How I Run Technical Interviews When Hiring Engineers

An interview usually takes one or two sessions of about an hour. Two engineers from the team join me for each one.

First, the candidate's experience

At the start we listen more than we talk. We ask the candidate to walk us through previous projects, hard problems, successes and failures.

What I want to understand is not only what the team worked on, but what part the candidate personally played:

• which tasks they took on;
• how independently they solved them;
• which problems they ran into;
• which decisions they made themselves;
• which concrete result they were accountable for.

When someone keeps saying "we built", "we solved", "we achieved", I start asking follow-up questions: what exactly did you do?

The word "we" is not a problem in itself. Software is almost always a team effort. But if a candidate cannot separate their own contribution from the shared result, it may mean they are used to leaning on colleagues and are not yet ready to carry a task to completion on their own.

Then the technical part

The next block is close to a standard technical interview: databases, architecture and design patterns, technologies, concurrency, service-to-service communication and whatever else fits the position.

The engineers I bring to the interview also contribute questions and practical situations from our team's real work.

The goal is not to check how many definitions the candidate has memorised. We need to understand:

• how systematically they think;
• whether they can apply knowledge in practice;
• whether they see constraints and trade-offs;
• whether their preparation matches the level of the role;
• whether they can solve the specific problems our team works on.

My favourite block: coding

I deliberately give simple tasks.

For example: write a function with three parameters that determines the winner in rock, paper, scissors.

You may be surprised, but roughly 80% of candidates cannot bring this task to a working state.

What interests me is not so much the final code as the process.

One candidate starts with the simplest possible solution, checks it, then improves it step by step. Another immediately sees a compact algorithm. A third clarifies requirements and edge cases first. Some write tests before the implementation, others verify the code by hand.

Watching someone write code line by line already tells you a great deal:

• how they break the problem into parts;
• whether they notice ambiguity;
• whether they check their own assumptions;
• whether they can find and fix mistakes;
• whether they can explain the decision they made;
• whether they think about tests and boundary cases.

If you have even a little development experience, it quickly becomes obvious when a candidate is solving the task themselves and when they are quietly using AI or other hints. It is not only about the quality of the answer. What gives it away is the mismatch between how the person reasons and the code that suddenly appears on the screen.

I am not against using AI at work. Quite the opposite: today it is an essential developer tool. But in an interview I need to see the candidate's own thinking: can they verify a proposed solution, find the bug in it, and take responsibility for the result?

We decide together

After the interview my colleagues and I discuss the candidate briefly, then vote at the same time:

• thumbs up: we are ready to work with this person;
• thumbs down: we are not.

That way nobody adjusts their initial opinion to match the team lead or a more confident colleague.

That is all. I like simple, transparent processes.

How do you run technical interviews? Which tasks best reveal a developer's real level? Tell me on LinkedIn.