Plenty of engineers who breeze through algorithm puzzles struggle once they are asked to maintain a messy production system, and plenty of excellent engineers freeze at a whiteboard. A technical interview should tell you how someone will do the job you are hiring for. Too often it tells you how well they have rehearsed interview questions.
This article sets out how to design interviews that test real work, score consistently and feed useful evidence into the hiring decision.
Why many technical interviews miss the point
Most weak interviews share a few habits. The questions are chosen by whoever happens to be interviewing that day. The task has little to do with the role: a data engineer is asked about sorting algorithms, a Salesforce architect about trivia from an exam guide. And the result is recorded as a feeling, “strong” or “not sure”, with no notes on what the candidate actually did.
The outcome is noisy. Two candidates for the same role face different tests, different interviewers apply different standards, and the hiring manager has little to compare. It also tends to favour people who interview well over people who work well, which is part of why structured methods help with bias in technology hiring.
Start the technical interview from the job, not the question bank
Before choosing any question, list the three or four things the person will actually do in their first months. For a backend engineer that might be designing an API, debugging a slow service and reviewing a colleague’s pull request. For a cloud security engineer, it might be reviewing an architecture for weaknesses and writing access policies.
Then design each part of the interview to test one of those tasks. If a question does not map to real work, drop it. This also makes it easier to explain the process to candidates, who tend to take a relevant exercise more seriously than an abstract one.
Formats that test real work
Different formats suit different roles. Pick the ones closest to the actual job.
Work-sample exercises
Give the candidate a small, realistic task: fix a bug in a short codebase, extend a data pipeline, configure a workflow in the platform they will use. Keep it bounded and respect the candidate’s time. The output gives you something concrete to discuss.
System design discussions
For senior engineers and architects, ask them to design something similar to what your team builds, then change the constraints. How they handle trade-offs, scale and failure tells you more than whether they reach a textbook answer.
Code or artefact review
Ask the candidate to review a piece of code, a data model or a security configuration and talk through what they would change. Reviewing is a large part of senior technical work, and it is hard to fake.
Past-work deep dives
Pick one project from the CV and go deep: what the candidate built, what went wrong, what they would do differently. Keep asking follow-up questions until the answers become specific. People who did the work can go several layers down; people who watched it usually cannot.
Score against a clear rubric
A technical interview only produces evidence if it is scored the same way for every candidate. For each part of the interview, write down what a good answer includes before the first interview takes place. Use a simple scale with described anchors, similar to the 1-to-5 bar used in CV screening, so a “meets the bar” rating means the same thing from every interviewer.
A few rules keep scoring honest:
- Interviewers score independently before discussing a candidate.
- Every rating has a written reason tied to something the candidate said or did.
- The same core exercise is used for every candidate on the role.
- Interviewers note what they did not get to test, so gaps are visible.
Who should run the technical round
The technical evaluator should be someone who does or leads the work, ideally from the team the candidate will join. They should be briefed on the rubric and on what the earlier stages found, including the strengths and gaps flagged at screening, so they can probe the right areas instead of repeating ground already covered.
In the Masarat.ai process, AI helps with matching, screening, analysis and interview summaries, and recruiters validate every shortlist before anyone reaches the employer. The technical assessment and the final decision stay with people: technical evaluators and the employer’s own hiring managers. The principle is that AI augments, humans decide. Our approach page shows where technical assessment sits among the other stages.
Turn interview findings into evidence
An interview that is not written down is soon reduced to a vague impression. Record what was asked, what the candidate did and how each part was scored. Interview transcripts can be summarised with AI support, but the evaluator’s judgement and comments should be their own.
Those findings then go into the structured candidate report alongside the CV analysis, recruiter assessment and verification results. Our article on what a good candidate report should include explains how the pieces fit. When the hiring manager reads the report before the final interview, they know what has been tested and what is still open.
Adapting by domain
The principles hold across roles, but the exercises change. Software engineering roles suit work samples and code review. Data and AI roles benefit from exercises on messy, realistic data and questions about how a model would be monitored in production. Enterprise platform roles need scenario questions about configuration, integration and working with business stakeholders. Leadership roles lean on past-work deep dives and system-level trade-offs rather than hands-on tasks.
Frequently asked questions
Should take-home tests be part of a technical interview?
They can be, if they are short, relevant and respectful of the candidate’s time. Many strong candidates, especially senior ones already in demanding jobs, will drop out of a process that asks for a long unpaid project. A bounded exercise discussed live is often a better compromise.
How many technical rounds are enough?
Usually as few as it takes to test the core tasks of the role. Each extra round should test something the earlier ones did not. If two rounds test the same thing, merge them.
Can AI run the technical assessment?
AI can help prepare structured questions and summarise what was said, but judging a candidate’s technical ability and fit for the team should stay with a qualified person.
If you want interviews that feed straight into a structured, comparable report, send us one technology role and we will run it through the full process with your team.