How to Assess Developers Before Hiring

The standard developer interview — whiteboard a sorting algorithm under time pressure — predicts how a candidate performs at a whiteboard under time pressure. It does not predict whether they will ship working software on your team. Assessing developers before hiring requires testing the work they will actually do: reading existing code, modifying it under realistic constraints, debugging tests, and communicating about technical tradeoffs.

What the classic coding interview measures

The whiteboard coding interview is a strange test. The candidate is asked to design a data structure on a wall, in real time, while a senior engineer watches. Few jobs ever require this exact skill. The interview measures a skill — performing technical work under interpersonal pressure — that is at best loosely correlated with the actual job.

The format persists for legacy reasons. It feels rigorous. It is easy to scale. It is what most senior engineers experienced when they were hired. But the data on its predictive validity is weak. Candidates who excel at whiteboard interviews are not consistently the best engineers in production. Candidates who struggle at whiteboard interviews include many of the best engineers in production.

What to test instead

Test the skills the candidate will actually use.

• Reading and modifying existing code. Most engineering time is spent in existing codebases, not greenfield. A test that asks the candidate to extend a small but realistic codebase mirrors the actual work.
• Debugging a broken test suite. A daily skill almost no hiring process screens for. Give the candidate a small repo with two or three failing tests and ask them to fix them. The signal is dense.
• Designing a small system with realistic constraints. Architecture sense matters for senior roles. Ask the candidate to design a small service with realistic load, data, and team constraints — not infinitely-scaling Google-class problems.
• Communicating about technical tradeoffs. Ask the candidate to explain a recent technical decision they made. Not what they built — why they chose it over alternatives, and what they would do differently. Reveals how they think.

None of these require the candidate to invent quicksort from memory. All of them mirror real work. The signal is dense and the candidate experience is meaningfully better than the whiteboard.

The take-home dilemma

Take-home tests give more signal — the candidate can think in their own environment, with their own tools, without performance pressure. But they lose candidates who refuse to spend unpaid time, and they reward candidates with more free time, which can correlate with privilege.

The fix is a short take-home (60-90 minutes max) plus a follow-up discussion of the candidate's submission. The take-home is short enough that the cost is reasonable; the discussion catches the candidates who got outside help.

For senior roles, paid take-homes are increasingly common — $200-500 for a half-day take-home, equivalent to a contractor day rate. The signal is strong, the candidate respects the offer, and the fairness concern is addressed.

How to score without bias

Coding assessments are particularly exposed to bias. Code style varies across cultures and traditions. A senior engineer reviewing code naturally favours the patterns they prefer. Same code can read as elegant or unreadable depending on whose eyes are on it.

Three controls help.

First, anonymise submissions where possible. Score the code before knowing who wrote it. Even names and email addresses move scores in research studies.

Second, score against a rubric, not against the reviewer's instinctive preference. The rubric should specify what good looks like — function size, naming, test coverage, edge case handling — and reviewers tick against it rather than reacting.

Third, use two independent reviewers for borderline cases. Their disagreement either resolves with a calibration conversation or surfaces a candidate who genuinely splits opinion (which is itself informative).

The AI tools question

Candidates increasingly use AI tools during coding assessments. The question is whether to allow this, how to detect it, and how to score it.

The honest answer depends on whether AI tools will be allowed on the job. If yes — and they will be at most modern engineering teams — the test should allow AI tools and adjust the difficulty accordingly. Pretending AI does not exist gives a misleading score that does not predict real work.

If the test allows AI tools, the difficulty should increase to compensate. Tasks that an AI can answer trivially should be replaced with tasks that require understanding the AI's output and judging its quality. The candidate's skill becomes "directing an AI tool effectively" — which is a real and increasingly important engineering skill.

If the test bans AI tools, the platform must detect their use. Tab switches, distinctive typing patterns, abrupt high-quality answer arrival — all generate signal. AssessExpert flags these for human review; the proctor decides whether the signal is conclusive.

Pair programming as an assessment format

For final-round interviews, pair programming sessions test how the candidate works with another engineer. The interviewer is not just observing — they are participating. The signal is high but the format does not scale to early-funnel screening.

Use pair programming for the last technical round, not the first. The early funnel should use scaleable formats — written tests, take-homes, or platform-delivered assessments. Pair programming for every candidate burns senior engineer time disproportionately.

Sample structure for a developer assessment

A balanced developer assessment that fits in 90 minutes:

• 10 minutes — MCQ on language fundamentals (15 questions on the candidate's stated primary language).
• 25 minutes — read-and-modify task: small existing codebase, two specified modifications, plus one bug to find and fix.
• 30 minutes — broken test suite: small repo with three failing tests, candidate fixes them.
• 20 minutes — short system design exercise: written discussion of how the candidate would design a small named service.
• 5 minutes — pre-flight check, instructions, close.

This covers fundamentals (MCQ), applied coding (modify task), debugging skill (test suite), and design thinking (system design). 90 minutes, four signals, all reviewable against a rubric.

How AssessExpert handles developer assessment

For developer-specific assessments — covering Python, JavaScript/TypeScript, Java, Go, C#, Ruby, PHP, SQL — see Coding Assessment Platform. The platform pairs role-specific MCQ banks with a practical coding task and a proctored session, all scored against a transparent rubric. For the broader assessment platform overview, see Technical Assessment Platform.

FAQ

Should we let candidates use AI tools in the test?

If they will use them on the job, yes — and adjust difficulty. Pretending AI does not exist gives a misleading score.

What if the candidate uses an AI tool when we asked them not to?

Layered detection flags it; the proctor reviews. Outcomes vary case by case. Severe and clear cases are declines; borderline cases get a clarifying interview.

How long should a developer assessment be?

90 minutes total. Longer adds noise from fatigue; shorter is too thin to capture multiple signals.

Should we test specific frameworks or just the language?

For mid-level and above, test framework knowledge if the role demands it. For junior, focus on language fundamentals — frameworks are learnable.

What about candidates who claim multiple stacks?

Pick the stack closest to the role. A candidate who claims Python, Go, and Rust should be tested in the one the job uses.

Are HackerRank-style algorithmic puzzles still useful?

For junior algorithmic-heavy roles, yes. For most production engineering roles, less so. The puzzle skill is loosely correlated with the production skill.

Next steps

If your developer hiring leans heavily on whiteboard interviews and you want to see how a structured assessment compares, book a demo. The first call covers your stack and the assessment shape that would fit.