This post describes a Software Engineer interview exercise I would like to experience one day. But before, let’s talk about how coding interviews are generally executed.
The three most common coding interviews have the following forms: take home exercise, onsite programming and whiteboard coding.
A take home exercise is an assignment that the company gives to the candidate that has to be done at home. The candidate may have a few hours to a few days to submit the code.
An onsite programming interview is where an interviewer sits aside the candidate and let the candidate program the assignment. The candidate generally has access to the internet and thus can do web searches to learn about APIs they forgot about.
Whiteboard coding is the situation where the interviewer ask a generally simpler programming task like “write a function that sorts a list of strings” on a whiteboard. Contrary to the two other methods, the candidate generally cannot do web searches and is thus limited by what they already know.
For whatever reason, I personally perform better on a whiteboard than when someone looks at my screen and judge me (I find it creepy). In particular, an onsite programming interview doesn’t feel like pair programming because it’s not: the other person is not helping. And I don’t like take home exercise because they can become a time sink.
The recruiter asks the candidate which language (and open source projects, if any) the candidate is familiar with.
The recruiter signal the candidate will have to do a code review and emails links to blog posts to how to do a code review. Preferably the company has a public document, failing that here’s a start:
The interviewer takes a real project in the chosen language, forks it, creates a GitHub Pull Request (or relevant review tool) that has several problems, e.g. O(n³) algorithm, overabstracted code, poor documentation, no test, inconsistent formatting, etc.
The interviewer behaves as a junior that is both new to the project and the language and request the candidate to do a code review.
The interviewer shall act in a kind, empathetic way (like the company’s employees), but having issues with design fundamentals and needs guidance.
That’s it! The code review is the interview. You can learn so much based on how they behave during code review. Much more than code on a whiteboard. With a blind setup with temporary accounts, the interviewer doesn’t know who the candidate is and thus is not biased by prior experience.
Coupled with in-person interviews, I think it’s a good signal.
Think how this is different from three other forms: take home exercise, onsite programming and whiteboard coding.
It forces the person to read the surrounding code, understand the overall architecture and design parameters and make judgement calls.
This process definitely costs more to the company. The interviewer has to spend time making a non-trivial change. On the bright side, this change can be reused across candidates asking for the same language, which may reduce the toll .
By far take home exercise is the one that takes the less time for the company. Onsite programming generally has an higher duration allowance than whiteboard coding. By contrast, a code review interview initially require more preparation by the company, but can still scale by reusing changes over candidate. To make this work, the PRs themselves can be made private.
In the best situation, the code is judged in a blind way; the interviewer in this case doesn’t know who the candidate way. Home codign: In this case, the company puts the burden on the candidate to potentially spend hours to create a toy project. This is closer to a University assignment than an interview, and measures how someone can work in silo. The company generally looses information about how long the candidate took to make the project, an important signal.
It generally forces the candidate to think out loud, which may or may not fit certain type of personality.