The Tech Interview Behind the Scenes: Martin Antonov

post cover

The Tech Interview Behind the Scenes is an HRLabs series.
Let’s take a look behind the scenes of the technical interview process from the interviewers' perspective.
Our goal is to provide candidates with valuable tips and recommendations directly from professionals who conduct interviews for various technical roles.

“Live coding shouldn’t be part of an interview,” shares Martin Antonov, Software Architect - Frontend at Leanplum (a Clevertap Company).

Tell us more about your career path.

I hold a degree in mathematics from the UK, with a focus on abstract algebra, algorithms, graph theory and cryptography. About ten years ago, I attended Telerik Academy. After that, I launched a startup called Fractal Games, specializing in HTML5 puzzle games. Later, I moved to Sofia, where I have worked for various companies, primarily as a Tech/Team Lead for gaming and enterprise teams.  

My professional interests revolve around algorithms, architectures, clean code, and, of course, frontend technologies. Somehow, I often find myself leading teams that work with legacy code, which needs to be rewritten or refactored. :)

As a candidate, have you had any strange interviews? What about interviews that impressed you?

Over the years, I've had a few interviews that I would classify as "odd." The last one that comes to mind was just before I started my current position.

While snowboarding with my family in Pamporovo, I got a call from a very nice lady from a recruiting agency about an Architect role. I told her about my experience, my focus on frontend technologies, and what I was looking for in terms of a position and salary. 

During the actual interview, I noticed that the interviewer was a backend engineer, so I brought it up in relation to the role. I believe his exact words were, "I don't understand frontend, and I'm not interested in it." It became an awkward situation because the role turned out to be for a Backend Architect. Nevertheless, we decided to proceed with the interview. It was quite a thorough technical interview—algorithms, data structures, graphs, hash maps, SOLID principles, architectures... I think I only stumbled when it came to databases and AWS due to my limited backend experience. Understandably, I didn’t get an offer. On the positive side, I’ve had several enjoyable and interesting interviews for positions as a mathematician/programmer in the field of combinatorial optimization. 

Still, the best interview process I’ve experienced was at Leanplum.

The process began with an interview with the HR Manager at the Sofia office. This was followed by an interview with the hiring manager for the position, where we got acquainted, I shared my experience, and I was informed about the role, the team, and what my responsibilities would be. The technical part was conducted in two stages—first a take-home task, followed by an in-office interview where we discussed the solution and additional, quite interesting questions were asked. Finally, I went through a "cultural fit" interview. I was really impressed that the company conducted such an interview and took it as seriously as the technical stages. This was also the first company I applied to that required references from previous employers.

After such a rigorous interview process, I was thrilled to receive and accept Leanplum’s offer—the work is interesting, and my colleagues are super cool, intelligent and incredibly skilled professionals.

What skills and qualities do you look for in a candidate? How can a candidate stand out during the interview?

I would divide a candidate's qualities into two categories. 

The first is related to social skills—how they handle conflicts, how they communicate, whether they are overly confident, and if they fit into the company’s culture and atmosphere.

From a technical perspective, it depends heavily on the specific role.

For junior developers, I look for the ability to solve problems they haven’t encountered before (algorithmic tasks, clean code, object-oriented programming), as well as adaptability to new technologies and a desire to grow.

For senior developers, the expectations are higher. In addition to the previous criteria, I pay closer attention to coding style, relevant experience with specific technologies, discussions on OOP principles, SOLID, design patterns, and architectures.

Often, the questions I ask are similar across different levels. A candidate stands out if they can answer quickly and precisely, no matter how deep the discussion goes or how challenging the follow-up questions become. For me, such candidates show a strong passion for programming—not just as "a job" but as a hobby that brings them joy.

What questions do you typically ask in technical interviews? Do you have specific tasks or problems that you often use to assess candidates?

Creating a good technical interview is no easy task and is often quite a subjective process. For me, it's crucial to ensure the candidate is comfortable so they can show their best work.

In my opinion, live coding should not be part of an interview. In real-life situations, developers rarely write code while someone watches and evaluates them. It can be stressful and unrepresentative of their typical work environment. Because of this, I divide my interviews into several parts.

The first part is an introductory technical discussion designed to put the candidate at ease. I often ask questions like:

  •  What’s the most complex problem you've solved as a developer?
  • What makes you smile at the end of a workday?
  • What are your thoughts on React vs. Vue vs. Angular? Which one do you prefer and why?

The second part is a more in-depth technical discussion, including architectural design of reusable components (like a Dropdown Menu), defining and discussing the Redux pattern, which is highly used in our field, and smaller questions related to CSS, design patterns, OOP, and more.

The most important and final part of my interview process involves coding tasks. I have specific tasks prepared to test a candidate's competence in areas like algorithms, OOP, clean code, and async/promises. I share my screen, and we work on the tasks together to reduce the stress of live coding. I try to help the candidate if they get stuck and focus mainly on the quality of the code.

How important are good communication skills for a candidate? How do they impact the overall interview?

On one hand, it's not difficult for a candidate to demonstrate good communication skills, meaning the bar isn't set very high. On the other hand, in the absence of such skills, the candidate does not move forward, regardless of how good a programmer they are and how much value they could bring to the company through their work.

I believe that when it comes to leadership positions (Team Lead, Engineering Manager, and above), good communication skills become much more crucial, and this is emphasized more during interviews.

How important is cultural fit when making a hiring decision? How do you assess whether a candidate will fit well into the team?

