Most teams still start hiring by skimming CVs for keywords and logos. It feels efficient. It is also where you quietly lose many of your best developers.
Stronger engineers often have unusual paths, messy stacks of side projects, or skills that don’t map cleanly to your job description. Keyword CV filters miss them completely. Meanwhile, candidates who look perfect on paper can stumble as soon as you put a real codebase in front of them.
A better approach is to move your first filter from resumes to real work samples and structured code review. That sounds heavy, but it doesn’t have to be. Done right, it is faster than traditional screening and much more predictive of how someone will perform on your team.
Shift your first filter from paper credentials to concrete work
The biggest mindset change is simple: treat the CV as supporting context, not the primary filter. Your first question becomes, “Can this person solve the kind of problems we actually have?”
To do that, you need a standard way to look at real work for every candidate. Think in three buckets, in this order of preference:
- Existing public work: GitHub, GitLab, open source contributions, technical blogs, talks, or a portfolio site.
- Candidate-provided samples: a small codebase or snippet they’re proud of and allowed to share from previous roles or side projects.
- Short, targeted work sample exercises: custom tasks you send when there’s nothing else to review.
Your goal is not to find a perfect, production-grade project. You want something that forces you to answer: did this person write real code, make real decisions, and ship anything resembling production work?
Practically, change your application flow so that every candidate can either link to existing work or opt in to a short exercise later in the process. Make this explicit in the job post so serious engineers know you care about actual craft, not just credentials.
Design work samples that look like a thin slice of the real job
Most “coding challenges” fail because they are either toy puzzles or overlong take-home projects. You want neither. Aim for a thin slice of the real role that can be reasonably completed in 60 – 90 minutes of focused work.
Use these constraints when you design your work samples:
- Mirror your stack and problem domain: If you build backend APIs in Go, the exercise should involve a tiny API in Go, not reversing a linked list in pseudocode.
- Force trade-offs: Good engineers constantly trade speed, simplicity, and correctness. An example: “Extend this existing endpoint to support pagination and basic filtering, and outline how you’d secure it in production.”
- Provide just enough scaffolding: Give them a minimal repo with a README, a basic project skeleton, and fake data. The task is to change or extend it, not bootstrap everything from scratch.
- Cap the time: Tell candidates up front: “We designed this for 60 – 90 minutes and will evaluate based on approach, not completeness.” This reduces anxiety and levels the playing field for candidates with less spare time.
For example, for a mid-level backend role you could send a small repo with:
- An in-memory API that returns a list of items.
- Very basic tests.
- A brief description of performance constraints (e.g. expected data size, request volume).
The task: add filtering and pagination, write at least one new test, and describe in a short README section what you’d change to support 100x traffic. That’s enough to reveal how they read code, extend it, and think about scale without asking for a full weekend.
Make code review your main signal, not an afterthought
Looking at work samples only helps if you know what you’re looking for and review them consistently. Treat this the way you treat production code review: with a checklist and clear expectations.
Agree as a hiring team on 5 – 7 concrete signals to score for each submission. For example:
- Problem understanding: Did they actually solve the problem you asked, or something adjacent?
- Code clarity: Is the code readable, with sensible naming and structure?
- Edge cases: Did they consider failure modes and non-happy paths?
- Testing approach: Not just test quantity, but whether the tests reflect realistic scenarios.
- Design trade-offs: Do their choices make sense given the constraints you described?
- Pragmatism: Did they over-engineer or under-engineer relative to the task?
Score each signal on a simple scale (e.g. 1 – 4) and write one or two sentences of justification. Then make a decision rule: for example, move forward only if they score at least “3” on problem understanding and clarity, and the overall average is 2.5 or higher.
Importantly, keep the bar consistent across seniority but change what “good” looks like. A senior engineer’s submission should show stronger abstraction, more awareness of long-term maintenance, and better communication in comments or documentation, even if the task is similar.
Where possible, run a short synchronous review with the candidate: spend 20 – 30 minutes walking through their solution together. Ask questions like:
- “What trade-offs did you consider when you chose this approach?”
- “If you had another half day, what would you improve first?”
- “How would this change if we needed to support multi-tenant customers?”
This conversation often tells you more about how they think and communicate than the code itself.
Operationalise this so it’s lighter than CV keyword hunting
The biggest fear with work samples is that they will slow everything down. In practice, you can make this leaner than your current resume-heavy process with a few tweaks:
- Standardise templates: Create one or two reusable exercises per role type (backend, frontend, data), with versioned improvements over time. Avoid custom one-off tasks unless you’re hiring for a truly unique role.
- Batch reviews: Schedule 2 – 3 short review blocks per week for your hiring engineers. Reviewing five similar submissions in an hour is much faster than context-switching over random CVs.
- Use an intake form instead of manual CV triage: Ask candidates for links to GitHub, blogs, or projects and a short description of their most relevant work. Use those answers plus a quick scan of their background to decide who gets the exercise.
- Set clear expectations with candidates: Be up front about your process and timelines. Engineers appreciate “We don’t do brainteasers; we look at real work. Here’s exactly what to expect.”
- Continuously tune the exercise: After every hiring cycle, review where candidates dropped out, how predictive the exercise scores were, and whether senior folks felt the task was worth their time. Adjust scope accordingly.
Over a few cycles you’ll find that you’re spending less time debating CVs and more time having high-quality conversations with candidates who have already shown their working style.
Replacing CV filters with real work samples and structured code review won’t just improve your signal; it will make your hiring process feel more honest to the engineers you want to attract. They get to show how they actually build software, and you get clearer evidence before you invest in full interview loops. If you want a steady stream of developers who value this kind of practical evaluation, sign up for free on unicorn.io and make real work the centre of how you hire.
