How to test coding skills without LeetCode

Four alternatives that work

1. Debugging exercise — a small working program with a seeded bug.
2. Extension task — add one feature to code the candidate has not seen.
3. Code review — hand them a flawed pull request and ask what they would say.
4. Time-boxed take-home — two hours maximum, with a follow-up conversation.

1. The debugging exercise

Give the candidate a program of two or three hundred lines that does something comprehensible, with a bug that produces wrong output rather than a crash. Ask them to find and fix it. This is the closest a 45-minute exercise gets to the actual job: orienting in unfamiliar code, forming a hypothesis, narrowing it down. Score the method, not the time — a candidate who bisects systematically and takes thirty minutes is better than one who guesses correctly in five.

2. The extension task

Same setup, different ask: add a small feature. You learn whether they follow the existing conventions or impose their own, whether they notice the test suite, and whether they ask about the requirement before building. The most revealing part is often what they do with the ambiguity you deliberately left in the specification — strong candidates surface it, weaker ones guess and build.

3. The code review

Give them a pull request with three or four deliberate problems of different severity: one genuine bug, one performance issue that will only matter at scale, one naming or clarity problem, and one thing that is merely a matter of taste. Ask what they would comment. This is excellent for senior roles because it tests prioritisation and tone at once — you find out whether they can distinguish a blocker from a preference, and how they would say so to a colleague.

4. The time-boxed take-home

• Two hours, honestly. If it takes you two hours it will take a candidate with a job and a family four. Build it yourself first and then halve the scope.
• Pay for anything longer, or do not ask. A long unpaid take-home selects for people with spare time, which is not a job requirement.
• Always follow up in conversation. Ask them to walk through a decision and extend it live. This is also the cleanest way to handle the question of who wrote it.
• Give the grading criteria with the task. Candidates who know you care about tests and not about CSS will produce something you can actually assess.

Scoring consistently without a puzzle's right answer

The usual objection to these formats is that puzzles are easier to grade. That is true only because a puzzle grades itself — badly. Write the rubric first and the problem disappears: define what a 1, 2, 3 and 4 look like for decomposition, verification, readability and communication, then apply them to whichever format you chose. The rubric, not the format, is what makes scoring consistent.

When an algorithm question is the right choice

There are roles where this work is the job — systems where a complexity mistake is an outage, or domains built on real algorithmic problems. If that is yours, ask directly, and ask about problems from your actual domain rather than from a puzzle site. The argument here is not that algorithms are unimportant; it is that for most product engineering roles a puzzle measures preparation for puzzles.

What this changes about your candidate pool

Expect the shape of your pipeline to shift. Candidates who have drilled hundreds of problems will do slightly worse; experienced engineers who have not interviewed for six years will do noticeably better. If most of your pipeline comes from new graduates, a familiar format may genuinely be fairer; if you are hiring senior engineers who are not actively practising, puzzles are quietly filtering out the people you want. See what to look for in a coding interview.

Where Interviewer Mode fits

Disclosure: we make CoPilot Interview, which includes Interviewer Mode for the hiring side and a real-time assistant used by candidates. We have an interest in you using the first, and our view of the second is that interviews should be designed to measure something an assistant cannot fake. Weigh the advice below accordingly.

Frequently asked questions

How do you test coding skills without LeetCode?

Four formats work well: a debugging exercise in unfamiliar code, a small extension to a working program, a code review of a deliberately flawed pull request, and a strictly time-boxed take-home with a follow-up conversation. Each tests something closer to the job than an algorithm puzzle.

Are take-home assignments better than coding interviews?

They test different things and have a real cost. A take-home shows what someone produces with time and tools, which is closer to the job, but it is unpaid work that selects for candidates with spare hours. Keep it to two hours, pay for anything longer, and always follow up in conversation.

Do algorithm interviews predict job performance?

Weakly for most product engineering roles, where they largely measure recent puzzle practice. They are defensible where algorithmic work genuinely is the job. Even then, questions drawn from your own domain predict better than puzzle-site problems.

How do I grade a coding exercise without a single right answer?

Write the rubric before the first candidate: define what weak, adequate and strong look like for decomposition, verification, readability and communication. Puzzles feel easier to grade only because they grade themselves, and they grade the wrong thing.

How long should a take-home assignment be?

Two hours at most, and build it yourself first — whatever it takes you, a candidate with a job will take roughly double. Anything longer should be paid, and should come with the grading criteria so the candidate is not guessing at what you value.