Software Engineer Interviews are Hard

[@TroodoN0]

I think interviews are broken at the moment. I completely agree with you when you said you forgot "for" loop syntax. I often forget syntax even with 20 years of experience because i jump from one language to another, trust IDE to much or I havnt worked with certain part of a code in a long time. It feels embarrassing. You said the solution to that is to study more or practice building those things from scratch. However think about this, why do interviews require us to know those things. In practice aka at work noone requires us to know the exact syntax and even if we forget we let IDE to help us or we google it, thats how it is. Another example is design patterns. Even tho I know them (not by heart and not word by word) with my team we hardly ever talk about them and we still follow design patterns with best code practice in mind and we just implement them naturally. We are humans and we forget things but interviews require us to be perfect and knowing those things. Whats even worse is that we as software engineers are involved more and more in different areas of work. For example I could be working in the backend part for 4 weeks then 1 week on frontend and then another 4 weeks in some infrastructure project. And then when I go back again to backed, i do feel rusty and need extra time to get up to speed. And I cant prove that experience in the interview even tho all those areas i mentioned can crucial for the business, sometimes complex and require a lot of thinking before even first line of code is written. I feel like nowadays even tho I have more experience it is going to be harder for me to pass an interview. I am actually thinking of changing work now (with 20 years of experience but my last interview was about 2 years ago) at the moment but it pissed me off how much experience I have but I cant prove it in the interview easily. From what I hear I have to learn many things from scratch and I am like you a visual person. Its not fair to constantly re-learn basics I would say. I have a massive disadvantage to someone who is changing job every 3-6 months and is doing an interview each time. Who's more worth it?

[@nbktechworld]

Nowadays many interviewers want the perfect answer

[@argenistherose]

The problems you deal with during interviews don't translate to your day to day work. Every software engineer knows that, they use it as a filter system. But at the end of the day, they reject so many talented people and it's not fair.

[@AndrewYang1]

I started my interview cycle recently after being at a company for 11+ years. Needless to say, live coding interviews are so different from what you do in your day-to-day job. From my experience, you don’t need to memorize all the modules/libraries and what not as you craft your solution. Sometimes you can just articulate which libraries you are trying to use and more often than not, your interviewer can give you a hint/reminder here and there to help you. I do think you need to know the basics of whichever language you claim to know: loops, data types, structures you can use etc. Otherwise, how do you expect your interviewer to evaluate you if you don’t even know how to write a simple for loop? Another weird thing to get used to is to talk out loud. I talk about what I’m going to do before I start coding. Something as simple as reading the problem out loud just to figure out a straight forward verbal solution initially. There will be edge cases to consider but I like to leave those to the end because if you think too much about them, this will become a huge roadblock that prevents you from moving forward. I’ve done it a few times myself, did not get the job of course. In my last interview round, I was given two coding questions. I did not come up with the perfect solution in one shot in either of them. Instead I started talking and my interviewers gave me hints that eventually led to my solutions passing all the test cases. I do think the interviewers want to know about your thought process more than you just typing out perfect answers. Just think about how you would collaborate with a colleague in a work environment. That’s how I’d like to treat all my live coding interviews.

[@StephenSamuelsen]

yeah talking out loud while coding can take some getting used to

[@erekhronmusic]

honestly this is why I love interviews where we have ACTUAL technical discussion happens besided some coding. I had won most of applications where they were actually interested in my experiences and where i am good at - and not just general coding in a pseudo code. It is easy to fumble to figure out a quirk in a language (which you never or barely encounter in your daily work), safe to say i lost those opportunities, even with 10+ years of experience...and I am a person who mentored tons of developers When I did interview others - I always tried to see that they are software engineer material. How wide they see the big picture, and how well the essentials they are understaning. If they do not know how to create a palindrome string checker i don't care. Especially with the AI tools and etc at hand all this pressure coding is obsolete - and it should be. It is a bad filter. I had people rocking coding interviews and on the daily job failed to create a simple CRUD...they knew leetcode but could not optimize a DB query. Handson experience, with the right mindset and adaptibility is a much better indicator if someone is a right fit for a position or not.

[@StephenSamuelsen]

technical discussions are the most effective I think, yeah. leetcode stuff can be a bit like taking a test in the sense that you study to memorize how to do it once, then immediately forget it once you pass the test lol

[@ProgrammingWIthRiley]

I consult for a fortune 200 company and have high level architecture conversations with senior executives (and I manage their Kubernetes infra). My interview was about 5 minutes long and really more of a how do you do session. Competence shows itself most often times in experiences and confidence. Learn how to sell, because you're selling yourself. The technical interviews should never be harder than problems you solve on your own time.

[@youtubegarbage4u]

selling yourself all sounds cool and fun in front of execs that cant test your coding or technical skills and listen to you blarb with sales pitch. the moment they bring out a leetcode hard all that confidence and snake oil sales man gets thrown out of the window. coding and technical questions are things we face and have to study to prepare for, sorry this is not program/product manager interview

[@retrorewind6042]

@@youtubegarbage4u maybe they should change who is doing the interviews then. leetcode is pretty stupid

[@youtubegarbage4u]

system design is not a story, a story is like an essay that cant be dis-proved. system design is a technical discussions that are mostly things can be dis-proved meaning you cant talk about scaling without discussing how the hell you will scale etc. and good luck telling stories about that.