Replace resume roulette with real engineering work in your hiring

Most companies still filter developers by CVs and keywords. Years of experience, logo lists, and buzzwords end up deciding who gets a conversation. Then everyone acts surprised when strong paper candidates struggle in real work.

There’s a better way: treat the resume as a background check, and make real work samples and code reviews your primary filter.

Define the work before you define the candidate

Before you design an assessment, answer one question with the hiring manager and tech lead: “What will this person actually do in their first 90 days?”

Write out 4 – 6 concrete activities, for example:

• Extend an existing REST API with a new endpoint and tests
• Debug a flaky integration test in a CI pipeline
• Refactor a messy module without breaking behavior
• Review a teammate’s PR and give actionable feedback
• Write a small background job integrated with a third-party API

Those activities are your hiring rubric. Your assessment should simulate one or two of them in a slimmed-down form. If a task doesn’t map to a real activity, you’re probably testing trivia or leet tricks.

Design small, realistic work samples instead of generic tests

Good work samples feel like a Monday afternoon task, not a take-home midterm. Keep them small, specific, and familiar:

1. Single-sitting complexity. Aim for 60 – 90 minutes of focused effort. That’s short enough to respect candidates’ time and long enough to see how they think. If you need more depth, split into two small stages, not one giant project.
2. Use a thin slice of your actual stack. If you’re a Node shop, don’t give a standalone algorithm puzzle in Python. Provide a minimal repo: a simple service, a test suite, and a README with npm test or equivalent. Remove the yak shaving.
3. Anchor to real failure modes. Design tasks around the problems your current team actually hits: handling pagination correctly, managing time zones, avoiding N+1 queries, dealing with race conditions, etc. You’re not looking for perfection; you want to see how candidates approach tradeoffs.
4. Explicit scoring rubric. Before you send the task to anyone, write down what “great”, “good enough”, and “not there yet” look like for 4 – 6 criteria: correctness, clarity, tests, decomposition, and communication (via comments/README).

Example for a backend role:

• Provide a tiny service with user entities.
• Task: add an endpoint to return users filtered and sorted, with pagination, including basic validation and tests.
• You assess: input handling, query efficiency, simple error handling, test discipline, and basic design choices.

This tells you far more than a CV full of buzzwords or a brainteaser ever will.

Make the code review the core of the interview

The biggest mistake with take-home work is treating it as homework you mark in private. The real signal comes from walking through it with the candidate.

Structure a 45 – 60 minute code review session like a real PR review:

1. Candidate walkthrough first (10 – 15 minutes). Ask them to share their screen and explain what they did, what they left out, and why. Look for ownership: do they talk in terms of tradeoffs and constraints, or just line-by-line narration?
2. Deep-dive on one or two design choices (15 – 20 minutes). Pick a concrete spot: a function boundary, a data model, or an error handling decision. Ask, “If you had another hour, what would you change here?” You’re probing depth and pragmatism, not gotchas.
3. Collaborative improvement (15 – 20 minutes). Treat it like a pairing session: “Let’s improve this together.” Maybe it’s extracting a helper, adding test coverage, or tightening a query. Watch how they respond to feedback, navigate the code, and reason about impact.

Use a simple, consistent scoring sheet across interviewers:

• Technical fundamentals: Does the solution basically work? Are mistakes understandable vs. fundamental gaps?
• Code quality: Is the code readable and modular enough for your team’s standards, given the time?
• Testing approach: Do they think in terms of happy paths and edge cases?
• Communication: Can they explain their choices clearly and adapt when challenged?
• Collaboration: In the paired part, do they treat you like a teammate, stay open, and ask clarifying questions?

This mirroring of your actual review culture is where you see if someone will raise the bar on your codebase or quietly add risk.

Reorder your funnel so resumes are just context

To really replace CV filters, you need to restructure the funnel, not tack on another step.

A practical pattern:

1. Lightweight initial screen (15 minutes). Quick call or async questions focused on logistics (time zones, compensation expectations) and basic fit (language/stack comfort, type of work they want). Don’t get lost in career storytelling yet.
2. Primary filter: work sample plus review. Everyone who passes the initial screen gets the same small work sample. Grade consistently using your rubric. Only after reviewing the solution do you pull up the CV or LinkedIn for context and follow-up questions.
3. Resume as a risk and context check. Use the CV to explore gaps or verify patterns you saw in the code: professional level, domain exposure, scale they’ve worked at. It’s input, not the gatekeeper.
4. Team-focused final conversations. Follow with culture and collaboration rounds, ideally including another short, high-level architecture or system design discussion instead of unrelated puzzles.

If you’re worried about volume, cap how many work samples you run per week and triage based on the initial screen. Resist the temptation to fall back to keyword filtering; that’s how you end up hiring the same CV archetype over and over.

Handle fairness, time, and compensation thoughtfully

Replacing CV filters with work samples raises reasonable concerns; address them directly.

• Time burden. Limit tasks to what a busy senior engineer could do in 60 – 90 minutes. State that explicitly in the invite and hold yourselves to it by dogfooding the task internally every few months.
• Compensation. For anything beyond 90 minutes or for later-stage, role-specific projects, pay candidates a flat, fair fee. It signals respect and reduces drop-off from strong developers who are already employed.
• Reuse and IP. Never ship candidate code to production. Design fictional or heavily sanitized problems. Make it clear in writing that the exercise is for evaluation only.
• Accessibility and tooling. Let candidates use their own environment and reference materials. That’s how they work day to day, and it reduces artificial pressure.

These policies aren’t just about ethics; they directly improve your conversion rate with the developers you actually want to hire.

When you trade resume roulette for small, realistic work samples and collaborative code reviews, you hire people based on how they’ll perform in your codebase, not how good they are at keyword-stuffing CVs. You get clearer signals earlier, waste less time on mismatched interviews, and uncover strong engineers who would have been screened out on paper. If you want more candidates who are ready to be evaluated this way, sign up for free on unicorn.io and connect with developers who care about real work, not just resumes.