Are you struggling with hiring good programmers? This guide will help you to reliably understand if a candidate is a competent programmer, inspired by Casey Muratori’s interview.
With this approach, he claims he can always understand if someone is a competent programmer, and he has never seen it fail.
His opinion is that the second question is much harder to answer, and he doesn’t know how to reliably do it, and whether there is a way to answer it.
For the first question, he says that with the process he is following, he can always understand when someone is a good programmer.
If they can answer your questions, and their answers come from solid foundations, it means that they know what they are doing. If they can’t, then they are not what you are looking for.
In his opinion, one of the benefits of this approach, compared to LeetCode style interviews, is that people are responding to the questions from a place of comfort, which is similar to how they actually work.
To play devil’s advocate: difficult coding questions are a way to minimize false positives, with the side effect of having a large number of false negatives. Being able to prepare and apply learned techniques is a kind of problem solving. The ability of problem solving is the most important skill a programmer should have.
Another benefit of LeetCode style interviews is that they are somehow standardized. Standardized processes help large organizations stay consistent.
In our opinion, interviews of this style are not the only way to eliminate false positives. The same result can be achieved with Casey’s approach too. After all, how could a candidate fake the reasons behind their project decisions, or struggle to explain how they would improve something they have spent a lot of time building?
While we prefer this approach from LeetCode style interviews, we think something is missing: A way to understand how adaptable the candidate is to a new codebase.
A different set of skills is needed for jumping into a huge codebase and making contributions, from being able to explain why and how you did something you had spent a lot of time working on.
Our proposed solution to this is to have a pair programming session with the candidate, where they have to fix a bug in an unknown codebase. During this session you can understand:
At Linear, they were struggling to find the right people for their fast-paced environment following the standard interview process.
For that reason, they decided to do paid work trials, which typically last from 2 to 5 days depending on the seniority of the role. They mention that this approach is working very well for them, and they have achieved, at the time of writing, 96% retention. Everyone has to do them, from engineering to C-level candidates. During the trial the candidates work on a real project.
We also believe that this could be the best way to find the perfect fit, pairing on actual tasks should be the best indicator. Unfortunately, not everyone has the bandwidth or culture to support this.
In our opinion, Casey’s approach to coding interviews is an improvement to the current standard. However, it can be extended to have more certainty that a candidate is a good fit.
Finally, after you have made the right hire, you can use Hopp, our own OSS pair programming app, to have an even better onboarding experience. During the pairing sessions, you can guide the new hires by smoothly taking control of their computer when needed and saving them time from learning obscure commands and processes.
PS: Only Grammarly has been used on this post, I decided that I am not going to use AI when putting my views online.
Casey doesn’t like LeetCode style of interviews, instead, he follows a drill-down approach where he
According to Casey, two questions need to be answered in an interview
The process he follows can be summarized in the following steps:
Another quite novel approach to tech hiring we should mention, is Linear’s work trials.
We would love to hear your approach to coding interviews and whether you disagree with our views.
Feel free to reach out at X/twitter or email me directly at iason at gethopp dot app.
You must be logged in to post a comment.