The anatomy of an effective interview. What to do and what not to do during an interview, part 1

I've done a lot of interviews in my career, probably several hundred in total. We selected and trained people for interviews at companies like Microsoft and Google, so these were quite difficult interviews. In the beginning I wasn't very good at it and made all sorts of mistakes. Hopefully over the years I have become more aware of what to look for 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 if you are a good developer, you can conduct interviews. Obviously this is not the case; many excellent engineers cannot and, most importantly, should not, conduct interviews without preparation.

To my surprise, many companies still do not have any guidelines 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 nothing is more important to a company's success than finding the right people, and interviewing is the core of that process. So it always surprises me when a reputable company has a chaotic and inconsistent interview process. But what upsets 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 company requirements or the real needs of the position.

This is a broad topic, so I'll just share a couple of my observations here and the 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. Don't try to establish yourself at the expense of others. The interviewee may not know some topics, and that's okay.

   Positive attitude towards the candidate Necessarily. The person you are interviewing is already under a lot of stress, no need to add to that. Positive intentions are even better. I always try to let people know up front that one of the main purposes of the interview is to provide them with feedback so they can improve their skills. So they can't really fail – they'll get a job offer or good feedback they can use later.

   Quite often these days I see the interviewer half-listening and trying to do his other tasks at the same time. More than once I have seen an 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 can quickly learn the rest and require minimal maintenance. Also, unlike technical skills, they are not as easy to acquire. Sound obvious? But not for many interviewers and hiring managers. I regularly see numerous examples of candidates being rejected based on their lack of knowledge of a particular technology. It's pretty stupid. Like, the candidate is a quick learner and has deep knowledge of front-end development, but has no experience with Typescript. So what? How long will it take this person to learn it? Three days, maybe, or even a week? But problem-solving skills don't come easily.

3. Another important skill to focus on is communication. I know some programmers don't think this is important. Unfortunately, even in the technical field, becoming a senior specialist without communication skills is quite difficult. And working with such a person is painful. At the end of the day, 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 interview, I try to keep the technical side as close as possible to the big tech companies. Structurally, 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 issues

• Behavioral issues

• Design Questions

• Coding task

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

Not all parts are always present. I would say that only coding tasks and theory/experience questions are mandatory.

Resume Review

To get an idea of ​​a candidate, I usually ask about 1-3 recent projects. People tend to forget details on projects older than three years, so you shouldn’t ask about projects that took place under Tsar Pea.

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

Theoretical issues

I usually start with basic questions and tailor them to the candidate. It's a good idea to ask the candidate to rate their core skills and focus on that. There is no point in asking something that the candidate does not know well. For candidates' core skills, I suggest going deeper and asking not just what or how, but why. That is, checking whether the candidate understands how a certain function works and why it works the way it does. Very experienced people and the best candidates are usually curious and know these things.

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

NO CONFUSED OR TRICKY QUESTIONS!

Yes, I have to write this in capital letters because I see them too often. We're not playing a quiz game here. Confusing questions are not indicative of anything. Who cares why hatches are round? I heard it's so the Teenage Mutant Ninja Turtles can fit into them. These questions do not show anything other than the idiocy of the interviewer (if he really intends to evaluate candidates by them and is not asking for fun).

Behavioral issues

They can be anything as long as they highlight the candidate’s behavior and character. The main goal is to get an idea of ​​the candidate, how connected he thinks and can explain his actions and ability to solve problems. My advice to all candidates is to prepare for this in advance; Without practice, it’s difficult to remember something on the spot.

Some examples:

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

• Tell us about conflicts you have 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 🙂

Questions about design and architecture

These are open questions for which there is no one correct answer. The goal is to understand whether the candidate understands architecture and evaluate his 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 said problems, which not everyone can do.

That's all for now. Coding tasks and feedback are a separate big topic, so I will talk about it in part 2.

I am a co-founder of an AI integrator Raft.

I share my experience in TG channel.