Technical Interviews Decoded: A Guide for Interviewers – Part 1

I’m a Senior Software Engineer specializing in back-end development with Java, with over seven years of experience. In my career, I’ve been on both the candidate and interviewer sides of the interview table, giving me a holistic perspective on the technical interview process.

The interviews I've conducted have given me firsthand insight into what makes an interview effective, what common mistakes both sides tend to make, and how to make the interview process more efficient and productive. 

I'd like to share my notes, observations, and best practices with interviewers and candidates to help them conduct structured, insightful, and confident interviews. This is the first part where I’m sharing tips for interviewers, while the second part focuses on tips for candidates. 

So, whether you’re hiring or being hired, I hope these insights make your technical interview experience more effective and less stressful.

1. Pre-Interview Preparation

The first, the obvious, and maybe the most often overlooked part is reading the candidate’s CV carefully. A resume design can be just as important as the technology stack the candidate worked with and the roles they performed. It looks odd to me if I look at a CV file that has copied and pasted experiences without even a small change. It gives the interviewer almost no insight into the interviewee's past experiences.

Understanding the candidate’s strengths in past projects will make it easy for an interviewer to formulate relevant questions focusing on experience and the needs of the vacancy. Pro tip: You can use phrases like “In your CV, you’ve mentioned your experience with…”, which can give the candidate a nice feeling that you have indeed read the CV and built rapport. 

Here are a few quotes from my experienced colleagues for this first part:

“The first step is to know exactly what you need the candidate for and what the role is. The biggest problem with a lot of interviews is that the questions are totally unrelated to the actual role, which would not help you find the right person for the job. Try to align the questions as much as possible with the role you‘re looking for.”

“Be aware about seniority level of candidate, the task or question needs to be different for each seniority level”. 

This is a fair point, and I agree that it’s better to prepare questions right after reading candidates' CVs because asking the candidate to name all of the methods on the Object class (from Java) can mislead the candidate if s/he is applying for a Middle+ or Senior position.

2. Interview Methodology

The best way to build a productive interview is to avoid broad, open-ended questions, which can be found easily by searching for “questions for Java Middle / Senior interview ”. The rule of thumb is: the better you’ve learned the candidate’s CV and the project requirements, the better you can interview the candidate and elicit the answers you need to assess their experience and skills.

I recommend using the 80/20 rule: speak 20% of the interview time and let the candidate speak the remaining 80%. 

While listening, analyze the candidate's responses on which terminology they are using, as it can give you a good point for understanding the candidate's level of experience, their roles, and the level of their knowledge of technical concepts. 

In one of my first interviews, when the interviewer asked what Spring is, I answered that it is something that simplifies developers’ work. I couldn't say more about that framework, just because I wasn’t suitable for a middle-level position.

Also, a good point during an interview is to ask a candidate to describe their role in past projects, their challenges, how they dealt with them, and which technical leadership skills they developed. 

At this point, I recommend paying attention to the candidate’s explanation, team composition, their interaction with the team, and their way (or attitude) of solving problems. When you're interviewing a candidate for a project you're already working on, you know the type of interaction the team has and how much independence each team member needs to have, so you can make useful decisions based on the answers given by the candidate. Focusing on how candidates approach the challenges can be more important than just the final answer.

Check these useful tips from my colleagues to help you conduct interviews and excel at them.

“Try to say less about yourself, and let the candidate tell more about their career. They always have a lot to talk about when it comes to presenting themselves. However, don’t push them into it.”

“Try to avoid asking questions that can be answered with a simple Google search. These types of questions hardly ever reveal anything about the candidate and their capabilities.”

“When asking coding questions, try to actually keep the question simple. Asking the candidate to implement an optimized deep Traverse algorithm is hardly ever relevant for your job. What matters is the candidate‘s approach to solving a problem, which you can evaluate with a simple question.”

“Be aware of the candidate’s seniority level, since tasks and questions must correspond to each seniority level.”