Unfortunately, my impression is that very few companies conduct cultural fit interviews and take into account a candidate's compatibility with the company. Without giving specific examples, I have worked in companies with people who lack basic business etiquette, workplace culture, and manners. Working with such people is extremely difficult; the atmosphere becomes very oppressive and toxic, especially if they are in leadership positions. In such cases, they also become a reason for the resignation of good employees or entire teams.

I personally pay serious attention to racist, sexist, hateful or sort of comments, regardless of how subtle they may be during the interview.

At Leanplum, cultural compatibility is checked at all stages and by all interviewers, which I believe has greatly contributed to the wonderful culture and atmosphere in the company.

What are the most common mistakes candidates make during an interview? What advice would you give candidates on how to prepare for an interview?

I have conducted many interviews for various companies over the past 10 years, and in my observation, over 95% of candidates make basic mistakes that leave a very bad impression, excluding technical skills.

My advice before the interview is for candidates to read more information about the specific company and product. I am very pleased when, in response to the question, 'Do you know anything about Leanplum?' or 'What made you apply with us?', the candidate shows that they have prepared and quickly talks about the product and what caught their interest in the job posting.

I also believe it is essential for candidates to review all the technologies and requirements mentioned in the job advertisement they are applying for. Spending 10-15 minutes on each topic through a YouTube video or an article increases the candidate's knowledge, and this is always felt during the interview. This isn’t about learning the specific technology in detail, but simply having a basic understanding.

Additionally, there are "trap" questions for which it is good for candidates to always have a prepared answer. These include questions like:

  • 'Why did you leave your last position?'
  • 'Have you ever had a conflict with colleagues? How did you resolve it?'
  • 'What are your top 5 negative qualities?' and others.

Personally, I don’t like these questions and don’t ask them, but when they have been asked of me, I always have a ready answer, and that makes a good impression on HR.

Following basic business etiquette, candidates should arrive on time for the interview (I always arrive at least 5 minutes early) and dress appropriately (no flip-flops, shorts, hats, or sunglasses). In unforeseen circumstances, the candidate should notify about a delay at least 15 minutes before the interview, apologize for the delay, or for any potential postponement.

During the interview, the candidate should be positive, not overly self-confident, and ready to focus on the technical part—I have had candidates who 'just didn’t feel like it.'

I have encountered other similar mistakes, but by following these simple rules, a candidate would be in the top 5% of all interviewed. Even with a less-than-perfect technical interview, the chances of receiving an offer increase significantly.

What advice would you give to candidates who want to improve their technical skills? Are there any resources you would recommend?

My main advice is for candidates to have in-depth knowledge of the fundamentals of programming—algorithms, OOP, principles, quality code, design patterns, and basic architectures. After that, they should specialize in a specific area of programming that sparks their strong interest, such as frontend, backend, web/app development, AI, embedded systems, or gaming. For everything that isn't their specialty, it’s good to have at least basic knowledge and competencies.

I most often use YouTube, Medium, or a random website from Google to quickly fill in gaps. For comprehensive courses, I check YouTube because it's free, and if I can't find a suitable resource, I look at Coursera, Udemy, or MIT OpenCourseWare.

Share more about the best (or worst) interviews you've conducted.

I have conducted a considerable number of successful interviews. The candidates often breeze through my questions with ease. In such cases, I usually recommend them for a higher position than the one they applied for (if the company has the capacity for it) or, at the very least, I inform the other interviewers with a personal message about a very strong candidate.

Here’s a funny story about the strangest interview I’ve conducted.

The position was for a junior programmer at my startup, Fractal Games.

The candidate had put effort into his CV. He had about a year of experience and had graduated from Telerik Academy—on paper, a great candidate for the position. He arrived on time, but in flip-flops, shorts, and a t-shirt. The conversation and technical part went satisfactorily, except for a few responses like, 'This is very easy—I can check it on Google very quickly' (the idea is to answer during the interview—anyone can use Google!). Still, we decided to give him a task. The candidate strangely asked on which day we would send him the task. The reason was that he had been living in a tent for a year 'in search of himself' and had internet access only on Tuesdays when he went down to the nearby gas station to charge his batteries. This definitely took us by surprise, and we didn’t expect such a response. In the end, we decided not to give the candidate the task.

I also have examples of objectively 'bad' interviews—a candidate explicitly wrote in his CV 'Algorithms and Graph Theory,' and when asked a related question, his answer was, 'I had such a course in university; I passed it with a C, and I didn’t understand much about what it was about.' 

I’ve also had candidates who copied the solution to a task from the internet. Perhaps my most vivid memory is of a candidate who showed up 10 minutes late, wearing a hat and t-shirt, with seriously bloodshot eyes—perhaps intoxicated or suffering from a serious hangover. With every question I asked, I felt like I was causing him mental distress, and the technical part went by with incredible boredom—it was as if I had forced him to plow an entire field.

How do you evaluate a candidate during an interview—based solely on their theoretical knowledge, or is their approach to solving a problem/task more important to you? What other factors do you consider when making a decision?

I don’t emphasize dry theory, but I always check it as an application to a specific problem. For example, I never ask, 'What is the definition and an example of each of the SOLID principles?'

Instead, I test whether the candidate will notice the absence or error in the code related to these principles. If they can cite the corresponding broken principle and provide a definition, that would be a perfect answer.

I definitely focus on the way of thinking and the approach to interesting and unconventional tasks.