Take Home Coding Tests: Yes, No, and How to Make Them Fair

# Take Home Coding Tests: Yes, No, and How to Make Them Fair

Take home coding tests are assignments given to engineering candidates to complete outside the interview. Done well, they reveal real problem-solving judgment, code quality, and architecture instincts that a one-hour whiteboard session cannot. Done badly, they waste hours of a candidate's time, filter out experienced engineers who decline them on principle, and produce work that the interviewer cannot evaluate fairly. The question is not whether to use them but how.

What you need to know

• Senior engineers increasingly decline take home tests that exceed two to three hours, especially for early-stage companies with no brand recognition
• A take home test that reveals architecture thinking is worth doing; one that tests algorithmic puzzles is not
• Paying candidates for their time, even a small amount, signals that you respect the time investment and significantly improves completion rates
• The follow-up conversation is more valuable than the test itself; the test is just the basis for the conversation
• AI tools mean candidates can complete most take home tests faster than before; design tests that are hard to complete well with AI alone

The core argument

The case for take home tests is that they show you the actual work. A well-designed take home test reveals how a candidate structures code, what tradeoffs they make, how they handle edge cases, and whether their documentation habit is real. None of those things are visible in a 45-minute interview. For a role where code quality and architecture judgment directly affect the product, that signal is worth the friction of asking a candidate to do real work.

The case against them, or at least against badly designed ones, is the time cost and the selection effect. A take home test that takes eight hours to complete seriously tells your candidates that you are willing to consume a full working day of their time before you have committed to interviewing them. Senior engineers with multiple options will not spend eight hours on your test. They will spend it on a project where they are already being paid. The candidates who complete eight-hour tests are often the ones who have fewer options, not the ones you most want to hire.

The design principle I use is: the test should take two hours to complete at a reasonable level and four hours to complete excellently. Give the candidate this estimate explicitly. Make the task realistic to the actual work of the role. A CRUD API with auth and tests is more useful than a binary search tree implementation. The follow-up conversation after the test is where the real interview happens: "Walk me through the tradeoffs you made here. What would you do differently with another hour? What did you deliberately leave out?" That conversation reveals more about the candidate than the code alone. I have seen candidates write mediocre code and give brilliant answers in the debrief, and vice versa.

Common mistakes

1. Making the test too long. Three hours is the practical maximum for a non-compensated take home test. Beyond that, you filter out your best candidates. If the role genuinely requires evaluating more complex work, consider a paid trial project instead.
2. Not evaluating the take home test consistently. If each interviewer evaluates the test with different implicit criteria, the process is unfair and noisy. Write an explicit rubric before the test goes out: what does "good enough" look like, and what does "excellent" look like?
3. Using algorithmic puzzles instead of practical tasks. LeetCode-style challenges measure a specific kind of practice, not the skills required for most software engineering roles. A take home test for a full-stack role should look like the actual work, not like a competitive programming contest.
4. Not giving candidates the option to discuss instead. Some strong candidates perform better in conversation than in written code. Offering a "code review of a real PR" or "design discussion" as an alternative to the take home test widens your candidate pool.
5. Not providing feedback when candidates complete the test. Candidates invest real time in take home tests. Providing specific feedback, even brief, when you decline someone after a take home tests your own standards, builds your reputation, and is simply the right thing to do.

Where to start

Step 1: Write the rubric before you write the test. What exactly are you evaluating? Code structure? Test coverage? API design choices? Documentation? Edge case handling? Define the criteria first, then design a test that reveals those specific things.

Step 2: Time-box the test explicitly and calibrate it yourself. Do the test yourself before giving it to candidates and note how long it takes you. Then double that time to account for candidates who are less familiar with your specific requirements. If your calibration time doubled is more than three hours, cut scope.

Step 3: Make the debrief scheduled and substantive. The debrief conversation should be scheduled in the same email as the test. "Please complete this and we will review it together in a 30-minute call." This signals that the test is a means to a conversation, not a filter to eliminate candidates without speaking to them.

Related reading

• The Senior Developer Test: Architecture, Tradeoffs, Communication
• The First Project Test: How to Trial a Developer Without Risking Everything
• Why I Stopped Asking Whiteboard Coding Questions
• How to Run a Technical Interview as a Non-Technical Founder