I've interviewed well over a hundred engineers, and I've been wrong about plenty of them. Early on, I optimized for the obvious thing: who could solve the hardest coding problem the fastest. Some of those hires were great. Some were quietly a nightmare to work with. Over time, my mental checklist changed completely, and the things at the top of it now have very little to do with raw coding speed.
Here's what I actually look for when hiring software engineers — and why the technical test is the least interesting part.
The story
The hire that changed how I interview was technically the strongest candidate I'd seen that year. He breezed through every problem, wrote clean code under pressure, knew the language deeply. Easy yes. Six months later he was one of the hardest people on the team to work with — not malicious, just impossible to align. He'd build the wrong thing beautifully, defend it past the point of reason, and leave teammates afraid to give feedback. His code was excellent. His impact was negative, because software is a team sport and he played it alone.
Around the same time, I'd taken a chance on someone more middle-of-the-road technically, who I'd almost passed on. She asked great questions, admitted what she didn't know, and clearly thought about why before how. Within a year she was one of the most valuable people on the team — not because she out-coded anyone, but because she made everyone around her better and consistently solved the right problems.
That contrast rewired my hiring. Coding ability gets you into the conversation. It's rarely what makes someone great.
What I look for now
How they think, not just what they know. I care less about whether someone arrives at the perfect answer and more about how they get there. Do they ask clarifying questions before diving in? Do they consider trade-offs? Do they notice the edge cases? I'll happily take a candidate who reasons well through an unfamiliar problem over one who pattern-matches a memorized solution.
Ownership. The best engineers treat problems as theirs to solve, not as tickets to complete. In interviews I probe for this with their past work: "Tell me about something that broke. What did you do?" Owners talk about what they did and learned. Non-owners talk about what happened to them. The language gives it away.
Communication. Can they explain a technical idea simply? Can they disagree without being defensive? Engineering is mostly communication wearing a technical costume — design docs, code reviews, debugging with others, explaining decisions to non-engineers. Someone who can't communicate will cap out fast no matter how good their code is.
The ability to learn and be wrong. Technology changes constantly; whatever someone knows today is a depreciating asset. What compounds is their ability to learn and to update when they're wrong. "I don't know, but here's how I'd find out" is one of my favorite answers. Candidates who can't say "I was wrong" become senior people who can't either, and that's expensive.
I'm not hiring the person who's best today. I'm hiring the person who'll be best in two years — and that's almost always about ownership, communication, and learning, not current skill.
The red flags
A few things make me cautious regardless of technical strength: blaming previous teams for everything, an inability to name a single mistake, treating the interviewer's questions as obstacles rather than conversations, and condescension toward "easy" problems or other roles. None of these are about skill. All of them predict how someone will treat teammates on a hard day.
Key lessons
Coding speed is overrated. It's a filter, not a differentiator. Past a baseline, it barely predicts impact.
Hire for the trajectory, not the snapshot. Learning ability and ownership compound. Current knowledge decays.
Communication is a technical skill. Treat it as core, not soft.
Watch how they handle being wrong. It's the single best predictor of whether they'll grow or stall.
Action steps
If you're hiring (or want to be hireable):
- Ask about real past work, not just puzzles. "Walk me through something you built and what went wrong" reveals more than any whiteboard.
- Give an open-ended, slightly ambiguous problem and watch whether they ask questions before coding. The questions are the signal.
- Probe for ownership with their language — "we/I did" vs "it happened."
- Create a moment where they don't know something and see how they react. Comfort with not knowing is a green flag.
- Optimize for the team, not the individual. A brilliant solo player who damages collaboration is a net negative, and the spreadsheet won't show it until it's too late.
Final thoughts
The most valuable engineers I've hired weren't the ones who impressed me most in the first ten minutes. They were the ones who asked the right questions, owned their work, communicated clearly, and got better every month. Those qualities are harder to measure than a coding score, which is exactly why most hiring processes under-weight them — and why getting them right is such an advantage.
Hire for how someone thinks, owns, communicates, and learns. The code, you can teach. The rest is who they are.