Coding Assessment for Hiring and What to Test at Each Seniority Level
October 11, 2026 12 min read
A coding assessment for hiring is a short, realistic programming task that shows how a candidate reads requirements, writes working code, handles edge cases and explains trade-offs. The best ones mirror your team's real work, run against real test cases, and are scored with a written rubric, not gut feel.
That sounds simple, and yet most teams get at least one part wrong. They pick a puzzle because it was easy to find, they set a four-hour limit because nobody measured how long it takes, or they let each reviewer score however they like. The result is a test that filters out good people and lets lucky ones through. Below we walk through how we think about a coding assessment from the ground up: what it should measure, what changes by seniority, how long it should take, and how to keep scores consistent across reviewers.
What should a good coding assessment actually measure?
Start from the job, not from the test. Ask the hiring manager what a new engineer will do in their first ninety days, then pull out the skills that matter most. For a backend role that might be designing a small API, writing database queries that don't fall over on large tables, and handling failure cleanly. For a frontend role it might be state management, accessibility and working with an imperfect API response.
Once you have that list, a good assessment measures a handful of things, and only a handful:
- Correctness. Does the code do what was asked, including the awkward inputs? This is where real test cases earn their keep.
- Problem decomposition. Did the candidate break the task into sensible pieces, or write one long function that does everything?
- Code clarity. Could a teammate read this on a Monday morning and change it safely? Naming, structure and small functions matter more than clever tricks.
- Edge cases and error handling. Empty input, duplicates, timeouts, malformed data. Strong engineers think about these without being told.
- Testing habits. Did they write a few tests of their own, or at least describe what they'd test?
- Communication. A short written note explaining decisions and known gaps tells you a lot about how someone will work on a team.
What it should not measure: memorized algorithm trivia, typing speed, or familiarity with a niche library you could teach in an afternoon. If a skill isn't on the job description, it shouldn't carry points on the test.
Blind review on
Name and photo hidden until shortlist
88
overall
Code
93
Interview
87
Integrity
Clean
What do you test at junior, mid, senior and staff level?
The same task rarely works for every level. A junior candidate shouldn't be judged on system design, and a staff engineer shouldn't spend an hour reversing a linked list. The table below is the split we use as a starting point.
| Level | Core focus | Typical task shape | What separates strong from weak |
|---|---|---|---|
| Junior | Fundamentals, correctness, readable code | Implement one well-specified function or small feature with clear inputs and outputs | Handles edge cases, names things clearly, asks or notes assumptions |
| Mid | Independent delivery, testing, working with existing code | Extend a small existing codebase, fix a bug, add a feature with tests | Reads code before changing it, writes useful tests, keeps changes focused |
| Senior | Design trade-offs, performance, failure handling | Build a small service or module with an ambiguous requirement and a scaling constraint | Makes explicit trade-offs, handles failure paths, explains what they'd do with more time |
| Staff | Architecture, judgment, technical leadership | Review a flawed design or pull request, then implement the most important fix | Prioritizes the right problems, communicates risk clearly, balances short and long term |
Junior candidates
Keep the specification tight. Juniors are still learning to read requirements, so ambiguity mostly tests confidence rather than skill. Give them a function to implement (parse a log line, group transactions by day, validate a form payload) and a few visible test cases. Hidden tests cover the edges. You're looking for code that works, reads well, and doesn't crash on empty input.
Mid-level candidates
Mid-level engineers spend most of their time inside code someone else wrote. So hand them a small repository, a few hundred lines at most, with a bug and a feature request. This shows whether they read before they write, whether their tests are meaningful, and whether they resist the urge to rewrite everything.
Senior candidates
Add ambiguity and a constraint. For example, "build an endpoint that returns the top ten products by revenue for any date range; the orders table will grow to tens of millions of rows." There's no single right answer. A strong senior picks an approach, says why, handles the obvious failure modes and writes down what they'd change at higher scale.
Staff candidates
At staff level, the code itself matters less than judgment. A good format is a review task: give them a design document or pull request with several problems of different severity, ask them to write review comments, then implement the fix for the issue they consider most important. Pair it with a technical interview where they defend their choices.
Should the test be timed or take-home?
Both formats work. They answer different questions, and each has costs.
A timed test (usually 45 to 90 minutes in a browser) is consistent. Every candidate gets the same conditions, it's harder to outsource, and it fits into a busy candidate's evening. The downside is pressure. Some excellent engineers perform poorly with a clock running, and timed tests push you toward smaller, more contrived problems.
A take-home (usually two to four hours of real work, submitted within a few days) is closer to how people actually code. Candidates can use their own editor, look up documentation and think. The downsides are length creep, uneven effort (people with free evenings can polish more), and less certainty about who wrote what.
Here's a simple way to choose:
- Use timed tests for early screening at volume, and for junior and mid roles with well-defined tasks.
- Use take-homes for senior and staff roles, where design thinking and written explanation matter more than speed.
- Whichever you pick, follow it with a conversation about the candidate's own solution. Asking "why did you structure it this way?" and "what breaks if the input doubles?" quickly shows whether they understand the code they submitted.
Paste events
3 small pastes, from the task text
Tab switches
2 switches, longest 39 seconds
Keystroke playback
Steady typing, edits and reruns
Code similarity
46 percent with Candidate 2659 on helper code
AI-generated code likelihood
Low, style matches interview answers
Signals inform your team. They never reject a candidate on their own.
How long should a coding assessment take, and how do you respect candidates' time?
Shorter than you think. Good candidates usually have options, and a long unpaid task is a common reason they drop out. As a rule of thumb, keep timed tests to 90 minutes or less and take-homes to roughly three hours of honest effort.
The word "honest" matters. Teams routinely underestimate their own tasks because they wrote them. Before you send a task to anyone, have two engineers on your team who haven't seen it complete it cold, and time them. If they need two hours, candidates will need more, so trim the scope.
A few other habits make a big difference to candidate experience:
- Say up front what you're scoring. Share the rubric categories (not the answer key). Candidates spend effort where it counts instead of guessing.
- Set a hard scope. Write "do not build a UI" or "no need for authentication" if those aren't the point. Otherwise conscientious people build them anyway.
- State the time budget and mean it. Say that a partial solution with clear notes beats a complete one that took twice as long.
- Allow the language they're best in unless the role truly requires a specific one.
- Give feedback. Even three sentences after a rejection is more than most candidates get, and it shapes how they talk about you.
- Test later, not first, when you can. A short screening call or questionnaire before a three-hour task saves everyone time.
Why do real test cases beat algorithm puzzles?
Puzzles test whether someone has seen a similar puzzle before. That's a weak signal for most product engineering work, and it's an even weaker one now that AI coding assistants can produce textbook solutions to well-known problems in seconds.
Real-world tasks with real test cases are better on almost every axis. They resemble the job, they reward practical judgment, and they produce an objective correctness score that reviewers can't argue about. A typical structure looks like this:
Task. You're given a CSV export of subscription events (created, upgraded, cancelled) for many customers. Write a function that returns monthly recurring revenue for each calendar month in a given range. Events can arrive out of order. Some rows have missing amounts. A customer can cancel and come back.
Visible tests. Three simple cases with expected output.
Hidden tests. Out-of-order events, duplicate rows, a month with no events, a cancellation on the last day of the month, a missing amount, a large file to check performance.
Deliverable. Code, your own tests, and a short note on assumptions.
Notice what the hidden tests do. They don't trick anyone; they check the edge cases any careful engineer should consider. Two candidates can both pass the visible tests, and the hidden ones will separate them cleanly. Run the code in a sandbox against these cases automatically, and your reviewers can spend their time on clarity and design rather than checking whether the output is right.
In DeveloperHiring, the browser coding test runs candidate code against real test cases in a sandbox, in more than 30 languages, as either a timed test or a take-home. The follow-up AI technical interview then asks questions about the candidate's own solution, so a submission they can't explain stands out quickly.
What does a good scoring rubric look like?
A rubric turns "I liked it" into something two reviewers can agree on. Keep it to four to six criteria, define each level in plain words, and weight the criteria by what the role needs. Here's an example for a mid-level backend role:
| Criterion | Weight | 1 (weak) | 3 (meets bar) | 5 (strong) |
|---|---|---|---|---|
| Correctness | 30 percent | Fails most hidden tests | Passes core cases, misses one or two edges | Passes all tests, including performance |
| Code clarity | 20 percent | Hard to follow, unclear names, one long function | Readable, reasonable structure | Clean, small functions, intent obvious without comments |
| Edge cases and errors | 20 percent | Crashes on bad input | Handles common bad input | Handles bad input deliberately and explains choices |
| Testing | 15 percent | No tests | A few happy-path tests | Targeted tests for edges and regressions |
| Communication | 15 percent | No notes | Brief notes on approach | Clear assumptions, trade-offs and next steps |
Two rules make rubrics work in practice. First, each reviewer writes a one-line reason next to every score. "Clarity 2, everything is in one 120-line function" is useful; "Clarity 2" is not. Second, reviewers score independently before they discuss. If they talk first, the most senior voice in the room becomes the score.
Also decide your pass bar before you look at any submissions. A common approach is a weighted average of 3.0 or above with no criterion below 2. Writing this down in advance stops the bar from drifting when you're short of candidates or in a hurry.
How do you calibrate a coding assessment?
Calibration is how you check that the test measures what you think it measures and that your reviewers agree with each other. It doesn't need to be elaborate.
- Run it on your own team. Ask three to five engineers at the target level to take the test cold. Their scores tell you where the bar really sits. If your strong mid-level engineers can't pass, the test is too hard or too long.
- Double-score the first batch. Have two reviewers score the first ten or so candidate submissions independently. Where they differ by more than one point on a criterion, talk it through and tighten the wording of that rubric level.
- Check for useless questions. If every candidate fails the same hidden test, it may be poorly specified rather than hard. If everyone passes a criterion, it isn't telling you anything.
- Look back after hiring. After a few months, compare assessment scores of the people you hired with how they're doing. You won't get statistics from a handful of hires, but you will spot criteria that predicted nothing.
- Refresh the task periodically. Tasks leak over time. Keep two or three variants with the same rubric so you can rotate them.
Fairness belongs in calibration too. Score submissions without looking at the candidate's name, photo or background where you can, and keep the same rubric for everyone applying to the same role. DeveloperHiring scores blind to name, photo, age and gender, shows candidates which stages are AI scored along with the rubric, lets them request a human review, and always leaves the final decision to your team.
What are the most common coding assessment mistakes?
Most problems we see fall into a short list. If your current process has two or three of these, fixing them will probably do more than any new tool.
- Testing the wrong thing. A dynamic programming puzzle for a role that's mostly CRUD endpoints and integrations.
- Tasks that are too long. Eight hours of "optional" polish turns into a filter for free time rather than skill.
- No rubric, or a rubric nobody uses. Scores then depend on which reviewer picked up the submission.
- Grading only on whether it runs. Passing tests matters, but unreadable code that passes is a real cost once it's in your codebase.
- Ignoring integrity entirely, or obsessing over it. Remote tests need some signals (paste events, tab switches, similarity between submissions), but treat them as prompts for a conversation, not automatic rejections. We cover this in more detail in our guide to detecting cheating in remote coding tests.
- No follow-up conversation. A short discussion of the candidate's own code is the cheapest and most reliable check that they understand it.
- Same test for every level. Juniors drown and staff candidates get bored and leave.
- Silence after submission. Candidates who spent three hours and hear nothing remember it.
How do you fit the assessment into the rest of hiring?
An assessment works best as one stage in a sequence, not the whole decision. A typical order is: screen CVs and public code against a skill matrix, send a short async questionnaire, run the coding assessment, hold a technical interview on the candidate's solution, then check integrity signals and references before the final conversations. Each stage should answer a question the previous one couldn't.
That's the sequence DeveloperHiring runs for you, from role description to a ranked shortlist of five technically verified candidates, with scorecards and an ATS hand-off at the end. Plans use flat monthly pricing with no per-hire or success fees, which matters if you're comparing it with agency costs. If you'd rather keep everything in-house, the principles above still apply: realistic tasks, honest time limits, a written rubric, and a conversation about the code. Get those four right and you'll hire developers with far more confidence than a resume screen and a puzzle can give you.
Frequently asked questions
How long should a coding assessment be?
For timed tests, 45 to 90 minutes is usually enough to see how someone works. Take-home tasks should take roughly two to three hours of real effort. Time the task yourself by having two engineers who haven't seen it complete it cold. If they need longer than you planned, cut scope rather than asking candidates to give up a whole weekend.
Are take-home coding tests better than live coding?
Neither is better in every case. Take-homes are closer to real work and suit senior roles where design and written explanation matter. Live or timed tests are more consistent, harder to outsource and suit early screening. Many teams combine them: a take-home or timed task, then a live conversation where the candidate walks through and extends their own solution.
Should candidates be allowed to use AI coding assistants?
It depends on how your team works. If engineers use AI coding assistants daily, banning them can make the test less realistic. Either way, state the rule clearly in the instructions. The follow-up interview is the strongest check, because candidates who rely on generated code they don't understand struggle to explain or modify it when asked specific questions.
What languages should a coding assessment support?
Let candidates use the language they know best unless the role truly depends on a specific one, such as a deep Python data role or a Swift mobile role. Good engineers transfer skills between languages quickly, and forcing an unfamiliar one mostly measures syntax recall. For language-specific roles, test the idioms and libraries the job actually uses.
How do you keep coding assessments fair?
Use the same task and rubric for every candidate applying to the same role, score submissions independently and without seeing names or photos where possible, and decide the pass bar before reviewing anyone. Tell candidates what you're scoring and how long the task should take. Offering a human review on request also helps candidates trust the process.