Re-Imagining Technical Interviews: Valuing Experience over Exam Skills
The blog criticizes traditional technical interviews, emphasizing flaws in live coding assessments like time pressure and bias. It suggests prioritizing real-world skills and team qualities to enhance candidate evaluation.
Read original articleIn the blog post "Re-imagining Technical Interviews: Valuing Experience Over Exam Skills," the author critiques the current technical interview process, particularly the live coding round, for its shortcomings in assessing true engineering skills. The post highlights issues with using LeetCode exercises, time pressure, the expectation to talk out loud while solving problems, bias towards quick thinkers, and lack of empathy in the assessment process. The author argues that the ability to quickly solve coding challenges under pressure does not necessarily reflect an individual's overall problem-solving skills or coding proficiency in a real-world setting. Suggestions for improving the interview process include focusing on qualities like technical skills, communication, problem-solving, collaboration, and adaptability, and tailoring the assessment to reflect the qualities needed for successful engineering teams. The post encourages companies to rethink their interview methods to better evaluate candidates based on the skills and attributes that are essential for the role.
Related
Failed miserably. The twist is that the interview scenario is literally the same work that he does on a daily basis and he crushes it for our team. He's an extremely talented front-end engineer with crazy experience. I'd place his capabilities similar to that of someone with 3-4 more years of experience because his experience has been so compressed by working in startups and building his own startup (and exiting once!).
The problem in this case, is exactly as described: his nerves got the best of him -- despite the interview scenario being identical to his day to day work at which he excels -- as this is likely only his second interview ever in his life.
I think there are ways that companies can think about this problem that prevents them from inadvertently passing on otherwise qualified candidates. One is to address issues with async coding exercises now in the age of AI. As the author suggests, one way to look at it is that AI is just another tool; it really doesn't matter if a candidate uses AI to solve the problem if they understood the problem and the solution.
One interview I went through had a novel approach: the first round was actually a code review which had intentionally left some areas for improvement from performance (at the app as well as DB layer) to security to error handling. I enjoyed that experience so much that I ended up writing a small tool to help teams that want to adopt this approach[0] of using code reviews as an alternative approach to evaluating candidates. I think the inclusion of code reviews as an alternative or additional tool can be a great way to de-stress technical interviews and help teams form a more well-rounded profile of the candidate.
Many things mentioned in the article are already implemented by various companies during their interview process.