How to assess a developer without a take-home test
Take-home exercises are the default because they are easy to send, not because they work. They select for candidates with free evenings, they are commonly abandoned partway by exactly the people who have other offers, and the finished submission tells you how someone codes when nobody is watching and time is unlimited, which is not the situation you are hiring for. There are better formats, and all of them cost you more attention and less of the candidate's.
Why do take-home tests fail?
Because the cost falls entirely on the candidate and it is not distributed evenly. A developer with a demanding job and a family pays far more for the same exercise than one between roles, so the format quietly filters on availability rather than ability. The strongest candidates are usually the busiest and the most likely to decline.
The second problem is that unbounded time makes the result unreadable. If one candidate spent two hours and another spent twelve, you are comparing submissions rather than people, and asking for a time log does not fix it because nobody reports it accurately.
The third is that the artefact hides the process. A finished, polished repository tells you almost nothing about how the person handled the moment they got stuck, which is the behaviour that actually determines what they are like to work with.
Which formats actually produce signal?
Five, and each is good at a different thing. Most processes use one and infer the rest, which is how a company hires someone who writes clean code and cannot be given an ambiguous problem.
| Format | Measures well | Misses | Cost to you |
|---|---|---|---|
| Debug a running app, live | Diagnostic order, tool fluency, composure | Design judgement, long-horizon thinking | An afternoon to build once, reusable |
| Extend their own past code | Real ability, honest context, communication | Nothing if they cannot share code | Low, but needs a reviewer who can read it |
| Pair on a small real ticket | Collaboration, questions asked, pace | Independent work habits | One engineer for ninety minutes |
| Architecture conversation | Trade-off reasoning, experience depth | Whether they can actually build it | Low, but easy to fake with vocabulary |
| Paid short trial task | Nearly everything | Speed of process, availability of candidates | High, and slow to schedule |
What does a good live session look like?
A small application that runs, a defect that is real, and ninety minutes with the candidate in their own editor sharing their screen. Tell them plainly that the fix matters less than the reasoning, that they may search the web, and that asking you questions is expected rather than penalised.
Choose a defect with a visible symptom and a non-obvious cause. An endpoint that returns correct data slowly is ideal, because the naive path leads somewhere plausible and wrong. What you are watching for is whether they gather evidence before forming a theory, and whether they abandon a theory when the evidence contradicts it.
Write down two or three specific things before the session that would change your mind either way, and score against those rather than against your overall impression. Unstructured impressions in live sessions mostly measure how similar the candidate sounds to the interviewer.
How do you assess when nobody internal can read code?
This is the common case for a first technical hire, and pretending otherwise produces bad hires. You cannot evaluate the code, so evaluate the things you can: the explanation, the questions, and the operational history.
Ask the candidate to explain a technical decision they made to someone non-technical. You are qualified to judge that answer, and the ability to do it is a real requirement of a first hire who will be your only source of technical information for a year.
Then borrow a reviewer. An hour of an experienced engineer's time, from your network or paid for, is far cheaper than a wrong first hire, and their job is narrow: read one piece of the candidate's code and tell you whether it is the work of someone who has been responsible for something in production. Ask them to justify the verdict in plain language so you can calibrate for next time.
What should you stop testing for?
Algorithm puzzles, unless the job involves writing algorithms, which almost no product role does. They measure recent practice, which correlates with job hunting rather than with capability, and they filter out experienced developers who have not revised.
Trivia about framework APIs is similarly weak. Anything a developer can look up in ten seconds should not be a gate, and testing it rewards familiarity with your specific stack over the judgement that transfers into it.
Also stop reading enthusiasm as competence. A candidate who is excited about your product is pleasant and tells you nothing about their work. The correlation runs the wrong way often enough that it is worth removing from your notes entirely.
How do you keep the process short?
Three contacts, total, and a decision within a week of the first. A screening conversation, one technical session, and one conversation about working practices with whoever they will work beside. Anything longer loses candidates to companies that decided faster, and the additional stages rarely change the outcome.
Tell candidates the full shape of the process in the first message, including how many stages there are and what happens in each. This costs nothing and is unusual enough to be a genuine advantage in a competitive market.
Run the same exercise for every candidate for the same role and keep the notes. After three or four hires you will have a rough calibration of what a strong session looks like, which is worth more than any individual interviewer's judgement and survives that interviewer leaving.
Common questions
- Why do take-home coding tests not work?
- They shift the entire cost onto the candidate and that cost is not evenly distributed, so the format filters on free time rather than ability. Unbounded effort also makes submissions incomparable, since one candidate may have spent two hours and another twelve. Worst of all, a finished repository hides the process, and how someone behaves when stuck is the behaviour that predicts what they are like to work with.
- What is the best way to interview a full-stack developer?
- A live debugging session on a small running application with a real defect, ninety minutes, in the candidate's own editor with the screen shared. State that the reasoning matters more than the fix and that questions are expected. Watch whether they gather evidence before forming a theory and whether they drop a theory when evidence contradicts it, which is the behaviour the job actually requires.
- How do you hire a developer when you cannot read code yourself?
- Evaluate what you are qualified to evaluate: ask the candidate to explain a technical decision to a non-technical person, which is a genuine requirement of a first technical hire. Then borrow a reviewer for an hour, from your network or paid, with a narrow brief: read one piece of the candidate's code and say whether it is the work of someone who has been responsible for something in production.
- Should developer interviews include algorithm questions?
- Only if the role involves writing algorithms, which few product roles do. Puzzle rounds measure recent revision, which correlates with job hunting rather than capability, and they filter out experienced developers who have not practised. Framework trivia is equally weak, because anything a developer can look up in ten seconds should not be a gate on the hire.
- How many interview stages should a developer hiring process have?
- Three contacts and a decision within a week of the first: a screening conversation, one technical session, and one conversation about working practices with whoever the person will work beside. Longer processes lose candidates to companies that decide faster, and the extra stages rarely change the outcome. Telling candidates the full shape of the process upfront is unusual enough to be a competitive advantage.
