Anatomy of an effective interview. Interview Dos and Don’ts, Part 1

Anatomy of an effective interview. Interview Dos and Don’ts, Part 1

I’ve done a lot of interviews in my career, maybe a few hundred in total. We selected and prepared people for interviews at companies like Microsoft and Google, so they were very difficult interviews. In the beginning I wasn’t very good at it and made all kinds of mistakes. I hope that over the years I have become better at understanding what to pay attention to and now look at it from a different angle. When I started many years ago, our company had no formal training in interviewing skills; it was believed that you are a good developer – you can conduct interviews. Obviously, this is not the case; many excellent engineers cannot and, more importantly, should not interview without preparation.

To my surprise, many companies still do not have any manuals or educational process for their interviewers. That is, the interviewer often does not even know what kind of people the company is looking for for this specific position! How can you find the right people if you don’t know who you’re looking for? Do you need a smart, fast-learning junior who will grow quickly with the company, or do you need a seasoned veteran who can be completely autonomous? Or perhaps you need an architect/lead developer to guide your team in a specific area? These are different people and different approaches to interviewing them.

I think there is nothing more important to a company’s success than finding the right people, and interviewing is at the heart of that process. So it always surprises me when a reputable company has a chaotic and disorganized interview process. But what frustrates me the most is when a really good professional is rejected because the interviewers followed a rigid or blind approach or used their own criteria for a good candidate, completely ignoring the requirements of the company or the real needs of the position.

This is a big topic, so here I’ll just share a couple of my observations and interview guidelines that I use in all my interviews (assuming you know who you’re looking for!).

  1. First, the interview is not about YOU. Nobody cares what YOU KNOW. Do not try to assert yourself at the expense of others. The interlocutor may know some topics, and this is normal.

    Positive attitude towards the candidate necessarily. The person you’re interviewing with is already under a lot of stress, there’s no need to add to it. Even better – positive intentions. I always try to let people know in advance that one of the main purposes of the interview is to give them feedback so they can improve their skills. So they can’t really fail – they’ll get a job offer or good feedback that they can use later.

    Nowadays, quite often I see the interviewer half-listening and trying to do his other tasks at the same time. More than once, I have seen the interviewer staring at his laptop throughout the interview. I’m guilty of this too ๐Ÿ˜” and when it happens, the result is a subpar interview.

  2. The main skills I look for are problem solving and the ability to learn quickly. If you think about it – a person with these skills will be able to quickly master the rest and will require a minimum of maintenance. In addition, unlike technical skills, it is not so easy to acquire. Sound obvious? But not for many interviewers and hiring managers. I regularly come across numerous examples of candidates being rejected based on their lack of knowledge of a particular technology. It’s pretty silly. Typically, the candidate is a fast learner and has deep knowledge of front-end development, but no Typescript experience. So what? How long does it take for this person to learn it? Three days, maybe, or even a week? But problem-solving skills are not easy to acquire.

  3. Another important skill to consider is communication. I know some programmers don’t think it’s important. Unfortunately, even in the technical field, it is quite difficult to become a senior specialist without communication skills. And pain will work with such a person. After all, we all work with people and create products for people.

As you can see, these are very general rules, but I wish someone had told me this 10 years ago.

Technical part

When I conduct interviews, I try to conduct the technical part as closely as possible to large technology companies. Structured interviews at all major tech companies are similar, so this part works well for any of them. There are five main parts:

  • Resume review

  • Theoretical questions

  • Behavioral issues

  • Design questions

  • Coding task

  • Candidate questions (yes, this is also important to evaluate)

Not all parts are always available. I would say only coding and theory/experience questions are compulsory.

Resume review

To get an idea of โ€‹โ€‹the candidate, I usually ask about 1-3 recent projects. People tend to forget details about projects that are more than three years old, so don’t ask about projects that were under the pea king.

In this part, I pay attention to self-presentation skills. It is important that the candidate talks about their contribution to the project, not just what the project or the technology stack was about, although that is also important. I also look for signs that the candidate can work in a team and is passionate about their work.

Theoretical questions

I usually start with basic questions and tailor them to the candidate. It’s a good idea to ask the candidate to assess their core skills and focus on that. It makes no sense to ask something that the candidate does not know well. In the main skills of the candidates, I suggest to go deeper and ask not only what or how, but also why. That is, to check whether the candidate understands how a certain function works and why it works the way it does. Highly experienced people and the best candidates are usually curious and knowledgeable about such things.

I prefer to start with general issues like SOLID, patterns, and then move on to the specifics of specific technologies.

No confusing and tricky questions!

Yes, I have to capitalize it because I see it too often. We’re not playing a quiz game here. Confused questions are not an indicator of anything. Who cares why the hatches are round? I’ve heard that ninja turtles can crawl into them. These questions show nothing but the idiocy of the interviewer (if he is really going to evaluate candidates by them, and not ask for a joke).

Behavioral issues

They can be any, if they highlight the candidate’s behavior and character. The main goal is to get an idea of โ€‹โ€‹the candidate, how coherently he thinks and can explain his actions and ability to solve problems. My advice to all candidates is to prepare for it in advance; without practice it is difficult to remember something at home.

Some examples:

  • Tell us about your most difficult technical problem and how you solved it.

  • Talk about conflicts you’ve faced in the past and how you resolved them.

  • Top 5 personal achievements.

  • A difficult decision you had to make in the past.

  • Your strengths and weaknesses (by the way, the correct answer is that you have no weaknesses, only areas for improvement ๐Ÿ™‚

Design and architecture issues

These are open questions to which there is no single correct answer. The goal is to understand whether the candidate understands architecture and to assess their maturity/expertise.

Examples of design questions:

  • Design the Twitter backend

  • Design the Whatsup frontend

  • Design a specific component

A good candidate will ask clarifying questions before proposing a design. The candidate must be able to justify the proposed architecture and identify bottlenecks in their solution. My goal as an interviewer is to criticize the proposed approach. Candidates must be able to accept criticism and correct the problems mentioned, which not everyone can do.

That’s all for now. Coding tasks and feedback is a big topic on its own, so I’ll cover it in part 2.

I’m the co-founder of AI integrator Raft.

I share my experience on the TG channel.

Related posts