A younger dev I work with recently went for an interview with a fairly well known YC company.
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.
As someone who interviews and hires engineers I'm not even remotely convinced live code exercises lead to better hiring than any other signal such as a CS degree. I remember when the the coding horror fizz buzz article came out and honestly things have just gotten worse since then.
I always like to link the talk where the speaker mentions google hiring committee refused to hire themselves [0]. I suggest that this outcome isn't rare.
Indeed; there are a wealth of better ways to find signals.
One is look at any available public work (GitHub repos, OSS contributions), public writing (blog, Medium, etc.), past projects for fun or profit.
I have hired candidates that ended up failing almost all of my technical assessment that turned out to be great engineers to work with because I could see in their responses a self-awareness and a curiosity about the question. These were engineers that were easy to train and bring up to speed.
I saw a post on LinkedIn recently that really summarizes this sort of "intangible" in a more concrete way: https://imgur.com/a/l9Wql7A
My take is that low ego, curiosity, tenacity, humbleness, focus -- these tend to be better predictors of success in most cases. (But I can certainly appreciate that there are cases where you really want deep expertise in a very technically challenging aspect of a system).
Conversely, I've seen many average and below average engineers end up in FAANG by dedicating time to studying leetcode challenges. The system is perversely broken when selection biases towards those that actively seek to game the system.
Completely agree. This seems to me like common sense reasoning to me so I'm curious how the best companies in the world just seem to phone it in with leetcode.
Having been though these leetcode-style interviews, I would say one of their advantages seems to be that for interviewers who themselves do not have strong communication skills, it allows them to conduct an interview that appears objective. In other words, they may not understand what you’re saying, but they can read your code.
8 comments
[ 3.7 ms ] story [ 36.2 ms ] threadMany things mentioned in the article are already implemented by various companies during their interview process.
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.
[0] https://coderev.app/
I always like to link the talk where the speaker mentions google hiring committee refused to hire themselves [0]. I suggest that this outcome isn't rare.
[0] https://youtu.be/r8RxkpUvxK0?t=531
One is look at any available public work (GitHub repos, OSS contributions), public writing (blog, Medium, etc.), past projects for fun or profit.
I have hired candidates that ended up failing almost all of my technical assessment that turned out to be great engineers to work with because I could see in their responses a self-awareness and a curiosity about the question. These were engineers that were easy to train and bring up to speed.
I saw a post on LinkedIn recently that really summarizes this sort of "intangible" in a more concrete way: https://imgur.com/a/l9Wql7A
My take is that low ego, curiosity, tenacity, humbleness, focus -- these tend to be better predictors of success in most cases. (But I can certainly appreciate that there are cases where you really want deep expertise in a very technically challenging aspect of a system).
Conversely, I've seen many average and below average engineers end up in FAANG by dedicating time to studying leetcode challenges. The system is perversely broken when selection biases towards those that actively seek to game the system.