# How to assess technical skills in an interview

> Assess technical skills in an interview without puzzle questions: structured formats, work samples, code review and debugging, scored with a shared rubric.

Source: https://getlemma.io/blog/assess-technical-skills-in-interview

Assess technical skills in an interview without puzzle questions: structured formats, work samples, code review and debugging, scored with a shared rubric.

Lemma team

2 October 2026 · 6 min read

![How to assess technical skills in an interview](https://cdn.sanity.io/images/islu4peo/production/b00a21f922b7a2b3aa2406c971777a18141a1d61-2400x1350.jpg?w=2400&fm=webp&q=80&fit=max)

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)](https://doi.org/10.1037/apl0000994), 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](https://www.humrro.org/blog/is-cognitive-ability-the-best-predictor-of-job-performance-new-research-says-its-time-to-think-again/). 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.

| Format | What it shows | Watch out for |
| --- | --- | --- |
| Code review | How they read unfamiliar code, spot risks and give feedback | Pick a pull request with real issues, not typos |
| Debugging an existing codebase | Hypothesis-driven problem solving under realistic conditions | Keep the setup simple so time goes on the bug |
| Extend a small project | Working within existing structure; judgement about where changes go | Provide the project in advance or allow setup time |
| Pair programming | Collaboration, communication, how they take hints | The interviewer's style can dominate; agree how much to help |
| System design discussion | Trade-offs, scale, failure modes | Scores drift without a rubric; anchor what good looks like |
| Take-home work sample | Unhurried quality, tests, documentation | Cap the time and pay for anything long |
| Algorithm puzzle | Problem solving on self-contained problems | Rarely resembles the job; use sparingly |

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](https://getlemma.io/blog/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](https://getlemma.io/blog/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](https://getlemma.io/product/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](https://getlemma.io/product/assessments) and linked work such as GitHub repositories. If a candidate's [TypeScript](https://getlemma.io/skills/typescript) evidence is strong but there is little on [system design](https://getlemma.io/skills/system-design), you know where to focus. The [methodology](https://getlemma.io/methodology#evidence-types) 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](https://getlemma.io/blog/technical-skills-assessment-template#how-do-you-keep-assessors-consistent) 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](https://getlemma.io/blog/skills-based-hiring-guide) covers the whole flow.

If you run screens on a platform, the comparisons with [HackerRank](https://getlemma.io/compare/hackerrank), [Codility](https://getlemma.io/compare/codility) and [TestGorilla](https://getlemma.io/compare/testgorilla) set out what each does well and where candidate-owned evidence fits.

## Frequently asked questions

What is the best way to assess technical skills in an interview?

Use a structured interview built around a realistic task: the same exercise and questions for every candidate, scored against a rubric that describes each level. A 2022 re-analysis by Sackett and colleagues in the Journal of Applied Psychology found structured interviews the strongest predictor of job performance among the methods reviewed.

Are algorithm puzzles a good way to test developers?

They test one narrow thing well: solving self-contained problems under time pressure. Most engineering work is reading, changing and debugging existing code with others, so puzzles work best as one small part of an assessment, if at all.

How long should a technical interview be?

Long enough for one realistic task and a short discussion. We suggest 60 to 90 minutes for a live exercise. A focused task with a clear rubric tells you more than a long session that tries to cover everything.

How do I assess a candidate who uses AI tools?

Set the rule in advance and say it. If AI tools are allowed, ask the candidate to explain, test and correct the output. That shows judgement, which is the skill that matters when the tools write the first draft.

![](https://cdn.sanity.io/images/islu4peo/production/f5f399e61c91e2d9a4f0d8ce278cf3ae9f0efd35-1672x941.png?rect=0,0,1672,836&w=1600&h=800&fm=webp&q=70&fit=crop)

## Hire on evidence you can check.

Candidates on Lemma bring a Skills Passport: each skill scored from sessions, assessments and linked work, every item traceable to its source. Join the early-access list for hiring teams.

[See the verification API](https://getlemma.io/developers)

## Read more

-   [Hiring · 8 min read

    ### Skills-based hiring: a practical guide](https://getlemma.io/blog/skills-based-hiring-guide)
-   [Hiring · 6 min read

    ### Technical skills assessment template and rubric](https://getlemma.io/blog/technical-skills-assessment-template)
-   [Hiring · 6 min read

    ### HackerRank alternatives for evidence-based hiring](https://getlemma.io/blog/hackerrank-alternatives-evidence-based-hiring)