“The good candidate is not always the one who knows the answer (especially for the regular questions taken from Google”

“Theory and practice should be checked. It’s good to have a practical task that is linked with some previously asked theoretical questions. This way, you can check if a candidate not only understands theory but knows how to solve practical tasks.”

3. Practical Task

Some interviews offer only coding tasks and a few technical questions. Whether it’s a good or bad practice depends on your interview goals and the roles you’re interviewing for.

In some cases, it makes sense to talk to candidates if you need to learn how they approach tasks, ask questions, and think aloud as part of your organizational process. If the interview is held for another client, then it’s important to consider their context and business goals. 

Coding tasks depend on the candidate's level and the project needs, but regardless, I recommend preparing typical coding tasks that occur on a project you’re interviewing for.

I believe there’s limited value in asking candidates to implement a fast sorting algorithm, especially since such tasks rarely occur in real-world projects. That said, tasks like these can offer insights into a candidate’s problem-solving approach – and, as always, it depends on the specific context.

Pay attention to the candidate's body language, face, and eyes during a test task. You can notice the stress level, confidence, and also…cheating. 

I’ve had some interviews where candidates cheated, and those were, to be honest, not the best interviews. By cheating, I mean that the candidate wasn’t the only one on the interview, and someone else (most probably someone more experienced) was just telling the candidate what to answer or what to write in the coding task. When candidates mute themselves, turn off the camera, and start typing the code quickly and correctly, but when asked to unmute or turn the camera on, they stop typing code in the correct way or at all, that’s a distinct sign they might get external help to get through the interview. 

Anyways, in all cases, interviewers should respect candidates and not make them feel uncomfortable. During the technical interview, the interviewer is the only person representing the company.

Another effective way, which is also a kind of practical task, is “pseudo-programming” with the candidate. This approach involves collaboratively designing the concept of “the perfect application”, which is adapted to the specific goals of the project. 

Think aloud together with the candidate about the architecture of an application, database selection, any ways of database optimisations, design patterns, infrastructure and other important components. Pay attention to the terms the candidate uses and how they approach different challenges, pain points, bottlenecks. Do they consider long-term solutions that are maintainable and scalable, or do they focus on quick fixes without considering future consequences ?

This method can give you deep insights into the candidate’s problem-solving skills, technical knowledge and their approach to building sustainable solutions.

I recommend taking notes about the candidate during the interview and documenting how a candidate approaches test tasks, their thoughts, questions, and so on. It’ll help you create more informed feedback (The best practice is to provide feedback promptly after the interview, while the details are fresh in your mind).

Here are some quotes from my colleagues:

“Don‘t forget to consider the "stress" factor during the coding questions. Try to reassure the candidate that they are doing fine if you feel they are stressed out.” 

“It‘s not necessarily bad to allow the candidate to do a Google search during the interview. It‘s already part of the job, isn’t it?”

This is the quote of my colleague who actually interviewed me a while ago. He said, “Just Google it if you don’t know or don’t remember.” The question was about a specific regular expression I hadn’t used frequently in my previous experience. Up until that point, I believed interviews were strictly a test of personal knowledge, not the ability to search for information. However, that moment shifted my perspective. The reality is that searching for solutions – whether through Google, AI tools, or documentation – is an essential part of a developer’s workflow, regardless of experience level. From junior engineers to lead architects, everyone relies on external resources to fill knowledge gaps, find efficient implementations, or learn something new. In fact, how well a candidate formulates their queries and navigates these resources can be just as telling as their technical knowledge.

4. Professional Considerations

During an interview, it’s essential to be respectful and polite to the candidate, even if you, as an interviewer, have already understood that this candidate is more likely unsuitable for the given position. Remember that you are representing your company, and you should follow the company's values.

Don't hesitate to help a candidate if you see they’re stuck on something or ask you about it. Remember that the candidate can worry much more than you.

Whenever the candidate wanders off course, guide him or her back to the topic, maintaining a respectful tone and avoiding criticism.

Here are some quotes from my colleagues:

“Be honest! If you’ve already decided the candidate isn’t right (which is the case for most of your interviews), just say that at the end of the interview, and state the reasons as well. Don’t keep the candidate in limbo. Direct feedback is more appreciated than a simple “We’ll call you back”.

In the next post, I'll share some practical tips for those in an interviewee's seat – stay tuned!