Hiring engineers: what I look for beyond technical skills

I almost rejected one of the best front-end engineers I’ve ever hired.

During the interview, they took long pauses before answering, avoided eye contact, and responded in a way that felt abrupt. My first instinct was that they wouldn’t work well with the team. I was looking for someone who could collaborate easily, communicate naturally, and be comfortable in design discussions. On the surface, none of that was obvious.

But their portfolio was remarkable. Deep accessibility knowledge, precise CSS, responsive layouts that held up across every breakpoint I could throw at them. Their CodePen projects showed both creativity and rigor. So I hired them. (You know who you are, D.)

A few months in, I learned they were autistic, and that interviews were genuinely difficult for them. The pauses weren’t uncertainty. The directness wasn’t arrogance. They were just processing differently from how I expected. That experience recalibrated how I think about the whole hiring process.

What “beyond technical skills” actually means

Every hiring guide says the same thing: look for communication, ownership, adaptability, curiosity. The advice is correct. The hard part is evaluating it without confusing “fits my expectations” with “has the trait.”

Communication is the most commonly misread one. An engineer who writes precise, well-structured comments in code reviews is communicating well. An engineer who writes clear RFC proposals is communicating well. Neither of those requires being comfortable in a live verbal interview. If your only signal for communication is how fluently someone talks under pressure, you’re measuring interview performance, not communication.

Ownership shows up in specifics. Ask someone about a project they worked on and listen for pronouns. “We built this system” tells you something. “I noticed the deploy times were getting out of hand, so I investigated and proposed switching to parallel test execution” tells you more. The people who own their work talk about it differently.

Adaptability is easy to claim and hard to fake. I ask about a time when the requirements changed significantly mid-project and what they did. The answers that impress me aren’t the ones where everything went smoothly. They’re the ones where someone describes adjusting their approach, acknowledging what they got wrong initially, and explaining what they’d do differently now.

Curiosity is visible in the questions someone asks, not just the ones they answer. A candidate who, at the end of the interview, asks something specific about the technical decisions the team made, or about where the architecture is going, is showing you something real. The candidate who has no questions or asks something generic has probably done more interviews than research.

How someone handles feedback is the one I test explicitly. Mid-interview, I’ll suggest an alternative to something they proposed and watch the reaction. Not to see if they agree with me, but to see if they engage. Do they ask a clarifying question? Do they consider it and explain why they’d still go a different way? Do they immediately capitulate because I’m the interviewer? Any of the first two are fine. The third is a flag.

Building the team, not just filling the role

When I’m hiring, I’m thinking about the team shape as much as the candidate’s individual profile. A team of all senior engineers with similar backgrounds has obvious blind spots. A team with no experienced engineers has different problems.

I actively look for diversity in gender, background, neurocognitive styles, and career path, not as an obligation but because the teams I’ve managed with genuine diversity have consistently outperformed on complex problems. Different mental models applied to the same problem surface things that homogenous groups miss.

The bias check I run: if I’m leaning toward rejecting a candidate, I ask myself what specifically concerns me and whether that concern maps to their ability to do the job. “They seemed uncomfortable” is not a job requirement. “They couldn’t explain the trade-offs between their two proposed approaches” is. The distinction matters.

The interview design question

Technical interviews need to test more than algorithm performance under time pressure. That skill set is real but narrow, and most engineering work doesn’t look like it.

I structure interviews to include a realistic problem: a piece of code to review, a system design to talk through, a debugging scenario. Then I watch how someone navigates ambiguity. Do they ask clarifying questions or make assumptions? Do they think out loud or go silent? Do they consider trade-offs or optimize for a single dimension?

A candidate who says “I’m not sure, but here’s how I’d approach figuring it out” is often more interesting than one who confidently gives the first answer they think of. Knowing what you don’t know, and having a method for figuring it out: that’s what the job mostly is.