The anatomy of an effective interview. Do’s and don’ts of the interview process

I have conducted a lot of interviews in my career, maybe 1000 in total. We screen and prepare people for interviews with companies like Microsoft and Google, so these are the toughest interviews out there. I wasn’t good at this in the beginning and made all kinds of mistakes. I hope I got better over the years and have a better perspective now. You see - when I started many years ago, we had no formal training for interviewing skills in our company; it was considered that if you were a good developer — you could interview people. It is obviously not true; there are many great engineers who can’t, and, most importantly, shouldn’t conduct interviews. Well, at least without training.

To my surprise, a lot of companies still have no guidelines and no education process for their interviews. I mean, like interviewer often doesn’t even know what kind of people the company looking for in this specific position or in general! How can you find the right people if you don’t know who are you looking for? Do you need a smart, fast-learning junior who will grow fast with the company, or do you need a seasoned veteran who can be completely autonomous? Or maybe you need an architect/lead-level person to guide your team in a certain area? Those are different people and different approaches to interviewing them.

I think there is nothing more important for the success of the company than hiring the right people, and interviewing is at the core of this process. Hence, it always baffles me when a respectable company has a chaotic and inconsistent interview process. But what saddens me the most is when a really good professional is declined because interviewers followed a rigid or blind approach or used his or her OWN criteria of a good candidate, with complete disregard for the requirements of the company or position's actual needs.

This is a vast topic, so I will share here only a couple of my observations and interviewing guidelines that I use for all my interviews (assuming you KNOW who are you looking for!):

1. The interview is not about YOU. Nobody is interested in what YOU know, don’t try to assert yourself at the expense of others. The interviewee may not know certain topics and that is ok.
2. A positive attitude is a must. The person you are interviewing is already under a lot of stress, don’t need to add to this. Positive intent is even better. I always try to tell people in advance that one of the major goals of the interview is to provide feedback to them so they can improve. So they can’t really fail — they would get a job offer or good feedback they can use to try later.
3. Listen. It is quite common nowadays when an interviewer is half listening and trying to do his other tasks simultaneously. Many times I’ve seen the interviewer staring into his laptop throughout the entire interview. I am guilty of that as well, and when this happens, you get a half-baked interview as a result.
4. The main skills I look for are problem-solving and the ability to learn fast. If you think about it — a person with these skills will be able to pick up the rest pretty quickly and will require the least amount of maintenance. Also, unlike technical skills, these are not easy to acquire. Sounds obvious? No, it isn’t, at least it is not obvious to many interviewers and hiring managers. I regularly encounter numerous examples when a candidate is declined based on that he doesn’t know some specific technology. This is so dumb. Like, the candidate is a fast learner, and has a deep understanding of frontend development but doesn’t have Typescript experience. I mean, so what? How long will it take for this person to learn it? Like 3 days maybe or even a week? But you can’t acquire problem-solving skills easily.
5. Another essential skill to look for is communication. I know some software engineers think this is not important. Sadly, it is quite challenging even in tech to become a senior professional without communication skills. And it is a pain to work with such a person. After all, we all work with people and build products for people.

As you can, these are very generic rules, but I wish somebody told me that 10 years ago.

Technical part

When I interview people I try to conduct the technical part of the interviews as close as possible to big tech companies. Structurally, interviews in all big tech companies are similar, so this part is good for any of them. There are five major parts:

1. Resume walkthrough
2. Theory questions
3. Behavioral questions
4. Design questions
5. Coding task
6. Candidate questions (yes, this is also going to be assessed)

Not all parts will always be present. I would say only Coding Tasks and Theory/Experience Questions are mandatory.

Resume walkthrough

To get a feel of the candidate, I unusually ask about 1–3 recent projects. People tend to forget details for anything older, so don’t bother asking.

In this part, I look for self-presentation skills. It is important that the candidate talks about his contribution to the project, not just what the project was about or the tech stack, although that is also essential. I also look for clues that the candidate is a team player and passionate about his work.

Theory questions

I usually start with basic questions and calibrate from that. Good idea to ask the candidate to self-assess his main skills and concentrate on that. No reason to ask what a candidate doesn’t know well. In candidates’ core skills, I suggest going deep and asking not only what or how questions but also why. That is, check if the candidate not only understands how a certain feature works but why it works this way. Very senior people and the best candidates are usually curious and know this stuff.

I prefer to start with general questions, like SOLID, patterns and then move to specifics about particular technologies.

NO TRICKY QUESTIONS! Yes, I had to put this in caps because I see this way too often. We are not playing trivia here. Tricky questions are not an indicator of anything. Who cares why manholes are round? I heard this is so that Ninja Turtles could squeeze into them.

Behavioral Questions

Could be anything that highlights the candidate's behavior. The main goal is to get a feel of the candidate, how articulate he is, and if he can explain his actions and problem-solving abilities. My advice to all candidates — prepare for this in advance; it is hard to come up with something good without practice.

Some examples:

• Tell me about the most difficult technical problem and how you solved it.
• Tell me about the conflicts you had in the past and how you solved them.
• Your top 5 personal accomplishments.
• Challenging decision you had to take.
• Your strong and weak sides (btw correct answer you have no weak sides, only areas to improve :) )

Design Questions

Open-ended questions. There is no one right answer. The goal is to understand if a candidate understands architecture and assess the candidate's maturity/expertise.

Examples of design questions:

• Design Twitter backend
• Design Whatsup frontend
• Design specific component

A good candidate will ask intelligent questions before proposing a design. The candidate should be able to provide justification for the proposed architecture and identify bottlenecks in his/her own solution. My goal as an interviewer is to criticize the proposed approach. Candidates should be able to take criticism and iterate on it, something not all people can actually do.

That’s it for part 1. The coding task and giving feedback is a separate big topic, so I’ll cover it in part 2.