CV filters are easy to automate and easy to justify, but they are terrible at telling you who can actually ship production code with your team.
As a result, you reject strong developers because their titles look odd, their education is non-traditional, or their tech stack keywords are slightly off. Then you complain about a “talent shortage.”
The fix is not another ATS plugin. It is replacing resume-first filtering with simple, predictable work samples and code reviews that reflect real engineering work.
Decide what “real work” means for this role
Before you design any assessment, get uncomfortably specific about what success in the first 90 days looks like. For one backend role I hired for, we wrote:
- Own a small service end to end: read existing code, extend an API, and ship it safely.
- Debug a production-only issue from logs and incomplete reports.
- Communicate tradeoffs clearly to a product manager and another engineer.
From that, we derived concrete skills:
- Read and modify unfamiliar code in our main language.
- Reason about data flows, edge cases, and failure modes.
- Write clear, maintainable code with tests.
- Explain decisions in pragmatic, non-theoretical language.
Do this once per role. Ten minutes of alignment here simplifies every assessment decision later. If a test or question does not map directly to those skills, cut it.
Replace CV screens with a two-step work sample funnel
Instead of filtering by keywords, filter by signals from actual work. A simple two-step funnel works for most teams:
Step 1: Tiny async work sample (30 – 45 minutes)
This is your replacement for the resume screen. Everyone who is not obviously unqualified gets it.
Keep it short, focused, and close to the job. Some examples:
- Backend: You show a small API handler with a couple of bugs and missing tests. Ask the candidate to improve it, add a test, and write a short note on what they changed and why.
- Frontend: You provide a minimal component with layout and state bugs. Ask them to fix it and describe how they would make it accessible.
- Data: You share a small CSV and a messy SQL query. Ask them to clean up the query, point out a couple of data quality issues, and propose one additional metric.
Key constraints:
- Time-box it explicitly: “This should take you about 30 – 45 minutes. Do not spend more than an hour.”
- Use a simplified version of your tech stack, but do not require your exact frameworks.
- Ask for a brief written explanation of changes and tradeoffs.
You are not trying to see their best possible work, just a realistic sample under light constraints. This surfaces fundamentals quickly: code hygiene, basic debugging, attention to detail, and written communication.
Step 2: Live code review of that sample
Candidates who pass the work sample move to a 45 – 60 minute session where you review their submission together.
Structure it like a normal code review:
- Ask them to walk through their changes as if you are a teammate joining the project.
- Probe on specific decisions: “You chose approach X instead of Y. What tradeoffs were you considering?”
- Introduce one or two new constraints: “What if traffic doubled?” or “What if this input is null?” and see how they adapt.
- Invite them to critique their own work: “If you had another half day, what would you improve or refactor?”
Here, you are testing:
- How they think about code structure and tradeoffs.
- How they respond to review-style questions: defensive, collaborative, curious.
- Whether their mental model of the code is solid or fragile.
You now have two strong signals before you even care about where they worked or studied.
Make the assessments lightweight and fair
Work samples can easily turn into unpaid projects. Avoid that. A few guardrails keep the process both candidate-friendly and predictive.
1. Keep it short and bounded
- Design tasks to fit comfortably in 30 – 45 minutes, and say that explicitly.
- If you feel tempted to ask for a full feature, cut it in half twice.
- For senior roles, keep the coding short but deepen the discussion in the review: architecture, tradeoffs, unknowns.
2. Use a fixed rubric, not vibes
For each step, agree on a 3 – 5 point rubric with specific criteria. For example, for the async sample:
- Correctness: Does the code do what was asked, including edge cases?
- Code quality: Is it readable, reasonably structured, and testable?
- Testing: Are there at least minimal, relevant tests (if applicable)?
- Communication: Is the written explanation clear and concise?
Rate each from 1 – 4 with defined anchors (e.g. 1 = missing, 2 = weak, 3 = solid, 4 = outstanding). Decide pass/fail thresholds in advance. This prevents “I just didn’t get a good feeling” from dominating.
3. Blind-review where you can
For the async sample, it is trivial to hide names, schools, and employers from the reviewer. Have your coordinator or ATS strip that metadata and assign an ID. Review only the code and the short write-up.
This reduces bias and keeps you honest: if a candidate’s work is strong, they move forward regardless of whether you recognise the logos on their CV.
4. Communicate the process clearly to candidates
When you invite someone to the work sample, explain:
- Why you use work samples instead of heavy CV filters.
- Rough time expectations and what happens next.
- That the exercise reuses a simplified version of a real internal task.
You want good developers to think, “This is how I already work day to day,” not “Another abstract puzzle.” That framing itself is a differentiator in a crowded hiring market.
Fitting this into your existing hiring loop
You do not need to blow up your entire process. Thread work samples and code reviews into what you already do.
- Before: Recruiter screen based heavily on CV and brand names.
- After: Recruiter screen for basic fit (location, comp, tech stack), then send the async work sample to most candidates who clear that.
Downstream, the live code review can replace one of your generic “technical interviews.” In many teams I have worked with, the code review plus a focused system design conversation replaced two to three unstructured whiteboard interviews, while improving signal.
Track the outcomes. For each hire, ask their manager after three and six months:
- Did the work sample and code review accurately predict how they work?
- Were there surprises that suggest tweaks to the tasks or rubrics?
Iterate lightly every quarter. Treat your hiring process like a product: ship, measure, refine.
When you replace CV filters with real work samples and structured code reviews, you widen your funnel to strong, non-traditional candidates and dramatically increase the odds that offers go to people who can do the actual job. You also give developers a clearer window into how your team works, which means better matches on both sides. If you want a steady stream of candidates ready for this kind of practical assessment, create a free employer account on unicorn.io and start hiring from a pool that cares about real engineering work, not just polished resumes.
