Most engineering interviews are backwards. We spend the majority of our time evaluating technical skills, the thing that’s easiest to teach and quickest to develop, and almost no time evaluating values and abilities, which are much harder to change and far more predictive of long-term success.

I’ve made this mistake myself, repeatedly. I’ve hired brilliant engineers who turned out to be terrible collaborators. I’ve passed on candidates who weren’t the strongest technically but would have been exactly what the team needed. The more I’ve hired across start-ups and corporates, the more convinced I’ve become that we need to flip the order.

The Framework

Jay Signorello, writing in 97 Things Every Engineering Manager Should Know, proposes a hierarchy that clicked for me immediately: evaluate values first, then abilities, then skills.

Values are a person’s principles and standards, what they believe is important, how they treat others, what they’re willing to compromise on and what they’re not. Values are deeply ingrained and rarely change in adulthood. If someone doesn’t value collaboration, no amount of training will make them a good team player.

Abilities are inherent talents, things like problem-solving aptitude, communication clarity, learning speed, and adaptability. These can be developed but they’re largely innate. Someone with strong analytical ability can learn any programming language; someone without it will struggle regardless of which language they know.

Skills are learned competencies, specific programming languages, frameworks, tools, and domain knowledge. These are the easiest to acquire and the most likely to become obsolete. Yet they dominate most interview processes.

The logic is simple: skills are the easiest to improve after hiring, values are the hardest. So why do we spend most of our interview time on skills?

The Culture Fit Trap

One reason the industry over-indexes on skills is that evaluating values feels subjective and risky. “Culture fit” has become a loaded term, and rightly so, because it’s often used as a proxy for “people like me.” Lisa van Gelder makes this point forcefully: the A/B/C Player categorisation that some companies use opens the door to unconscious bias and removes manager responsibility for developing people.

The growth mindset distinction matters here. If you believe talent is fixed, that people are either A Players or they’re not, you’ll hire for current ability and discard anyone who doesn’t immediately impress. If you believe talent is developed, that people grow with the right support and challenges, you’ll hire for potential and invest in development.

That doesn’t mean lowering the bar. It means changing what you’re measuring. Instead of “can this person solve a whiteboard algorithm problem under pressure?” ask “does this person demonstrate curiosity, integrity, and the ability to learn quickly?” The first question tells you about their interview preparation. The second tells you about their trajectory.

Designing Better Interviews

Alicia Liu’s advice on interviewing beyond technical skills has shaped how I think about interview design. The key principles:

Define the non-technical attributes that matter. Before you start interviewing, agree as a team on what values and abilities you’re looking for. Write them down. Create a rubric. This prevents the common failure mode where each interviewer evaluates whatever they personally care about.

Make technical interviews collaborative. Instead of adversarial whiteboard sessions, try pair programming on a real problem. You’ll learn far more about how someone thinks, communicates, and handles ambiguity than you will from watching them write a sorting algorithm from memory.

Involve diverse interviewers. Different perspectives catch different things. If your interview panel is homogeneous, you’ll have blind spots in your evaluation.

Treat behavioural red flags as deal-breakers. If someone is dismissive, arrogant, or disrespectful during the interview, when they’re presumably on their best behaviour, that’s a strong signal about how they’ll behave once they’re comfortable. Don’t rationalise it away because their technical skills are impressive.

Lorenz Cheung suggests three interview questions that I’ve found genuinely useful: ask about something they’ve learned recently (tests curiosity and growth mindset), ask about a past failure and what they learned (tests self-awareness and resilience), and ask about real work experience in depth (tests actual capability rather than rehearsed answers).

What I’ve Learned From Getting It Wrong

The worst hiring mistake I ever made was someone who aced every technical assessment but had a fundamental values mismatch with the team. They were competitive where the team was collaborative. They hoarded knowledge where the team shared it. They optimised for individual recognition where the team optimised for collective outcomes.

The technical output was impressive. The team damage was worse. Within six months, two other engineers had asked to transfer, and the collaborative culture we’d built was visibly eroding. When the person eventually left, the team’s velocity actually increased, not because they weren’t productive individually, but because their presence had been suppressing everyone else’s productivity.

That experience taught me something I now consider a hiring axiom: a values mismatch will always cost you more than a skills gap. Skills gaps can be closed with training and mentorship. Values mismatches can only be resolved by separation.

The Practical Reality

I’m not suggesting you ignore technical skills entirely. You need people who can do the work. But the order of evaluation matters. Screen for values first, in the initial conversations, in the behavioural questions, in how they interact with everyone they meet during the process. Then assess abilities, their problem-solving approach, their communication, their learning speed. Then, and only then, evaluate specific technical skills.

If someone has the right values and strong abilities but is missing a specific technical skill, they’ll learn it. If someone has every technical skill you need but the wrong values, no amount of coaching will fix it.

Hire for who someone is and who they’re becoming, not just for what they can do today.