I started tracking the patterns somewhere around candidate number two hundred. By that point I had conducted enough technical hiring conversations to notice that certain things kept showing up — not in the CVs, not in the test results, but in the texture of how people talked about their work. The specific language they used. […]
I started tracking the patterns somewhere around candidate number two hundred. By that point I had conducted enough technical hiring conversations to notice that certain things kept showing up — not in the CVs, not in the test results, but in the texture of how people talked about their work. The specific language they used. The moments they slowed down. The things they pushed back on, and the things they accepted without question.
By candidate six hundred, the patterns were impossible to ignore. And they were different from everything I had been taught to look for when hiring technical talent.
What follows is not a research paper. It is not a framework with a catchy acronym. It is a set of observations from someone who has spent years inside the process of finding, evaluating, and placing technical people — and who has learned, often by getting it wrong, what actually matters when you are trying to figure out whether someone is going to do exceptional work in a specific environment.
Take from it what is useful. Question what does not fit your experience. But read it as if the person across from you on the next screening call is not a CV walking into the room. Read it as if they are a person with a perspective on their own work that most processes are never designed to surface.
The single strongest early signal I have found when hiring technical talent is whether someone can tell you why they made specific decisions — not just what the system does, but why it was designed that way, what tradeoffs were made, what was considered and rejected.
The CV said they built a real-time data pipeline. The question is: why did you choose that architecture over a batch process? What were you optimising for? What would you do differently now? Most engineers can answer the first version of that question — they know what they built. The much smaller group who can answer the second and third version — who have genuinely reflected on the tradeoffs and can articulate why a different approach might have been better — are consistently the ones who perform well after hire.
This pattern holds across disciplines. The frontend developer who can tell you why they chose one state management approach over another, and acknowledge the limitations of that choice. The DevOps engineer who can describe the incident response failure that led them to redesign their alerting system. The team lead who can explain why they moved away from a sprint-based model and what they learned from the transition. Self-awareness about the why of technical decisions is one of the most reliable early signals in hiring technical talent that I have found.
This one surprised me early on and I kept confirming it. When evaluating candidates for technical roles, I found that the people who performed best in the role were not always the ones who knew the most coming in. They were the ones who picked up new concepts the fastest during the conversation.
You can test this directly and ethically during a technical discussion. Introduce a constraint or a change in requirements mid-scenario. Watch what happens. Does the candidate pause and recalibrate? Do they ask a clarifying question before they continue? Do they update their approach fluidly, or do they continue executing the original plan regardless?
The candidates who adapt quickly, who treat the constraint as information rather than obstacle, who can hold their current answer loosely enough to revise it when new data arrives — these candidates consistently outperform in environments where requirements change and ambiguity is the norm. In other words, in almost every technical role that exists. When hiring technical talent for roles that require thinking on your feet, speed of understanding is more important than depth of prior knowledge in most cases.
I started noticing this around candidate one-fifty, and by now I consider it one of the more reliable informal signals in technical hiring conversations. The way an engineer talks about former colleagues — specifically their non-technical colleagues — tells you a great deal about how they will function inside a cross-functional team.
Some candidates talk about product managers, designers, and business stakeholders as obstacles to engineering work. The people who generate requirements that make no technical sense and then change their minds at the last minute. This is a recognisable frustration — it is genuinely shared by many engineers — but the candidates who frame all cross-functional collaboration in these terms tend to create friction in environments where engineering does not operate in isolation.
Other candidates talk about the same challenges — unclear requirements, late changes, misaligned priorities — as problems they have been part of solving. They describe the product manager they learned to communicate with more precisely. The design conversation they pushed to have earlier in the process. The stakeholder presentation they helped build because they understood that technical work does not exist outside a business context. These candidates are not more talented. They are more useful in most real working environments.
When hiring technical talent for roles that involve any cross-functional collaboration, I pay close attention to this signal. It is not definitive. But it is consistent.
There is a type of candidate that consistently fails standard technical assessment processes and consistently succeeds in the role. They are hard to evaluate because they do not fit the pattern the process was designed to detect.
They might have a non-linear career path that does not map cleanly to seniority expectations. They might have deep expertise in a domain adjacent to but not identical to what the job description asked for. They might be quiet in a structured interview and verbose in a pair-programming session. They might have built significant things in environments with less prestigious brand names than the top-tier candidates.
The hiring technical talent processes that miss these candidates have one thing in common: they are optimised for signal clarity, not signal diversity. They are looking for a recognisable profile, and when a candidate does not match that profile, they produce a no. Sometimes that no is right. Often it is a false negative — an accurate evaluation of fit with the assessment process rather than with the actual role.
I have learned to add one question to every evaluation, independent of what the structured process produces: “Is there something this candidate demonstrated that our process is not designed to see?” It has produced some of the strongest hires I have ever been involved with.
This is counterintuitive given the volume of career coaching that tells engineers to quantify everything and lead with impact metrics. But in my experience, the majority of technical candidates — particularly mid-career engineers — consistently undersell what they have actually done.
They describe the system they built as “fairly standard” when what they are describing is a genuinely difficult engineering problem solved under real constraints. They say they “helped with” a migration that they effectively designed and led. They describe a performance improvement they delivered as “nothing special” when the numbers, if you press them, are significant.
Part of this is professional modesty, which is not a bad quality. Part of it is that many engineers are not used to translating their work into the commercial or strategic framing that hiring processes reward. Part of it is that the questions interviewers ask when hiring technical talent are often not well-designed to draw out the actual scope and impact of what candidates have built.
Ask follow-up questions. Press on specifics. Ask about constraints and pressures. Ask what would have happened if the project had not succeeded. The engineers who know their work deeply will always have more to say. Give them the space to say it.
After six hundred conversations, the things I trust most when hiring technical talent are almost never the items that get the most attention in a typical hiring process. Prestigious school names and previous employer brands are weak predictors of performance. Technology stack breadth is a weak predictor. Number of years of experience is a weak predictor, particularly once you are past a certain threshold.
What I trust: the quality of someone’s reflection on their own work. How quickly they update their mental model when new information arrives. Whether they are genuinely curious about the problem your company is trying to solve. How they talk about the people they have worked with. Whether they can be wrong gracefully — whether they can say “I don’t know” or “I got that wrong” without it destabilising them.
These things do not show up in a CV screener. They do not always survive a take-home coding test. They emerge in conversation, in the margins of a well-designed technical discussion, in the way someone reacts when you change the parameters of the scenario halfway through.
That is why the hiring technical talent process matters so much. Not as a filter, but as a context — one that either creates the conditions for these signals to emerge, or prevents them from being seen at all.
If you take one thing from six hundred conversations, let it be this: the process you use shapes the candidates you find. A process designed to filter for pattern-matching — for people who look like hires you have made before — will produce pattern-matched results. A process designed to surface capability, curiosity, and judgment will produce something else.
Neither is neutral. Both are choices. And given how much depends on getting technical hiring right — the pace of product development, the quality of engineering culture, the compounding advantage of having genuinely exceptional people in key roles — the choice deserves more deliberate attention than most organisations currently give it.