Most teams still start hiring developers by skimming CVs and LinkedIn profiles. You look for the right buzzwords, familiar company names, and maybe a degree. Then you reject 90% of applicants before seeing a single line of their code.
That workflow feels efficient, but it’s a terrible signal. You’re optimizing for writing a good CV, not for writing good software.
There’s a much better way: move your filters from paper credentials to real code and code reviews that look like the work you actually do.
Define the work before you define the filter
Before changing your process, clarify what “real work” means for the role you’re hiring for. That sounds obvious, but many teams skip it and fall back to generic leetcode questions or fuzzy “culture fit” chats.
Write down, in one page or less, what this person will actually do in their first 90 days:
- What kind of code will they write? (APIs, front-end UI, data pipelines, infrastructure-as-code?)
- How will they collaborate? (PR reviews on GitHub, pair programming, async RFCs?)
- What constraints matter? (performance, readability, security, maintainability, legacy systems?)
- What seniority-level behaviors do you expect? (owning a feature, mentoring, scoping work?)
Turn those into 4 – 6 concrete behaviors you want to see in your hiring process. For example:
- Can break down a vague feature into testable chunks.
- Writes code that another engineer can understand and extend.
- Uses version control and code review like a professional.
- Asks clarifying questions instead of guessing requirements.
These behaviors, not CV keywords, become your new filter criteria.
Ask for real work samples instead of polished CVs
Once you know what good looks like, your first filter can be a work sample, not a resume. The goal is to see some real code in its natural habitat.
Give candidates a simple menu and let them pick what suits them best:
- Existing repositories: Personal projects, open source contributions, or a stripped-down version of something from a past job (with all sensitive stuff removed).
- Code snapshots: A gist or archive showing a couple of files that represent their typical work.
- Small fresh exercise: A focused task that takes 60 – 90 minutes, built to resemble your actual stack and problems.
Make this explicit in your job description:
“Instead of a formal CV, please share: (a) links to any representative code, or (b) a short coding exercise we’ll send you. We care about how you solve real problems, not how your CV looks.”
This alone will change who applies. You’ll get more doers and fewer professional CV polishers.
Turn your first screen into a fast code review
Replacing CV filters doesn’t mean creating a huge new step. The first screen can be a 10 – 15 minute code review instead of a 10 – 15 second CV skim.
Set up a simple, repeatable workflow:
- Standardized review checklist. Create a short checklist aligned with your earlier behaviors. For example:
- Is the code readable without the author present?
- Are there basic tests or at least testability in mind?
- Is the design reasonable for the problem size?
- Does the commit history (if available) show iterative thinking?
- Time-box your review. Reviewers get 15 minutes per candidate, no more. You are not doing a deep audit; you’re checking if it’s worth talking.
- Score simply. Use a 3-point scale for each checklist item: clear yes / maybe / no. Avoid fine-grained 10-point systems that pretend to be scientific.
- Decide and move. If you have more than one “clear no”, reject with a short, respectful note. If you have mostly “yes” with some “maybe”, move them forward.
Two reviewers per candidate is ideal to reduce individual bias. If that’s too expensive, rotate reviewers and occasionally cross-check to keep standards aligned.
The result: instead of rejecting on school names and job titles, you’re selecting on actual code quality and problem solving. The noise drops dramatically.
Use collaborative reviews to see how they think, not just what they wrote
Once a candidate passes the quick code screen, the next stage should mirror how your team actually works: a collaborative code review or pairing session.
There are two practical patterns that work well.
1. Live review of their own code
Ask the candidate to walk through a small piece of their own code in a call. You share screen on a diff or file, and run a normal review conversation:
- “Why did you choose this approach?”
- “If this had to handle 10x more traffic, what would you change?”
- “How would you make this easier for a teammate to modify later?”
You’re not looking for the “right” pattern; you’re watching:
- Can they explain trade-offs?
- Do they acknowledge weaknesses in their own code?
- Can they respond calmly to critique and suggestions?
This is far closer to daily work than whiteboard trivia.
2. Short, constrained pairing exercise
If the candidate doesn’t have shareable code, or you want to see them in your environment, use a tiny pairing exercise:
- 60 minutes max, in a realistic language and framework.
- Clear, modest scope: e.g., extend an existing API, fix a bug, or refactor a messy function.
- Access to normal tools: docs, Google, tests.
Have one engineer pair with the candidate and intentionally play the role they would play at work: colleague, not examiner. What you’re testing:
- Do they ask clarifying questions before coding?
- Do they narrate their thinking enough that others can follow?
- Do they respond well when the pairing partner suggests alternatives?
Document observations against your behavior list immediately after the call while memory is fresh.
Minimize bias and candidate pain while you do this
Real work assessments can still be unfair or heavy if you’re not careful. A few guardrails make the process sustainable for both sides.
- Pay for substantial time. If you expect more than ~2 hours of work (e.g., take-home plus review), compensate candidates for the time. It sends a strong signal that you respect their effort.
- Be explicit on expectations. Tell candidates the exact steps, estimated time, and what you’re evaluating. “We expect this exercise to take around 90 minutes; we’re looking for clarity of thought, not a production-ready system.”
- Use the same rubric for everyone. Score each stage against the same 4 – 6 behaviors. Don’t improvise new criteria mid-process because a candidate “feels off”.
- Decouple identity from code where possible. For the first code screen, reviewers can see only the code snippet and a candidate ID. This won’t remove all bias, but it cuts down on it.
- Close the loop with feedback. Even a 3-line note on why you’re passing is better than silence and teaches your own team what you value.
Replacing CV filters with real work samples and code reviews is not about adding complexity; it’s about swapping weak, noisy signals for strong, relevant ones. When you select on how people actually write and discuss code, you surface candidates who will thrive in your environment, not just look good on paper.
Teams that make this shift consistently report fewer bad hires, more pleasant interviews, and a broader range of backgrounds in their engineering group. If you want to find developers who match how your team really works, start centering your process on real code, and consider signing up for free on unicorn.io to tap into candidates who are ready to be evaluated on the work that actually matters.
