The only thing I look for in a technical interview

During a technical interview, I put all my bets on one horse. One key ingredient I seek in every candidate. This characteristic transcends programming languages, frameworks, or algorithms. It's the cornerstone of effective engineering. And the ultimate litmus test for potential hires. What could that be? Amongst the vast ocean of skills and experience, what could stand out as the deciding factor? Let's find out.

The first thing I always do in an interview is understand the candidate's context. By this, I mean their background, their experiences, and how they think about problems. I don't rush this or do it by myself - for example, with a resume. An open dialogue with the candidate is more suitable.

I always make it clear to the candidate what I'm looking for. The first is a piece of work they're most interested in basing the first few questions around. I want them to showcase their best work, or something they've invested a lot of time and energy in. Something they've thought a lot about or are confident in. I want to put them at ease, and what better way than to start a conversation there? Their role in the project is usually what I want to understand first. Then comes details like the challenges they faced and the decisions they made.

For problems we pursue, I'm interested in their approach, and not the solution itself. There's no penalty for getting things wrong. They're also allowed to request a change in the problem. I'm interested in learning their strengths; not their stress triggers. I also share how if I appear distracted or look away it's me taking notes. The candidate is always at the center of my attention and their time is very valuable to me. I would love it if they think out loud, as it helps me the most.

As an interviewer, there are a few keys skills that come to aid. Having cross-domain knowledge is one. Being able to understand and contemplate new domains is another. Asking about a possible issue, or adding a constraint is one way to proceed. Another way is to extend the problem space or adding a new feature.

At this stage, I don't test the candidate's ability to learn new contexts. The problems posed - while new - are still rooted in their domain. I am focused on problems, and I don't have a predetermined solution. I am most interested in how the candidate wants to solve the problem at hand. Asking a question with an answer in mind is for trivia quizzes; they don't have a place in an interview.

If the candidate stays quiet for a while I try not to interrupt their thoughts. But if it goes on for longer, I ask them what they're thinking about. It's better to interrupt and save some time than to have the candidate meander. I avoid a few pointless struggles faced by a candidate this way.

The candidate could be overthinking. As in they may be trying to solve more than required. In that case, I simplify it for them. If they are stuck with no way out, I reiterate that they can switch to another problem with no penalty. Some people are more persistent while others would switch. It's good either way, since we make better use of the candidate's time. The alternative is they spend time without making progress.

Sometimes it can be revealing to steer the candidate into uncharted waters. Especially when the candidates are more experienced, this becomes useful. I expect most of us to comprehend and work with a new/different domain. For these instances, I present a domain that's straightforward but unfamiliar. This could be a rudimentary rate-limiter or a basic key-value store.

I start small and introduce layers of complexity. The aim here isn't to perplex or overwhelm. I want to observe how the candidate navigates challenges as they evolve. I look for adapatability, resilience, and strategic thinking here. Most of these improve with experience and exposure.

In a technical interview, I don't want to know what a candidate knows. I want to know how they think. I check their ability to approach, dissect, and tackle problems. In the art of interviewing, problem-solving is the masterpiece I seek. It's the essence of engineering and the driving force behind successful technical endeavors.