How to assess technical skills in an interview

To assess technical skills in an interview, give every candidate the same realistic task, ask the same follow-up questions, and score what you see against a rubric that describes each level. Prefer work that resembles the job, such as reviewing, debugging or extending code, over puzzles. Use evidence the candidate already has to decide what to probe.

That is the whole method. The rest of this post is about doing each part well.

Why do structured interviews work better?

Because they control the noise. When each interviewer asks different questions and scores on instinct, the result says as much about the interviewer as the candidate. Asking the same questions and scoring against shared anchors makes results comparable.

The research supports this. In a widely cited re-analysis of selection methods, Sackett, Zhang, Berry and Lievens (2022), published in the Journal of Applied Psychology, 107(11), found that structured interviews had the highest mean operational validity of the methods they reviewed (r = .42), followed by job knowledge tests (.40), with work sample tests at .33. HumRRO summarises the findings for practitioners on its blog. The authors also note that validities vary widely between studies, so how well you run the method matters as much as which one you choose.

The practical lesson: a structured technical interview, built around job knowledge and a realistic task, is one of the best tools you have. An unstructured chat is not.

Which interview formats show real technical skill?

Pick the format that matches the tasks the role needs. Most engineering roles need more reading and changing of code than writing it from scratch.

For most roles, two of these are enough: one hands-on format and one discussion. More stages rarely add information in proportion to the time they cost.

How do you structure the interview itself?

Plan it like an exercise, not a conversation. Write down, in advance:

1. The task. One realistic task, sized for the time you have. Give the same one to every candidate for the role.
2. The prompts. Three to five follow-up questions you will ask everyone, such as "How would you test this?" or "What would change at ten times the traffic?".
3. The hints. What help you will give when someone is stuck, and when. Giving one candidate more hints than another makes scores incomparable.
4. The rubric. Which criteria you are scoring and what each level looks like. Our technical skills assessment template has a four-level rubric you can copy.
5. The AI rule. Whether tools such as AI assistants are allowed, and how you will score their use.

Then run it the same way each time. Introduce the task, let the candidate work, ask the prompts, and leave time for their questions.

What does a good interview task look like?

Here is an example for a mid-level backend role. It is an illustration, not a task from a real company.

The task. The candidate gets a small service, a few hundred lines, that accepts orders and writes them to a database. A test is failing intermittently, and there is a feature request: reject duplicate orders submitted within one minute. They have 60 minutes, may use documentation, and are told whether AI assistants are allowed.

Why it works. It has a debugging part and a building part, both inside existing code, which is most of what the job involves. The intermittent failure rewards hypotheses over guessing. The duplicate rule has edge cases worth clarifying: what counts as a duplicate, which clock, what the caller sees. And there is no trick. A strong engineer who has never seen it will do well, which is the point.

The prompts. How did you narrow the failing test down? How would you know this works in production? What changes if two instances of the service run at once? Each prompt maps to a criterion on the rubric, so every answer has somewhere to be scored.

How should you score what you see?

Score each criterion alone, from what you observed, before talking to anyone else. Use a rubric with described levels; our technical skills assessment template has one for seven engineering criteria that you can copy as it is.

In an interview, the hard part is not the rubric but the note behind each score. Write one or two sentences of evidence as you go. "Found the race condition by adding logging around the queue consumer" is evidence. "Seemed strong" is not. Live interviews make this harder than take-homes, so agree in advance who takes notes, and leave five minutes after the candidate leaves to finish them.

If you did not see evidence for a criterion, mark it "not observed". A missing signal is a reason to probe in the next stage, not a low score.

How do you avoid testing the wrong thing?

Check each part of the interview against the role's tasks. Common ways interviews drift:

• Testing recall. Asking for API details anyone would look up. Let candidates use documentation, as they would at work.
• Testing speed over judgement. A very tight time limit rewards people who have seen the problem before.
• Testing confidence. Fluent talkers can score well on communication without solving anything. Score each criterion separately.
• Testing your own stack. Penalising someone for not knowing your internal tools tells you nothing about how fast they will learn them.

What should you check before the interview?

The evidence the candidate already has. A strong portfolio, an assessment result or a record of real work can tell you which skills are already well evidenced, so you can spend the interview on the gaps rather than re-testing the obvious.

A Lemma Skills Passport is built for this. Each skill shows an SCI score from 0 to 100 and the evidence behind it: live sessions rated by the person the candidate worked with, adaptive assessments and linked work such as GitHub repositories. If a candidate's TypeScript evidence is strong but there is little on system design, you know where to focus. The methodology explains what each type of evidence can and cannot show.

A score does not replace the interview. It tells you where to look.

How do you keep interview tasks fresh?

Rotate them. Once a task circulates, it measures preparation rather than skill. Keep two or three tasks of the same difficulty for each role, rotate them between rounds, and retire any you find online. When you add a task, have two interviewers try it first to check it fits the time.

Interviewers drift too. The assessment template covers calibration before and after a hiring round.

Where does the interview sit in the wider process?

At the end, not the start. A good process screens on evidence, uses a work sample or assessment to check the core skill, and saves the interviewer's hour for reasoning, collaboration and fit with the team. Our skills-based hiring guide covers the whole flow.

If you run screens on a platform, the comparisons with HackerRank, Codility and TestGorilla set out what each does well and where candidate-owned evidence fits.