How to build a technical assessment for developers

Building a technical assessment for developers means deciding what you're actually screening for - fundamentals and concepts, or hands-on coding ability - then choosing a format that measures it honestly, sized to respect the candidate's time. The two goals get conflated more often than they should: a concept-and-fundamentals test and a live coding exercise measure genuinely different things, and treating one as a substitute for the other is where a lot of technical hiring processes go wrong.

This guide covers how to build the concept-and-knowledge layer well, including question design, difficulty calibration, and where it fits relative to a live coding round. For the broader process of building any recruitment assessment, see our complete guide to online assessment for recruitment.

Decide What You're Actually Screening For

Before writing a single question, get specific about what this particular assessment is supposed to filter on, because "test their coding ability" isn't specific enough to build a good test from.

• Fundamentals and concepts

  - language syntax, data structures, common debugging scenarios, understanding of core principles - these work well as structured multiple-choice or short written-response questions

• Applied coding ability

  - writing working code to solve a problem - this generally requires a live coding environment, not a knowledge test

• System design judgment

  - how someone reasons about architecture and trade-offs at scale - this is usually better suited to a live conversation than any written format

• Code quality and style

  - best evaluated through a take-home project or review of existing work, not a timed test

Most technical hiring processes actually need more than one of these, at different stages. Trying to cram all of them into a single test format is how you end up with an assessment that measures none of them well.

Where a Concept-Based Assessment Fits

A structured, multiple-choice or written-response technical assessment is genuinely useful - it's just useful for a specific job in the funnel, not the entire technical evaluation.

• As an early filter for high-volume roles

  - screening hundreds of applicants for fundamentals before investing interviewer time in live coding rounds

• To confirm baseline knowledge before a deeper technical interview

  - someone who can't answer core concept questions correctly is unlikely to perform well in a live coding session either, so this saves everyone's time

• As a consistency check across a large, distributed candidate pool

  - every candidate answers the same questions, scored the same way, which a purely conversational technical screen can't guarantee

Worth being direct about here: a platform built for multiple-choice and written-answer testing, like TunnelQuiz, is well suited to exactly this layer - concept checks, syntax and debugging-recognition questions, scenario-based reasoning - but it isn't a live coding-execution environment. If your process needs candidates to actually write and run code in a sandboxed environment, that still belongs in a separate, dedicated coding round; a concept assessment is the filter that happens before that round, not a replacement for it.

Write Questions That Actually Predict Performance

Not all technical questions are equally useful, even within the "concept and fundamentals" category.

• Favor debugging-style questions over pure syntax recall

  - "what's wrong with this code snippet" tends to predict real-world troubleshooting ability better than "what does this keyword do"

• Use realistic code snippets, not contrived edge cases

  - a question built around a bug pattern developers actually encounter is more predictive than an obscure trick

• Write scenario-based questions for judgment, not just knowledge

  - presenting a realistic situation ("this API call is timing out intermittently, what would you check first?") surfaces reasoning a pure fact question can't

• Avoid overly academic computer-science trivia unless the role genuinely requires it

  - favoring a formal CS background over practical skill can quietly exclude strong self-taught developers

A relevant, well-designed concept question generally beats a harder but less relevant one - difficulty for its own sake doesn't make a test more predictive; it just makes it more frustrating to take.

Calibrate Difficulty and Timing Carefully

Technical assessments have a specific failure mode where teams either make them too easy to be useful or so demanding that strong candidates drop out before finishing.

• Match difficulty to the role's actual level, not to how impressive a low pass rate looks - a test that most qualified candidates fail is miscalibrated, not rigorous
• Give generous, not stingy, time limits - the goal is measuring whether someone can reason through the material cleanly, not whether they can do it under artificial time pressure that has little to do with the job
• Keep a concept-based screening test relatively short - 20-30 minutes is usually enough to assess fundamentals without adding unnecessary drop-off, saving longer formats for later-stage, higher-commitment rounds
• Use negative marking carefully, if at all, on technical concept questions - it discourages wild guessing, but calibrate it so it doesn't punish reasonable uncertainty on genuinely ambiguous questions

A meaningful share of developers report disliking technical assessments in general, largely tied to poorly calibrated difficulty and length, which makes getting this part right not just a fairness issue, but a real factor in whether strong candidates finish the process at all.

Randomize and Protect the Question Bank

Technical assessment questions circulate faster than almost any other category - they get shared, discussed, and posted to prep forums more than most other hiring test content.

• Randomize question order and answer choices per candidate, so results can't be shared by position even if candidates are in contact with each other
• Maintain a large enough question bank that no two candidates reliably see an identical test
• Refresh questions periodically, since a technical test that hasn't changed in years is more likely to have circulated widely by now
• Watch for detection signals during the test itself - tab switching or a second screen during a supposedly closed-book concept test is a meaningful flag worth reviewing

For the full approach to protecting test integrity, including how to handle flagged attempts fairly, see How to Reduce Cheating in Remote Hiring Tests

Pair It With a Live Round, Don't Replace One With It

The strongest technical hiring processes treat a concept assessment as one stage, not the whole evaluation.

• Use the assessment to filter, then invest real interviewer time in a live coding or system design round with candidates who clear the bar
• Let the assessment results inform the live round, not replace it - a candidate's specific weak areas on the written test can shape what the live interviewer probes
• Give candidates context on what to expect next, so the written assessment doesn't feel like a black box before a very different kind of evaluation

This sequencing respects everyone's time: candidates don't spend hours on a live coding round if they're missing fundamentals, and interviewers don't spend their time re-testing knowledge a structured assessment already covered efficiently.

The Short Version

Building a technical assessment for developers starts with deciding exactly what you're screening for - fundamentals and concepts are well suited to structured written or multiple-choice questions, while hands-on coding ability needs a live coding environment. Used together, in the right order, they respect candidate time and give a much fuller picture than either format alone.