What Job Specs Say vs What Clients Actually Care About
If you hired strictly by matching a candidate's CV to the written job spec, you'd reject a lot of the engineers who go on to become the strongest hires. There's a consistent gap between what firms write down and what hiring managers actually prioritise once real conversations start.
Do written job specs actually reflect what hiring managers care about most?
Not always, and the gap is fairly consistent across firms. Specs are often written around formal, easily-listed requirements, years of experience with a specific language, deep domain knowledge in a particular asset class, specific framework or certification experience. What hiring managers actually weight most heavily in practice tends to be different, and harder to write into a checklist.
What gets overweighted in practice, beyond what the spec says?
Core computer science fundamentals and what's often called mechanical sympathy, a genuine, intuitive understanding of memory layout, CPU cache behaviour, thread contention, and how code actually behaves at the operating system level. Fast, confident live coding and the ability to debug autonomously under real pressure also matter more in practice than the spec's formal requirements usually suggest. A proven track record of building something from nothing, taking a genuinely ambiguous problem and shipping a real solution independently, tends to carry more weight than any specific certification or framework listed on a spec.
What gets deprioritised, even though it's often listed as a requirement?
Specific language or niche framework familiarity is far more flexible in practice than specs suggest, strong engineers are generally expected to pick up a firm's specific internal tools and languages quickly regardless of prior exposure. Prior financial markets experience is similarly overweighted on paper, a large share of engineering hires at top trading firms genuinely have no prior finance background at all, and firms who are serious about this don't let its absence rule out an otherwise strong candidate.
Why does this gap exist in the first place?
Written specs are often built as a first-pass filter, a way to generate a manageable initial shortlist, rather than a precise description of what actually gets someone hired. The deeper, harder-to-write-down qualities, systems intuition, autonomy under ambiguity, genuine problem-solving track record, only really surface once real conversations and technical rounds begin, which is exactly why relying purely on keyword-matching a CV against a spec misses strong candidates regularly.
What should candidates actually take from this?
Don't self-select out of a process because a written spec lists a specific language, framework, or finance background you don't have. If your core engineering fundamentals are genuinely strong and you can demonstrate real, independent problem-solving ability, that gap is very often bridgeable, and often matters far less than the spec implies.
What should clients take from this?
Worth being honest internally about what's actually being assessed once interviews start, and reflecting that more accurately in how a role gets written up and sourced in the first place. A spec that overweights formal, easily-listed requirements risks filtering out exactly the kind of candidate who'd perform best once they're actually in the role.
