Guide · Technical hiring

How to design a fair technical screen

A good technical screen tells you how someone works, in a way you can compare across candidates and defend afterwards. A bad one tests memory, stamina or luck. Here is how to build the good kind.

8 min read

1. Start from the job, not from puzzles

List the three or four skills the person will actually use in their first six months, and build every task from that list. If the role is mostly API and database work, test API and database work.

Brain-teasers and trivia measure how recently someone revised, not how they build software. Leave them out.

2. Same problem, same conditions

Comparison only works if everyone faces the same test. Decide the conditions before the first candidate and keep them fixed:

  • The same tasks, in the same order.
  • The same time limit, announced in advance.
  • The languages the candidate may use.
  • What is allowed: documentation, search, AI assistants, or none of them.

3. Assess reasoning, not only the result

A working answer can hide a guess, and a broken one can hide sound thinking. The follow-up questions are where you find out which.

Follow-ups that reveal reasoning

  • Why this approach rather than another one you considered?
  • What happens when the input is ten times larger?
  • Where would this break first in production, and how would you notice?
  • If you had another hour, what would you change?

4. Use a rubric with anchors

Score a few separate dimensions rather than one overall impression, and describe what weak, good and strong look like for each. Typical dimensions for a backend screen: understanding the problem, correctness, code quality, design trade-offs, and communication.

Anchors for one dimension: design trade-offs

  • 1: Picks a solution without mentioning alternatives or limits.
  • 3: Names a trade-off when asked, with a reasonable justification.
  • 5: Raises the trade-offs unprompted, compares options against the constraints, and explains what they would monitor.

5. Keep it short and respectful

A first technical round of 30 to 60 minutes is plenty to decide who goes further. Multi-day take-home projects favour candidates with free time, not necessarily the best engineers.

Tell candidates what to expect, let them take the round at a time that suits them, and share what happens next.

6. Integrity without suspicion

Say up front what is and isn't allowed. If you monitor the session, record events and let people review them; don't disqualify anyone automatically. An event is a question to look at, not a verdict.

7. Calibrate after the first few candidates

Compare how different reviewers scored the same answers, and look at which questions actually separated candidates. Rewrite or drop the ones everyone passes or everyone fails.

Checklist

  • Tasks built from the skills the job really uses
  • The same tasks, time and rules for every candidate, announced in advance
  • Follow-up questions on the choices behind each answer
  • A rubric with anchored levels for each dimension
  • A first round of 30 to 60 minutes, not a weekend project
  • Monitoring that records events for people to review, never automatic rejection

Running this with Scoutly

Scoutly runs the first technical round with live coding in a 14-language editor and system design on a whiteboard, gives every candidate the same tasks, follows up on the choices behind each solution, and scores each answer against your rubric with a written reason. Your engineers review the evidence.

See how technical interviews work Request early access

Next guide

How to structure a first-round screen for contact-centre roles