Engineering hiring has a pedigree problem. A familiar university, a well known former employer and a long list of technologies on a resume feel like evidence, and under time pressure they are easy to lean on. But none of them tell you whether this person can take a vague requirement, break it into sensible pieces, write code a colleague can maintain, and say clearly when something is going wrong. Some of the strongest engineers have unconventional paths, and some of the most impressive resumes belong to people who were carried by a strong team. The goal is not to ignore the resume. It is to treat it as a starting hypothesis and then test the things that actually predict how someone will perform in your codebase, with your team, on your timeline.
What a resume can and cannot tell you
A resume is good at a small number of things. It shows the kinds of environments someone has worked in, the rough scale of systems they have been near, and how long they tend to stay. It is poor at almost everything else. A line that says a candidate built a payments service does not tell you whether they designed it, implemented one module of it, or maintained it after others left. A keyword list tells you what someone has touched, not what they understand. And brand names work in both directions: a large company can hide a narrow role inside an impressive title, while a small company can give an engineer far more ownership than their title suggests.
The practical move is to read the resume for questions rather than answers. Which of these projects did the candidate own end to end? What changed because of their work? Where did they make a technical decision that others had to live with? Those questions become the backbone of the first conversation, and the quality of the answers, especially the specifics about tradeoffs and mistakes, tells you far more than the document ever could. Candidates who were genuinely at the centre of the work can usually describe it in uncomfortable detail. Candidates who were adjacent to it tend to stay at the level of the resume.
Assessments that reflect the actual job
The most reliable signal comes from asking engineers to do something close to the real work. For many roles that means a short, scoped exercise: extending a small existing codebase, reviewing a pull request with deliberate flaws, or debugging a failing service with logs to read. These reveal how someone navigates code they did not write, which is most of what engineers actually do. Puzzle style algorithm questions under time pressure mostly measure practice at puzzle style algorithm questions, and they tend to filter out experienced people who have spent years shipping products rather than rehearsing for interviews.
Whatever format you choose, keep it fair and bounded. State how long it should take and respect that limit, give every candidate the same exercise, and score it against criteria written in advance: correctness, readability, testing, how they handled ambiguity, and how well they explained their choices. Follow it with a conversation where the candidate walks through their work, because the discussion is where you see reasoning, and it is also the best defence against work that was not really theirs. A design conversation for mid level and senior roles adds the other half of the picture: how the person thinks about failure, scale, cost and the people who will maintain the system after them.
Contract engineers and senior technical leaders
Contract and contingent engineering hires compress all of this. A client who needs a contractor productive within days cannot run a four stage process, and a contractor is often brought in precisely because the team lacks time to ramp someone up. That makes a tight, job specific screen more valuable, not less. A single practical session in the relevant stack, ideally touching the kind of code the contractor will meet on day one, plus a structured check of availability, rate, location requirements and any certifications, will tell a client more than several general conversations. The other thing to assess explicitly is how quickly the person gets oriented in an unfamiliar codebase and how they communicate status, because a contractor who is technically strong but silent when blocked is a common and costly pattern. A staffing partner that runs the same screen across every submission also lets a client compare candidates on one basis rather than on how well each resume was written.
At the senior end the problem changes shape. For engineering managers, principal engineers, heads of engineering and CTO searches, hands on coding tests matter less and pedigree tends to matter more in the minds of hiring committees, which is exactly where it misleads most. A strong executive search process tests the decisions the candidate has actually made: an architecture they chose and later had to revise, a team they grew or restructured, a delivery they had to reset with stakeholders, a build versus buy call and what it cost. Structured references with former peers and reports, probing the same competencies, carry real weight here. The question is not whether this person has held an impressive title, but whether the specific problems your organisation faces over the next two years are problems they have solved before, under similar constraints.
Key takeaways
- Read the resume for questions, not answers, and probe what the candidate personally owned, decided and changed.
- Use short, fair, job realistic exercises scored against written criteria, then have candidates walk through their reasoning.
- For contractors, screen for fast orientation and clear communication in the exact stack; for senior leaders, test real decisions and use structured references rather than relying on pedigree.