Why Technically Strong Candidates Still Get Rejected
Some of the most technically capable candidates we work with still don't get the offer. When we dig into why with clients, the reason is almost never the technical bar itself, it's something else entirely.
If a candidate has the right technical background, why would they still get rejected?
Three recurring patterns show up consistently in client feedback, and none of them are about raw technical ability.
What's the most common non-technical reason clients pass on a strong candidate?
An inability to communicate technical trade-offs to non-technical stakeholders. Engineers who can write genuinely complex systems in isolation but freeze or over-complicate things when asked to explain a technical roadblock to a portfolio manager or trader in plain, commercial terms tend to lose otherwise strong processes at this exact point. Trading desks need engineers who can translate technical reality into business risk quickly, not just build well.
Does a background at a large, structured tech company ever count against a candidate?
It can, if it shows up as a specific working style rather than just prior experience. Candidates used to detailed requirements, structured sprint planning, and clearly scoped tickets sometimes struggle with the far more ambiguous, high-autonomy way trading desks actually operate, being handed a loosely defined problem and expected to work out the right approach independently. Clients read a need for constant structure and guidance as a genuine fit risk, not simply a difference in working style.
Do compensation-focused conversations early in the process actually hurt a candidate's chances?
Yes, more than most candidates realise. Engineers who over-index on compensation discussion in early or mid-round conversations, without matching it with genuine curiosity about the systems and problems they'd actually be working on, tend to get read as a retention risk rather than a strong hire, particularly by desks that have been burned before by hires who leave the moment a bigger number appears elsewhere.
Is there a common thread across all three of these rejection patterns?
Yes, all three are really about trust and fit under real conditions, not technical capability. Clients aren't questioning whether these candidates can code, they're questioning whether the candidate will communicate clearly under pressure, operate well with genuine ambiguity, and stay motivated by the actual work rather than the next comp conversation. Those are much harder things to assess from a CV, and much easier to get wrong in an interview than raw technical skill.
What should a technically strong candidate actually focus on to avoid this?
Practising how to explain technical decisions and trade-offs in plain, non-technical language, being upfront about comfort with ambiguity rather than assuming structure will be provided, and keeping early conversations focused on the actual work and systems rather than leading with compensation. None of this changes the technical bar, it changes whether a client trusts the candidate to operate well once they're actually in the seat.
