Start With the Job, Not the Test
The most common mistake is designing the assessment before defining the role. Teams reach for familiar formats such as algorithm challenges, take-home projects or live pair programming, and then fit the job to the format.
Reverse the order. Write down what the person will actually do in their first six months. Debug production issues? Build features on an existing codebase? Clean and analyse data? Write reports for non-technical colleagues? Each answer points to a different kind of test.
A useful rule is that every part of the assessment should map to a real task in the role. If you cannot explain why a question matters for the job, remove it. Relevance is the single biggest factor in whether a test is fair, and it is also what candidates notice. People can tell when an exercise has nothing to do with the work they were told they'd be doing.
Choose the Right Format for the Signal You Need
Different formats measure different things, and none is perfect.
Take-home exercises reveal how someone works without a clock ticking, including structure, naming, testing habits and written communication. The cost is the candidate's time, which creates an equity problem: people with caregiving duties or demanding current jobs can't always spare hours. Keep these short and clearly scoped, and be honest about the expected effort.
Live exercises show how someone thinks and communicates in real time. They are good for collaboration and problem-solving but can reward confidence over competence and penalise anxious candidates who would perform well in a calmer setting.
Code or work review asks the candidate to read and critique an existing piece of code, query or analysis. This is underused and closely resembles daily work, since most professionals spend more time reading and modifying other people's output than writing from scratch.
Structured conversations about past projects can reveal depth of experience. Ask what trade-offs the candidate faced and what they would change, rather than whether they have used a particular tool.
Mixing two or three formats usually produces a clearer picture than relying on one.
Keep It Short and Respect the Candidate's Time
A long assessment doesn't produce better information. It mostly filters for people with the most free time. As a general principle, ask for the minimum effort that gives you the signal you need.
State clearly at the outset what the exercise involves, how long it should take and how it will be evaluated. Ambiguity makes candidates over-invest, which wastes their effort and distorts your comparison between those who did and didn't. If an exercise is genuinely substantial, consider paying for the candidate's time.
Also be clear about what's allowed. Many real jobs involve searching documentation, using libraries and consulting references. Banning those tools produces an artificial scenario unrelated to how people actually work. If you do want to test unaided recall of something specific, say so and explain why.
Score Consistently, or Don't Score at All
Unstructured evaluation is where bias creeps in. If interviewers form impressions and then discuss them afterwards, the loudest or most senior opinion tends to win, and similarity to the interviewer quietly becomes a hidden criterion.
A simple rubric fixes much of this. Before the first candidate is assessed, decide what good looks like on each dimension: correctness, clarity, handling of edge cases, communication, testing and so on. Score each dimension separately, ideally before reviewers compare notes, and give every candidate the same exercise under the same conditions.
A rubric also protects the candidate. It forces reviewers to point to evidence rather than relying on a general feeling, and it makes feedback possible. A candidate who is rejected but told specifically what the team was looking for leaves with a better impression of your company than one who hears nothing.
Don't Forget the Roles That Sit Between Engineering and the Business
Not every technical role is about writing production code. Many sit at the boundary between software and the rest of the organisation, such as analytics, reporting, operations, finance technology, QA and implementation roles. In these jobs, much of the daily work happens in the tools business colleagues already use, and the most important of these is the spreadsheet.
For these positions, a purely coding-focused assessment misses the point. A candidate might write elegant Python and still be unable to read the workbook the finance team relies on, or untangle the formulas in a report that a department has trusted for years.
This is where a practical Excel exam earns its place as a legitimate part of the process, provided it is designed well. The best versions use realistic tasks: clean a messy export, combine two tables with a lookup, summarise results with a pivot, find and explain an error in an inherited formula. They are time-boxed, scored against a rubric and open about what is being measured.
Test for Judgement, Not Just Recall
The strongest signal in any technical assessment is often not whether the answer is right but how the candidate got there. Look for the following:
- How they clarify the problem. Do they ask sensible questions before diving in, or assume requirements?
- How they handle ambiguity. Real work rarely has a perfectly specified brief. Candidates who state their assumptions and proceed sensibly are showing a skill that matters more than the specific solution.
- How they test and verify. Someone who checks their own work, considers edge cases and questions their own results is demonstrating habits that prevent expensive errors later.
- How they communicate trade-offs. Explaining why one approach was chosen over another is a better predictor of seniority than raw speed.
This applies equally to AI-assisted work, which is now part of many roles. If candidates are allowed to use assistants, evaluate how they check and correct the output rather than how fast they produce it. Judgement is the thing a tool can't supply.
Close the Loop
A fair process doesn't end with a decision. Give candidates timely feedback, even brief feedback, because it costs little and builds your reputation in a field where people talk. And review your own process regularly. Ask whether the people who performed well on the assessment performed well in the job, and whether anyone you almost rejected turned out to be excellent. If the test doesn't predict anything useful, change it.
The Takeaway
A good technical assessment is relevant to the work, proportionate to the role, consistently scored and respectful of the candidate's time. It tests how people think as well as what they know, and it uses the tools the job really requires, whether that's an IDE, a SQL console or a spreadsheet.
Hiring will never be perfectly predictable. But a thoughtful assessment makes it fairer, and fairer processes tend to find better people.
