
What Makes Two Engineers With Identical CVs Deliver Completely Different Results
Engineering Hiring
·
8 min read
·
Talex Research Team
The Pattern
Two engineers apply for the same role. Both have eight years of experience. Both have shipped production AI features. Both list the same tools — Python, TypeScript, Claude, Cursor, vector databases, the standard 2025 stack. Both have worked in regulated industries.
One delivers a system that holds for eighteen months. The other delivers something that requires constant intervention from week three.
The gap between these outcomes is not random. It is structural. And it is invisible on the CV that both engineers submitted.
What CVs Cannot Show
A CV captures what an engineer has done. It cannot capture how they did it. In 2020, this was a manageable gap — most engineering work was sufficiently legible from project descriptions and tech stack lists. In 2026, with AI-augmented work, the gap is now the difference between hiring a productive engineer and hiring an expensive risk.
Three things matter for enterprise AI project outcomes that no CV format reliably captures:
Whether the engineer's judgment improves with AI assistance or simply speeds up their existing approach
How they behave when AI output is wrong in non-obvious ways
Whether they can carry project-specific context — legacy constraints, security requirements, organizational history — into their AI-assisted work
An engineer who has shipped a production AI feature might score high on all three of these. An engineer with the same line on their CV might score low on all three. The CV does not differentiate them.
Where the Gap Comes From
From 500+ engineering assessments in enterprise contexts, the most consistent source of output gap between similar-looking candidates is what happens at the moment of friction.
When an engineer encounters something that does not work — a library that behaves differently than documented, an AI suggestion that compiles but is subtly wrong, a system constraint that conflicts with the spec — what happens next determines the project trajectory.
One engineer treats friction as a signal that the problem is more complex than the surface, slows down, examines the assumption, and updates their model of the system. The fix takes longer but holds.
Another engineer treats friction as an obstacle to clear, applies a workaround that produces the expected output, and moves on. The fix is faster but introduces a structural debt that compounds.
Both engineers ship the feature. On the CV, both engineers have done the same work. In the project, one trajectory leads to a system that holds and another leads to gradual accumulation of unaddressed complexity that surfaces as production issues months later.
The Three AI Capability Tiers
The friction-handling pattern correlates strongly with what we call the three AI capability tiers — categories that emerged from observing how engineers actually work with AI tools across enterprise project contexts.
Tier 1 — AI-Enabled. The engineer uses AI to move faster. Output volume is high. Friction is treated as an obstacle to route around. This tier delivers well in execution-heavy work with clear specifications.
Tier 2 — AI-Integrated. The engineer knows when to trust the output and when not to. They override AI suggestions when project context the model cannot see makes those suggestions wrong. Friction is treated as information.
Tier 3 — AI-Native. The engineer can feed project-specific enterprise context into AI tools and get relevant output. Friction is treated as a window into where their model of the system needs to update. This tier is rare.
Two engineers with identical CVs can sit at different tiers. The CV format does not surface tier. The interview format usually does not either.
What an Assessment That Surfaces the Gap Looks Like
The assessment shift is from output questions to behavior questions.
Output questions ask what the engineer has shipped. Behavior questions ask what the engineer does in specific situations that reveal tier.
Examples that surface the gap:
"Walk me through a time an AI tool gave you output that was syntactically correct but wrong for your specific project. How did you identify it?"
"In a project with legacy constraints the AI tool does not know about, how do you structure context so the output is relevant?"
"Describe the last time you slowed down on a task because something did not match your expectations. What did you find?"
The quality being assessed is not the answer — it is the reasoning. An engineer who can articulate why they slowed down, what they checked, and how they updated their understanding is demonstrating Tier 2 or Tier 3 behavior regardless of the tools they used.
Why Joint Observation Matters
Sequential interviews allow candidates to calibrate. By the second conversation, they have learned what the first assessor responded to and adjusted their answers. The signal degrades.
Joint observation — a technical assessor and a delivery assessor in the same session — surfaces signals that neither would catch alone. The technical assessor probes the AI reasoning. The delivery assessor watches how the candidate handles uncertainty in real time. The interaction between the two perspectives generates a composite signal that cannot be reconstructed from individual notes.
Engineers who perform best in joint sessions are the ones who stop performing. They engage with the uncertainty as a real problem rather than a test. That behavior is the most reliable indicator of Tier 2 and above.
Implication for Project Outcomes
If a hiring process cannot differentiate two engineers with identical CVs, every hire becomes a coin flip. The downside of the flip is not just productivity loss — it is structural debt accumulating in the codebase, in the team, and in the relationship between the SI firm and the engineering function.
The engineers who deliver eighteen-month systems and the engineers whose work requires constant intervention often look the same on paper. Differentiating them at assessment time is the highest-leverage decision in the entire delivery chain.
Everything downstream — onboarding, project assignment, governance, exit risk — is downstream of that single signal.

