Hiring developers

A resume is a marketing document. That’s not a criticism—it’s just what it is. The problem is that many hiring processes treat it as something more: as evidence of capability rather than a claim about it. Combine that with the fact that technology moves fast and “knows X” depreciates quickly, and you have a situation where the signal-to-noise ratio in a typical developer hiring process is lower than almost anyone admits.

The symptoms show up in the resumes themselves. Developers list every technology they’ve encountered—web frameworks from three years ago, tools they used for two weeks on a project, platforms they’ve read about but never deployed. Not because they’re dishonest, necessarily, but because the hiring market rewards breadth of keyword coverage over depth of actual competence. Senior candidates listing basic office software as skills aren’t outliers. They’re rational actors in a system that has trained them to pad.

What actually predicts good developers

Algorithmic thinking is the foundation. Not academic CS—you don’t need someone who can recite the formal proof of a sorting algorithm’s time complexity. But a developer who can’t think through a search problem, who doesn’t instinctively understand what a stack or a queue is for, is going to struggle when the problem they encounter doesn’t fit a template they’ve seen before. Real software problems rarely do.

Language-agnostic reasoning matters more than language coverage. A developer who can write clear pseudocode—who can articulate the logic of a solution before they’ve decided how to implement it—is someone who understands the problem rather than just the syntax. Technology stacks change. The ability to reason clearly about computation doesn’t.

Solid object-oriented fundamentals are non-negotiable for most modern software work. Not just familiarity with the terminology—genuine understanding of inheritance, polymorphism, and composition, demonstrated across more than one language. Someone who knows these concepts in Java and can apply them in C# has understood something real. Someone who knows Java syntax and calls that “OO experience” hasn’t.

Then there are the things that don’t fit in a technical category at all. Curiosity. Genuine interests outside programming. The ability to disagree productively. The willingness to say “I don’t know” rather than speculate confidently. These predict someone who will keep learning and who will function well in a team. Neither shows up on a resume, which is exactly why interviews matter.

What to stop doing

Stop treating the technology checklist as a filter. Checking whether a candidate has used a specific framework tells you almost nothing about whether they can build reliable software. Frameworks are learnable. Judgment is harder to develop.

Stop confusing resume density with capability. The candidates who list fewer technologies but can explain each one clearly are often more valuable than the ones who list everything and can speak shallowly about all of it.

The organisational dimension

Hiring is only part of the equation. A learning organisation—one that invests in its people, creates space for professional growth, and values craft alongside delivery—can develop competent developers over time. One that doesn’t will burn through the good ones and be left with whoever stays.

Hire for attitude and foundational capability. Give people the chance to grow. The return compounds in ways that a keyword-matched hire rarely does.