Here’s something almost every engineering manager learns the hard way: a polished software developer resume tells you almost nothing about whether someone can actually do the job. You’ve probably lived through this yourself – a candidate with a perfect list of frameworks and five years at recognizable companies who fumbles a basic problem, sitting right next to someone with a thin, unremarkable resume who turns out to be genuinely brilliant once you watch them work. Technical hiring built entirely around resume screening is, frankly, a coin flip.

That’s not a knock on recruiters or hiring managers. It’s just how resumes work – they’re marketing documents, not performance data. If you want to know what a developer can actually do, you have to look somewhere else.

Why the Resume Was Never Built for This Job

A resume is designed to get someone past the first filter, not to prove capability. It lists technologies a candidate has touched, not how well they used them, how they think under pressure, or how they handle a messy, half-specified problem – which, let’s be honest, is most of what real engineering work looks like.

Hiring a developer badly is expensive too. Industry estimates put the cost of a bad technical hire somewhere between half and double that person’s annual salary once you factor in lost productivity, team disruption, and the cost of starting the search over. That’s a strong argument for spending more effort verifying skill before the offer stage, not less.

If you’re building or refining your broader hiring funnel, our earlier post on how to hire software developers covers the sourcing and process side of this in more depth. This post focuses specifically on the evaluation part – what to actually look at once a candidate is in front of you.

Start With Their Actual Work, Not Their Job Titles

Before you even get to a formal assessment, there’s a simpler signal available: what has this person actually built? A developer’s code is, in a very real sense, a truer resume than the document they submitted.

What to Look For in a GitHub or Portfolio Review

• Commit history and consistency – not just volume, but whether contributions look sustained and thoughtful rather than a single hurried burst before applying.
• Code documentation and structure – clear commit messages and reasonable project organization say a lot about how someone will work inside a team.
• Real usage – did the project solve an actual problem, and did anyone besides the developer use it? A polished personal project nobody else touched tells you less than a scrappy one that’s genuinely in use.
• Pull request behavior – how someone responds to code review feedback is often a better predictor of team fit than the code itself.

Not every strong developer has a public portfolio, especially those who’ve spent their careers on proprietary codebases. That’s fine – it just means this step is a bonus signal, not a hard requirement.

Rethink the Take-Home Test for the AI Era

Take-home projects used to be one of the more reliable ways to see how someone codes without the pressure of a live whiteboard. That’s gotten more complicated. A large share of candidates now use AI coding assistants to complete take-home assessments, and application fraud involving AI-generated work has risen sharply in recent years. If a candidate can complete your take-home project with a coding assistant doing most of the thinking, you’re no longer measuring what you think you’re measuring.

The fix isn’t banning AI tools – most working developers use them daily, and refusing to use them at all is now arguably a productivity disadvantage, not a virtue. The smarter move is changing what you evaluate.

How to Adjust Your Technical Assessment

1. Allow AI tools openly, and ask candidates to narrate their decisions. What did they accept from a suggestion, what did they modify, and why? Judgment about when to trust or override an AI suggestion is itself a real skill worth measuring.
2. Add a live component that’s hard to fake. No AI assistant can convincingly walk an interviewer through a system design tradeoff or explain a past technical decision in real time. Live conversation remains one of the most AI-resistant signals you have.
3. Ask directly about AI usage in their actual work. A simple prompt – “tell me about a time an AI suggestion was wrong, and how you caught it” – tends to separate candidates who use these tools thoughtfully from those who just accept whatever gets generated.

Consider a Paid Trial Project

If you have the flexibility, a short paid trial project is one of the most reliable ways to evaluate a developer – arguably more useful than any interview. A well-scoped one-to-two-week engagement, paid at the candidate’s normal rate, shows you how someone actually works: how they communicate, how they handle ambiguity, and whether the quality holds up outside an interview setting. Plenty of developers who interview brilliantly turn out to work inconsistently, and the reverse is just as common – people who are visibly nervous in interviews but produce excellent, reliable work once they’re actually building something.

This won’t be practical for every hiring situation, particularly high-volume roles, but for senior or high-stakes positions it’s worth the extra time.

Build a Structured, Multi-Stage Process

A scattered process – one technical question here, a vague culture chat there – makes it easy to miss real signal and easy for bias to creep in. A more structured funnel tends to work better:

1. Recruiter or initial screen – confirm baseline fit, expectations, and logistics.
2. Technical deep-dive – a conversation (not just a test) about past projects, decisions made, and tradeoffs considered.
3. Practical assessment – a take-home or live coding exercise, adjusted for AI-tool realities as above.
4. Team or culture conversation – technical ability alone doesn’t guarantee someone will collaborate well or communicate clearly under pressure.

Each stage should measure something different. If your technical deep-dive and your practical assessment are testing the same thing, you’re spending time without adding signal.

Don’t Skip Soft Skills and Collaboration

Strong technical output from someone who can’t communicate clearly, take feedback, or work well with the rest of the team creates its own kind of expensive problem down the line. Ask about how a candidate has handled disagreement over a technical decision, or how they’ve explained something complex to a non-technical stakeholder. These questions are unglamorous, but they predict day-to-day team friction better than almost anything else in a standard interview.

Where This Connects to Your Broader Hiring Strategy

Evaluating developers well doesn’t happen in isolation – it’s shaped by the same broader shifts affecting all of technical recruitment right now, from skills-based hiring to the erosion of trust in resumes generally. Our recent piece on IT recruitment trends every CTO and HR leader should know covers those shifts in more detail, and if you’re also seeing strong candidates disappear at the offer stage, our post on why candidates reject job offers is worth a read too – a great evaluation process doesn’t help much if candidates drop out before you get to make the offer.

If you’d rather have a team that already lives in this problem day to day, our services and solutions pages outline how we support technical hiring across different industries, and you can always get in touch to talk through your specific hiring challenges.

Conclusion

A software developer resume can get someone through the door, but it can’t tell you whether they’ll actually perform once they’re on your team. The better signals – real project work, adjusted technical assessments that account for AI tools, paid trial projects where possible, and a structured multi-stage process – take more effort upfront. They also save you from the far more expensive problem of a bad hire discovered three months too late.