Developer Assessment Test: A Practical Hiring Guide

A developer assessment test should show how a candidate handles work that matters in the role: understanding unfamiliar code, making a bounded change, testing it and explaining the trade-offs. A polished solution alone does not show how the candidate reached it or whether they can maintain it.

For engineering leads, the practical challenge is to collect useful evidence without turning recruitment into an unpaid project. Start with a small work sample, define the scoring criteria before inviting candidates, and use a structured follow-up. Treat the result as one part of the hiring decision, not a guarantee of future performance.

1. Define what the assessment needs to measure

Write down three or four capabilities the person needs on entry. Separate these from knowledge you expect them to learn after joining. The US Office of Personnel Management makes this distinction in its guidance on work samples: the task should resemble the job and assess capabilities required when someone starts.

For a backend role, that might mean tracing a failed request, changing an API safely and writing a regression test. For frontend work, it might mean fixing an accessible form with loading and error states. For a data role, it might mean identifying duplicate records and explaining the consequences of a join. Our data engineer hiring guide covers the wider role definition; this guide focuses on designing the assessment itself.

Algorithms are appropriate when algorithmic reasoning is part of the job. Framework trivia is appropriate only when that specific knowledge is genuinely required. Neither should become the default simply because it is easy to score.

2. Choose a format that fits the evidence you need

Use the same core task, instructions and assessment criteria for candidates applying to the same role. Offer an equivalent alternative where needed for accessibility. No format is inherently cheat-proof, and live observation is not a substitute for clear criteria.

As a starting design, try a 60-minute work sample followed by a 20-minute discussion. These are proposed limits, not a validated benchmark. Pilot the task before using it, adjust its scope, and tell candidates to stop at the time limit and record unfinished work. Do not reward extra hours hidden behind a nominal deadline.

Provide a working starter repository, setup instructions, sample inputs and one command to run the tests. Avoid requiring paid software or a personal cloud account. Agree any compensation before the exercise, especially if the task is substantial, and check applicable local requirements. Never use candidates to deliver unpaid production work.

3. Build a small, realistic developer assessment test

Here is an illustrative backend exercise. It uses fictional data and a local test environment, not a client system.

Candidate brief: handle duplicate import events

A small service receives customer-import events. Each event contains an event_id, a fictional customer record and a timestamp. The current implementation creates a second record when the same event is retried. Fix duplicate handling for the supplied single-process exercise and add tests.

• Expected behavior: the first valid event creates one record; repeating its event_id does not create another record.
• Input validation: an event without an event_id returns the documented validation error and makes no change.
• Failure case: if the simulated write fails, retrying the event must still be possible.
• Scope: use the supplied in-memory store. Do not add external services, authentication or a deployment pipeline.
• Deliverables: a patch, tests and a short note explaining assumptions, unfinished work and what would change for concurrent requests or process restarts.

Give candidates the acceptance criteria rather than hiding essential requirements in private tests. The exercise can reveal whether someone distinguishes a retry from a new event, notices a failure path and keeps the solution within scope. It cannot establish everything about distributed-systems expertise.

In the follow-up, ask what happens if two requests arrive together and what state must survive a restart. Evaluate the reasoning separately from the intentionally simplified implementation. Do not penalize a candidate for failing to build features that the brief explicitly excluded.

4. Score observable behavior, not presentation polish

Create the rubric before reviewing submissions. For each criterion, record a score and a specific example from the work. Use a simple scale: 0 means the required behavior is absent or incorrect; 1 means partial evidence with material gaps; 2 means the stated requirement is met; 3 means it is met with a well-supported explanation of relevant limits. A longer solution does not automatically deserve a higher score.

This is an example rubric, not a validated hiring instrument. Set role-specific decision rules during calibration rather than inventing a universal passing total. Record critical issues separately so an average cannot hide a failure on an essential requirement. Mark evidence you did not observe as unknown instead of assuming incompetence.

Keep seniority expectations explicit. A junior candidate might need to make a correct local change and explain it. A senior candidate may also need to identify operational limits. Ask for those expectations in the brief; do not silently change the standard during the interview.

5. Use the discussion to test understanding

A short, consistent follow-up helps distinguish a working submission from an understood solution. Ask candidates to explain a decision, trace a failure and adapt one requirement. OPM’s structured interview guidance recommends predetermined questions and a shared rating scale. Apply that consistency to the technical discussion.

For the example above, ask: “Where is an event marked as processed?”, “What happens if the write fails?” and “Which test would you add first for concurrent requests?” Follow-up clarification is useful, but record any hints so reviewers can interpret the evidence fairly.

For a SQL-focused role, use a small dataset with duplicates or missing values. Ask what each row in the result represents and how the candidate checked the output. For an infrastructure role, choose operational evidence instead; our DevOps hiring guide explains the broader skill requirements.

6. State the AI-use policy before the test

Decide whether the exercise measures unaided knowledge, tool-assisted delivery or both. Tell candidates which tools are allowed, what they must disclose and which parts, if any, must be completed without assistance. Provide comparable access to required tools. Do not change the policy after receiving a submission.

If AI assistance is allowed, assess how the candidate checks its output. Ask which suggestions they rejected, which tests they ran and what risks remain. GitHub’s responsible-use guidance warns that generated code can be incorrect or insecure and requires review and testing. Our guide to AI-assisted code review explores that review workflow in more detail.

Keep real customer data, credentials and proprietary code out of the exercise. Do not treat an AI detector, writing style or a polished commit history as proof of misconduct. Where authorship is unclear, use a focused explanation and modification task under the disclosed rules, then document what you actually observed.

7. Pilot, calibrate and review the assessment

Ask engineers who did not write the exercise to try it. Check setup friction, ambiguous instructions and whether the time limit is realistic. Have two reviewers score the same sample independently, compare their reasoning and revise criteria that produce inconsistent interpretations.

For US hiring, EEOC guidance on employment tests addresses job relevance, discriminatory effects and reasonable accommodation. Requirements differ by jurisdiction. Work with your HR or legal adviser on the process; a technical rubric alone does not establish compliance.

Over time, review completion rates, candidate feedback and reviewer disagreement. Where appropriate and lawful, compare assessment evidence with later job performance, accounting for role differences and support after joining. Small samples and changing tasks limit the conclusions you can draw. Do not label a homegrown test “predictive” simply because it feels realistic.

If you need help filling an engineering role, Powercode’s IT staffing and talent acquisition services are a starting point. Share the role and required outcomes so we can discuss the relevant hiring support.

Frequently asked questions

How long should a developer assessment test take?

Use the shortest exercise that produces the evidence you need. The 60-minute task and 20-minute discussion suggested here are a pilot design, not an industry standard. Test the scope internally, disclose the limit and assess unfinished work fairly.

Should candidates be paid for a technical assessment?

Agree compensation in advance for substantial exercises and check local requirements. Do not assume that a short task is automatically exempt from payment rules. Keep assessment work separate from commercially useful production work.

Should developers be allowed to use AI?

Allow it when tool-assisted work is what you need to assess, with clear disclosure and verification expectations. If unaided knowledge matters, define a separate, bounded component and explain the restriction before the assessment.

Can one coding test determine whether to hire someone?

No single exercise covers the whole role. Combine its evidence with a structured interview and other relevant checks. Document gaps and disagreements rather than letting one score replace the hiring team’s judgment.

How do you keep assessments consistent across candidates?

Use equivalent tasks, the same stated criteria, consistent follow-up questions and documented accommodations. Calibrate reviewers on sample submissions, record hints and avoid rewarding extra unpaid time or unnecessary complexity.