Making the most out of technical interviews

Subscribe to my newsletter and never miss my upcoming articles

Technical interviews are tough. They can be challenging, frustrating and downright exhausting. It is often argued that the process is fundamentally broken. Questions and problems are contrived and do not necessarily correspond to what we encounter on the job.

Imperfect as they may be, though, interviews are also an awesome learning resource. They can show us our strengths and weaknesses and make us not only good at interviewing but genuinely better programmers. With the right mindset, we can easily leverage technical interviews to our advantage.

So let's do it!

Take the chance

Applying for technical roles can be intimidating. It goes without saying that there is no need to tick every single box on the list of requirement in order to apply for a position. Being qualified is certainly important. But gaps in experience can easily be filled by showing enthusiasm for the job and willingness to learn, especially for more junior roles. So applying, even before feeling completely confident, is the first important step in the process.

We create our resume and go on a job hunt. After a while, we finally get a call.

We have an interview!


Preparing for a technical interview can be overwhelming. There is so much information out there. It is truly difficult to know where to begin. We will inevitably be doing some general interview prep. I highly recommend Hackerrank's interview preparation kit. FreeCodeCamp is another amazing resource.

But a quick way to narrow our scope immediately before the interview is to research the company itself. What do they do? What is their stack? What are the core technologies they use? Most crucially, how does it all relate to our own experience and knowledge?

We can use this information as a guide to create a clear framework for what to learn (or brush up on) before the interview. It can also help us understand which skills to highlight and what questions to ask during the interview itself.

The interview

The big day is finally here! Our first technical interview.

The pressure is real. Even though we've done all we can to prepare, we are a bundle of nerves. The technical questions start pouring our way. We answer some, semi-answer others and for the rest - we have no idea. And that's ok! It's our first interview, after all.

But while all of this unfolds, we discover something interesting. Interviewers are people, too. Not only that, they are most likely developers. And developers, as a general rule, like to share their knowledge. They also understand what it feels like to sit on the opposite side of the table. The moment they feel curiosity and genuine interest on our part, the interview stops being an exam and turns into a conversation.

At almost every interview, there comes a point when we are forced to admit we don't fully know or understand something. It is not an ideal situation. But it is made much better by having a discussion about it. Often, in the course of this discussion, we will get the correct (or at least expected) answer to many of the questions right then and there.

Already, this is extremely valuable information we can leverage in the next steps of the interview process or in conversation with other companies.

What's next?

The aftermath

The interview is now over and we can breathe again. But before we get too comfortable, let's write down everything that we can remember from the conversation we just had. We should put special emphasis on the questions we most struggled with.

Learning to solve the problems we tripped over last time should become integral part of our interview prep routine and our learning process more generally.

To illustrate the value of this approach, let me share a random sample of the questions I had trouble with during my first frontend interviews:

  • What is the difference between primary and reference data types in JS?
  • What is the only JS value that is not strictly equal to itself?
  • What is the difference between var and let?
  • How do closures work?
  • What are the disadvantages of React?

Diving into questions like these after each interview immensely deepened my knowledge on a variety of topics. Not only understanding the answers, but being able to articulate them in a high pressure environment, is also a valuable skill can we gain in this process.

What is more, there comes a point when interview questions start to repeat. So investing our time in targeted learning yields ever increasing returns.


Technical interviews create a unique setting for identifying our strengths and weaknesses as developers. Each time, they give us an opportunity to focus our learning process on what we should but don't yet know.

Over time, what can be perceived as learning Javascript trivia "in case someone asks" turns into a deep understanding of the language and its quirks. And it's all because we couldn't answer a question during an interview that one time!

No Comments Yet