Developer technical test: passing live coding and take-home assignments
· 9 min read
The technical test eliminates more developers than any other stage — rarely because they cannot code, often because they code as if nobody were watching. Someone is, and what they note is not what you think.
What does the interviewer actually watch during live coding?
Not the solution: the path. Do you clarify the problem before typing? Do you announce your approach? Do you test as you go or at the end? Do you recognise a dead end after two minutes or after fifteen? Most of these signals happen before the first line of code.
Should you start by asking questions?
Yes, and it is often explicitly scored. A technical test brief is deliberately incomplete: data size, edge cases, performance constraints. Charging in without asking is like shipping a feature without reading the spec. Two or three precise questions are enough — beyond that, it reads as avoidance.
What do you do when you get stuck mid-exercise?
- Say so. Silence is far worse than admitting it: the interviewer no longer knows whether they are watching thinking or a stall.
- Restate where you are and what exactly is blocking. Half the time, restating unblocks it.
- Offer a naive solution that works, then improve it. A slow but correct algorithm beats an elegant unfinished one.
- Take the hints. Refusing them out of pride costs more than accepting: collaborating is part of the score.
Take-home assignments: how far should you go?
Until the requested scope is clean, and no further. The trap is wanting to impress: adding an abstraction layer, a container, a CI pipeline for a two-hour exercise. It backfires — the conclusion is that you over-engineer, an expensive trait in a team. Deliver the requested scope, tested, with a file explaining your choices and what you would do with more time.
Should you respect the stated time?
Respect it, and say so if you went over. A "two-hour" exercise handed in after eight hours distorts the assessment, and the difference shows in the code. Writing "I spent three hours, here is what I left out" lands better than a flawless submission whose real cost the reviewer can guess.
What if the test uses a technology you do not know?
Ask whether you can use another language: it is allowed more often than people think, because what is assessed is reasoning. If not, state your real level before starting. A candidate who warns and roughly manages scores better than one who stays quiet and fails without explanation.
You do not hire a developer for the problems they have already solved. You hire them for the ones they have not seen yet — and the technical test exists to watch that.
This test does not replace the interview itself: the classic questions still need preparing, and we cover them in developer interview. See also the STAR method for telling your project stories without losing your way.