Coding interviews are a common part of the hiring process for software engineering positions. While some people excel at these interviews, experien...
For further actions, you may consider blocking this person and/or reporting abuse
There's one more reason as I see it: sometimes it's not the developer, it's the interview that fails :-)
I definitely think there's some truth to that. I was in the position of interviewer many times in my previous company and I can tell that my peers didn't know what to ask, they just ask what they know, sometimes they don't even have the answers for the questions. Basically many interviewers didn't put any effort on preparing questions, sometimes they feel wasting time.
Cannot agree more! And it’s important to remember that interview is a two way lane: it should show applicant what they can expect just as much as to an employer.
I'm currently struggling with that.
I have almost a decade of experience as a software developer. I architected, engineered, and coded a couple dozen different systems, applications, and apps... marketplaces, e-commerce solutions, 360-evaluation tools, GPS-trackers, dashboards for IoT sensors... I also built my own tech-company during the pandemic (turns out it was kind of a bad idea lol)... but am failing interviews left and right to challenges such as "you have 30 minutes to write a function that receives JSON detailing the website and outputs the HTML as a string".
I guess I must start over from the beginning. Time to remember the password for my Beecrowd account.
Problem is most first level interviews are not conducted by developers but rather by a dude that received a 101 flash course on how to interview developers, probably written by another HR dude that does not know how to correctly mesure developer experience and value.
Keep up looking! Im sure you'll find some great opportunities soon!
I'm sorry to hear that you're struggling with interviews despite your impressive experience and accomplishments. It sounds like you've worked on a wide range of challenging projects and developed a lot of valuable skills. It can be frustrating to face coding challenges that don't seem to reflect your expertise or real-world experience. I hope you find the right opportunity soon and don't have to start over completely. Good luck!
This really sucks, try not to let it knock your confidence or the enjoyment you get out of programming. It is also a bit of a numbers game, the next interview you could come out looking like a total genius depending on what random thing they ask you about
I think the real issue is:
So why the hell they focus on things that are totally not used in 99.99% of work you do later after joining the company? To me this sound like a broken interview process.
You make a valid point. It's true that coding interviews often prioritize skills that are not necessarily applicable to everyday work as a developer. However, it's important to note that these skills are still important to have in order to solve complex problems that may arise in a developer's work. Additionally, companies often use these skills as a proxy for problem-solving ability and general technical proficiency.
Companies should strive to create a more comprehensive and relevant interview process to better assess candidates and ultimately make more informed hiring decisions.
Something about the idea of failing an experienced developer on the basis of being too used to the job just feels to me like there might be something deeply wrong with this whole interview process.
Sometimes the experienced developer chose to fight the wrong battle.
If companies take time to design an interview process and challenges that are a more accurate representation of the kind of work they will be expected to do in that company, then it removes the need for these stupid brain teasers (that's what they are) and reduces the unnecessary anxiety for the candidates.
I have helped create just such an interview process and a take home technical assignment at my org, it's not perfect but it gives the candidate a chance to exercise some of things that we'd expect them to know and work with once they start with us:
We give them enough time to work on this assignment and during the interview we have a conversation about their hand-in and deep dive into their thought and decision making process based on the code they submitted. I have personally interviewed over a 100 candidates with this process over the last 3 years and when asked to rate the interview experience, I can't remember one candidate that didn't say they really enjoyed this kind of "coding challenge", much better than orgs. My colleagues have reported similar experiences with the candidates they have interviewed.
So yes sometimes it's the interview process that needs an attitude adjustment, its not always a burden for the candidate to bear if you as an org are lazy or don't care or are too misguided to think that brain teasers are a great way to asses candidate fitness for the role in the org.
I have a decade development experience as well. When it comes to the "technical" interview, companies are focused more on technical vocabulary, explainations about irrelevant techniques, and being able to answer "gotcha" questions. It makes the interview less productive because it becomes more about SOUNDING technical then explaining how you've used technology to develop productive solutions. I believe that's why it takes companies longer to fill positions OR end-up with so-so Developers. I'm thinking of starting my own comapany.
It's encouraging to hear that you're considering starting your own company. With your decade of development experience, you'll be well-equipped to succeed.
FYI only: minor typo in the link -
Top 10 Classic Interivew QuestionsFixed. Thanks a lot!
Rusting skills is always a problem when as an experienced developer to get asked to do so much more, and have less and less time for other things. Finding a balance is hard.
I'm not sure I agree with the bit about experienced developers not noticing minor errors. I would say it is the experienced developers who spot all the minor details that come back to bite the team later, and it's junior/mid developers who typically cause themselves problems down the line by misnaming things, applying patterns they read off medium without completely understanding them, writing unmaintainable code, or not handling error cases or rotations or process death properly (on android)
I wonder where that assumption comes from. I do remember an interview I was in recently which was a live coding exercise in a text file, and thinking that a lack of autocomplete and syntax warnings was really slowing me down (I lean on the IDE a lot, and I avoid using my memory as much as possible). Perhaps that looks like a lack of detailed knowledge to someone who hasn't learnt to lean on their IDE yet.
I think it's definitely worth reminding yourself how to do timed coding challenges and brushing up on some basic algorithms if it's going to be that sort of interview.
But when you're being interviewed by someone who knows less than you, it's really more about guessing what you think they think is the right answer, rather than giving them what you think is the correct answer. (And it's also about holding your tongue when they say something totally stupid 🤣)
I often wondered how can it be so hard to succeed in an interview, to prepare for the known and unknown unknowns, and gues what aspects might be most important in the eyes of the interviewer, when I have been successfully coding at work for so many years. But new projects and technologies can be challenging outside of the interview situation as well. It is important that we keep an open mind and never stop learning as senior developers.
Another aspect: when I first read the title "How Senior Developers Sabotage Interviews" I didn't think it was about self-handicapping, but rather about toxic workplace culture where senior developers would sabotage an interview and give applicants a hard time to prevent undesired competitors entering their company.