How to screen developers without a coding test

Short answer: to screen developers without a coding test, replace the puzzle with a work sample that already exists: code the candidate wrote and others accepted. Read their merged pull requests, ask them to explain one change in detail, then check the claims in a structured conversation. For finalists, add a short paid exercise tied to your real work.

Some experienced developers refuse unpaid tests, and puzzles are now easy to solve with AI assistance, so a passing score tells you less than it used to. This guide covers a screening process that needs no test, and the cases where a test is still the right tool.

Why teams look for alternatives

• Candidate drop-off. Experienced developers often have other offers and decline several hours of unpaid work.
• Puzzle relevance. Algorithm puzzles rarely look like the job.
• AI. Tests done at home can be completed with an assistant. Karat's co-founder has said around 80% of candidates use LLMs on tests, reported here. It is one industry claim, not a measured fact, but the direction is clear.
• Cost. Test platforms typically sell annual bundles. HackerRank's Starter plan, for example, was listed at $990 a year for 60 attempts, which is a lot for a company hiring two people.

None of this makes coding tests bad. It means they are one option among several. See the side-by-side comparison.

The no-test screening process

Step 1: Read the work that already exists (10 minutes)

A work sample is a piece of real output you can judge. Developers with public code have already produced many.

• Open the GitHub profile. Skip stars and green squares; they measure activity, not quality.
• Look at merged pull requests to projects the candidate doesn't own. Someone else approved that code.
• Look at the code reviews they gave. They show judgment.
• Check for sustained work over months, not one burst.

The full method is in how to evaluate a developer's GitHub profile.

DevEval automates this step: it reads only code the candidate wrote, says what it could not see, and suggests interview questions about their own changes.

If there is no public work, move to Step 2 and ask them to describe a past project. Private work is common and says nothing bad about a candidate.

Step 2: A 30-minute screening call

Ask about their work, not about trivia.

• "Walk me through this change you made to project X. What was the problem?"
• "What did the reviewer ask you to change, and did you agree?"
• "What would you do differently?"
• "What part of this did someone else do?"

You are checking whether the candidate understands what they shipped. Real authors answer with specifics and trade-offs. See how to interview a developer when you're not technical for scoring answers without knowing the language.

Step 3: A technical conversation with an engineer (45 to 60 minutes)

An engineer reads the same work and goes deeper: design choices, failure cases, how the candidate would approach a problem from your product. This is a conversation about real code, not a quiz. If you have no engineer, rent one for an hour.

Step 4: An optional paid exercise (finalists only)

For the last two or three candidates, offer a short, paid piece of real work: review a pull request from your codebase, fix a small bug, or write a short design note. Keep it to two or three hours, pay for the time, and agree the scope upfront. Paying keeps the exchange fair and shows you respect their time.

What to look for: green and red flags

Green flags	Red flags
Merged changes to other people's projects	Only forks of tutorials with no changes
Thoughtful pull request descriptions	Cannot explain their own listed project
Replies to feedback with changes or reasoned pushback	Credits "we" for everything and can't say what they did
Work spread over months or years	One burst of activity just before applying
Honest about what they didn't build	Claims inconsistent with the code or with later answers

Treat flags as prompts for questions. One red flag is rarely a reason to reject.

When a coding test is still the right choice

A test or exercise beats a profile review in these cases:

• High-volume hiring, where you need a consistent filter for hundreds of applicants.
• Junior and graduate roles, where candidates have little real work to show.
• Roles where public evidence is unlikely, such as people from companies with strict private code, security or finance work.
• Regulated or high-stakes roles, where you need a documented, repeatable assessment.

In these cases, a good test platform gives you structure that a profile review can't. The strongest processes mix methods: a quick work-sample review first, then a conversation, then a targeted exercise.

Limits of a no-test screen

• Private work is invisible. A developer who works in closed repositories looks empty on GitHub. Don't confuse that with weak.
• Team code is hard to attribute. Commits show who typed, not who designed.
• Public work favours people with spare time. Parents, carers and people with demanding jobs often have less public code. Don't make a public profile a requirement.
• Evidence gets old. Check how recent it is.

Be fair to candidates

• Tell them you will look at their public code and what you are looking for.
• Offer an alternative for people without public work.
• Use the same process for everyone.
• Make the report or your notes one input to a human decision. Never auto-reject on a score.

Checklist

• Read 2 or 3 merged PRs or a described past project
• Wrote questions about specific changes
• Told the candidate how you screen
• Ran a 30-minute call focused on their own work
• Had an engineer do a conversation about real code
• Used a paid exercise only for finalists
• Documented the reasons for each decision

You can start for free: DevEval has a basic report with no payment, and the methodology explains what it reads.

Frequently asked questions

Is it legitimate to hire without a coding test? Yes. Many companies use work samples, conversations and paid trials. A test is a tool, not a requirement.

Won't candidates claim others' code as their own? Some will. That's why the conversation matters: asking about trade-offs and mistakes in their own changes quickly shows who wrote what.

What about candidates with a blank GitHub? Ask about private work, offer a short paid exercise, and don't penalise the empty profile.