Job interviews for developers, my approach to Technical Interviews

My Approach to Technical Interviews

I’ve done — and still do — technical interviews for the companies I work with.
Recently, one candidate told me that my interview was easy.

Easy?
That surprised me, because I know my interviews are actually quite hard.
What the candidate didn’t realize is that the technical answers are only a small part of the overall evaluation.

Most of the time, I’m not just checking whether someone can code — I’m observing how they react, think, and communicate.
I’m trying to understand how they would fit into the project and the team.

Technical Questions

These days, I assume that any modern developer has already moved from Stack Overflow to ChatGPT (or a similar assistant).
I don’t care if they don’t remember all the functions from the standard library — nobody does.

In a recent interview I told the candidate that he was allowed to use LLMs to answer the questions. My colleagues send me LLMs code to review anyway.

What I do care about is how much they actually enjoy the technology they’ll be working with.
I like to ask if they follow any Java or Angular evangelists, or if they know some of the core concepts or thought leaders in the ecosystem.

I always review the candidate’s CV and start the conversation from their experience — asking for details about the projects they mention.
If they have a public repository, even better. I go through their code and ask questions about it. Unfortunately, not many candidates bring one.

If a candidate shows only limited curiosity or passion for the technologies we use, it’s usually a bad sign. They rarely pass the interview.

I also like to ask questions that come from real debates we’ve had within our team — things like:

• Interfaces: yes or no? When and why?
• Should we use var?
• Constructors vs. setters vs. other approaches?

These discussions prepare the candidate for the kind of technical debates we’ll have during code reviews. They don't have an absolute answer, it depends is a valid answer.
What I really want to know is whether they’re passionate about the craft — or just looking for a job.

Team Fit and psychological madness

Technical skills can be taught.
Personality and collaboration style — that’s another story.

The most important part of any interview is understanding how the candidate will fit into the team.
We spend 8 to 10 hours a day working together, often under pressure, discussing code, requirements, and sometimes life itself.

The new team member needs a personality that matches our current psychological madness — in the best possible way.

This part is complicated, because interviews are stressful by nature.
I usually use humor to break the ice and see how the candidate reacts once they drop their defenses.

But the hardest goal of all is to identify whether someone might become a toxic element.

Guarding the Team

A toxic teammate can silently destroy morale and motivation.
They often come in the form of the “I know it all” personality — the ones who always say things like:

• “I did that before.”
• “I’m the best at this.”
• “We have to do it this way.”
• “That’s wrong.”

Strong opinions are fine — when they come with flexibility and respect.
But when they turn into constant friction, they can poison the team’s energy and even jeopardize the project.

That’s why one of the toughest — and most important — parts of the interview is protecting the team from those toxic and disruptive elements.

Final Thought

In the end, a great developer isn’t just someone who writes perfect code.
It’s someone who brings curiosity, humility, and energy to the team.
That’s what I look for in every interview — and what makes the process much more meaningful than just a list of technical questions.