A bad technical test does two things at once: it lets weak engineers through and it scares strong ones away. Both are expensive. The strong engineer with three offers will not spend eight unpaid hours on a contrived puzzle, and the weak engineer will happily grind a LeetCode problem that has nothing to do with your actual work. A good test is short, looks like the real job, and tells you something a resume cannot. Designing one is less about difficulty and more about relevance.
Key Takeaways
- Test the job, not trivia. The task should resemble work the person would actually do.
- Respect their time. A senior engineer with options will walk from a long unpaid test.
- Watch the reasoning, not only the answer. How they think is the signal.
- Pay for anything substantial, and keep the whole thing under a few hours.
Make It Look Like the Real Job
The single most useful principle is relevance. If the role is building product features against an API, the test should be a small version of that, not an algorithms brain-teaser. Relevance does two things. It predicts on-the-job performance far better than abstract puzzles, and it respects the candidate enough that good people are willing to do it. A test that mirrors the work also lets a strong engineer show judgment: what they choose to build, what they leave out, how they handle the ambiguous parts. That is exactly what you are trying to see and cannot get from a resume.
Respect Their Time, or Lose the Best People
The best engineers are the most in-demand, which means they are the least willing to spend a weekend on your unpaid assignment. Keep any take-home to a couple of hours of real work, be explicit about the time budget, and tell them not to gold-plate it. If the task genuinely needs more than that, pay for it as a small contract, which also lets you see how they work when it counts. The alternative to respecting their time is a pool quietly filtered down to the people who had nothing better to do.
| Do | Avoid |
|---|---|
| A small slice of the real work | Abstract algorithm puzzles |
| A clear 2-3 hour time budget | Open-ended "however long it takes" |
| Pay for anything substantial | 8-hour unpaid assignments |
| Grade reasoning + tradeoffs | Grade only pass/fail on output |
A Concrete Version
A team kept losing senior candidates and blamed the market, until they looked at their own test: a six-hour, unpaid, from-scratch build of a mini app with a spec longer than the job description. The people who finished it were mostly juniors with time to spare; the seniors thanked them and took other offers. They replaced it with a two-hour task using a real snippet of their own codebase, a small feature to add with an intentionally ambiguous requirement, and a live thirty-minute walkthrough of the choices. The senior candidates started finishing it, because it respected their time and let them show judgment, and the hires improved immediately.
The Honest Counterpoint
You can also under-test and hire on charm. Trimming the assignment does not mean skipping the evaluation, and a friendly conversation is not a substitute for seeing someone actually build something. The goal is a short, relevant, respectful test, not no test. And relevance can be taken too far into "do our real backlog for free," which is its own red flag to candidates. The line is a small, self-contained, representative task that you would be comfortable being on the other side of. If you would resent doing it, so will they.
Frequently Asked Questions
How long should a technical test be?
Aim for two to three hours of real work at most, and say so explicitly. Anything genuinely longer should be a paid contract, both to respect the candidate and to see how they work for real.
Should the test be take-home or live?
Both have a place. A short take-home shows how someone works unhurried; a live session shows how they reason and handle the unexpected. A small take-home plus a live walkthrough of it is a strong combination. See take-home vs live coding interviews.
What am I actually grading?
The reasoning as much as the result: the tradeoffs they made, the questions they asked, what they chose not to build. A clean output from someone who cannot explain their choices tells you less than a rougher one from someone who can.
The Bottom Line
Design the test around the real job, keep it short enough that strong engineers will actually do it, pay for anything substantial, and grade the reasoning, not only the output. A relevant, respectful test predicts performance and attracts the people you want, instead of filtering down to whoever had a free weekend. For what to look for once they pass, see how to verify a senior engineer. See available engineers.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
