Shift your hiring focus from polished resumes to real developer work

Most teams still start hiring with a resume filter. That made sense when engineers followed linear careers and tech stacks changed slowly. Today it mostly rewards people who are good at formatting bullet points and guessing the right keywords.

If you want to consistently hire strong developers, you need to flip that order: look at real work first, then use the CV as a supporting document, not a gate.

Define what “real work” means for your team

Before you throw out CV filters, get specific: what kind of work will this person actually do in the first six months?

Write down 5 – 7 concrete activities, for example:

• Extend an existing service without breaking current behavior.
• Read an unfamiliar codebase and track down a production bug.
• Review a teammate’s PR and give clear, actionable feedback.
• Design a small feature end to end, including trade-offs.
• Communicate progress and risks to non-engineering stakeholders.

These become the backbone for your work-sample and code-review steps. The point is to see candidates doing the same type of thinking you’ll expect from them on the job, not solving abstract brainteasers.

Replace resume screens with a fast work-sample gate

Instead of rejecting (or accepting) candidates based on CV keywords, send a short, clearly scoped work sample to everyone who meets basic criteria (location, salary range, tech stack).

Design this work sample with three constraints:

• Time-bounded: 60 – 90 minutes max for most roles. State this upfront.
• Representative: Mirrors at least one real task you listed earlier.
• Scorable: Has an objective rubric you can apply in 5 – 10 minutes.

For example, for a backend role:

• Provide a small API with a couple of endpoints and a known bug.
• Ask the candidate to: fix the bug, add a simple new endpoint, and write one or two tests.
• Give them a basic README with setup instructions and constraints (language, frameworks).

For a frontend role:

• Provide a minimal app (e.g. a list view with dummy data).
• Ask them to: hook it up to a simple API, handle loading and error states, and add one interaction (sorting, filtering, or search).

You’re not trying to cover every dimension here. You’re answering a narrower question: “Is there enough signal in how this person works that it’s worth investing more interview time?”

Build a simple rubric so you can trust the signal

The value of work samples collapses if reviewers “go by feel.” You need a shared, lightweight rubric. Aim for 4 – 6 categories, each scored from 1 – 4 with a short description of what each level looks like.

A sample rubric for the backend exercise:

• Correctness: Does the code do what the instructions require, including edge cases?
• Code clarity: Is the code readable, with meaningful naming and minimal confusion?
• Design choices: Are the abstractions reasonable for the size of the task?
• Testing: Are there tests, and do they cover meaningful paths?
• Pragmatism: Did they respect constraints (no unnecessary frameworks, no gold-plating)?

Write one or two example notes for each score level so reviewers calibrate quickly. For instance:

• Code clarity 2: “Works but mixes responsibilities, long function, hard to skim.”
• Code clarity 3: “Mostly clean, a couple of slightly confusing names or minor duplication.”

Set a clear bar to move forward, such as “no 1s in correctness or pragmatism, average score at least 2.75.” This lets you substitute subjective CV filtering with a consistent, skill-based gate.

Use code review to test how they think with you, not just alone

A one-way work sample shows how a candidate codes solo. Your next step should show how they collaborate. A structured code-review exercise is one of the highest-signal ways to do this.

There are two good options here; you can use either or both:

1. They review your code.
2. You review their work sample together.

Option 1: Candidate reviews your code

Prepare a small PR in your usual stack (or close to it) with intentional flaws:

• A subtle correctness bug.
• Some unclear naming or confusing logic.
• A missing test for an important path.
• A minor performance or reliability concern.

Share it during a 45 – 60 minute call and ask the candidate to do a normal review. They can walk through it verbally or leave comments in your tooling if access is easy.

Score them using a similar rubric:

• Issue detection: How many of the important problems did they notice?
• Prioritization: Do they distinguish between nitpicks and serious issues?
• Communication: Are their explanations clear and respectful?
• Product sense: Do they consider user impact when judging issues?

Watch for signal like: “They missed a nitpick but caught a bug that would break billing” or “They noticed performance but completely ignored a security concern.” That tells you far more than another pass through the CV.

Option 2: Review their work sample together

Pull up the code they submitted and do a joint walkthrough:

• Ask them to explain how they approached the task before you open the editor.
• Then step through key sections and ask “What trade-off were you making here?” or “What would you change with another hour?”
• Invite them to critique their own work.

This shows you:

• How they reason about design under constraints.
• How they respond to questions and suggestions.
• Whether they can see better options once time pressure is relaxed.

Again, you’re bringing the interview as close as possible to the job: reading and discussing code with teammates.

Fit this into your existing process without slowing everything down

You don’t need a full redesign of your hiring funnel. In practice, most teams can shift to work samples and code reviews in a week by making three changes:

1. Replace CV keyword screens with a basic checklist. For example: relevant language or ecosystem, time zone overlap if needed, salary expectations. If they pass that, they get the work sample automatically.
2. Batch review work samples once or twice a week. Two engineers block 60 – 90 minutes to score everything using the rubric. No ad-hoc, late-night reviews.
3. Standardize the next step. Anyone above the threshold gets scheduled directly to a code-review call. No extra HR screening unless there’s a clear reason.

Monitor two metrics to keep this sane:

• Time to first real signal: How long from application to completed work sample and score? Aim for 3 – 5 days.
• Engineer time per candidate: For non-hired candidates, aim to keep total engineer time under 45 – 60 minutes (review plus call).

If either number drifts up, trim your exercise or tighten your basic applicant checklist. The goal is more signal earlier, not process bloat.

When you hire based on real work and thoughtful code reviews, you reduce surprises after onboarding, avoid overvaluing polished resumes, and give capable but non-traditional candidates a fair shot. You end up with engineers who can actually do the job you need, not just talk about a job they had years ago. If you want more candidates who are ready to show real work instead of just CVs, sign up for free on unicorn.io and start meeting them.