A few days ago I have my 16th technical interview conducted. After a while, I have defined a set of rules and formalised some good practices. Now I feel confident enough to share it.

Every time I keep an interview, I mostly don't improvise. I have a script I normally stick to, occasionally deviating from it if I see fit.

Medium and large companies usually have a framework for the interviewing process, as the companies want to have standardised ways and tend to give all candidates equal chances for success. So even before doing interviews it could be definitely a good idea to look into such materials.

☝️ Note: this article is a work in progress. As I keep practicing, I might add a few things or remove something I find no longer relevant.

The preparations

Of course, certain homework must be done before jumping into the call.

Here is a list of typical things I do:

1. Get a CV of the candidate, read it carefully.
2. Try to figure how to pronounce the candidate's name correctly. If a company hires worldwide, it can be a real challenge sometimes.
3. Scan the CV for unusual things and prepare questions. For example:
   • If the candidate's previous position was a lead (IC4), and now they are going for a senior (IC3), then it wouldn't be odd to ask about the motivation.
   • Same counts for situations when they worked for 10 years in fullstack, but applied for the front-end position.
4. Prepare a blank page in Notion (or any other tool) with the following:
   1. A pre-created link to the online technical assignment, if any.
   2. As list of custom questions, if there is any.

The Script

A typical interview lasts roughly 60 minutes. Hence, for each step there is a time limit.

1. Greeting - 1 min
2. Brief introduction - 1 min
3. Tech talks and CV discussion - 28 min
4. Tech assignment - 25 min
5. Q&A from the candidate and wrap up - 5 min

Let me dive deeper into each step details.

Greeting

The Greeting is a formal part. First I say some standard things like "How are you? Welcome to the interview!".

Then, I say "All right, here is the plan ...", and then I name the steps mentioned above. After that I seamlessly move on to the introduction.

Brief introduction

This part is also formal. At this point, the candidate is not really interested in getting to know me, since their main concern is how to pass the interview. This is why, in order to save time, I bring this part down to absolute minimum and only tell the following:

1. My name.
2. My occupation, what I do in the company.
3. When I joined.
4. What is the current project I am working on.

As soon as I'm done with this part, I ask if the candidate wants to take the stage. And that is when the real deal begins.

Tech talks and CV discussion

At this step I usually expect the candidate to talk about either their latest position, or something they are really proud of.

The conversation should not be too deep and thorough, as usually there is behavioural interviews for that. Also, the variety of questions may change depending on the level and role. If the position is junior, there is no point in diving too much into the candidate's experience, as there is simply none. In this case it is better to screen for personal traits and knowledge of basic technologies.

The ideal situation would be this part turning into a pleasant conversation, rather than a questionnaire. What could be even better is when I could actually learn something new from the candidate: a new library to explore, or a decent article to read.

There is a set of questions I sometimes ask a senior:

1. Can you give me an example of where you have a system built completely end-to-end?
2. How is your team structured and how are tasks assigned? What is your role in all that?
3. Can you give me an example of mentoring? Have you led any teams?
4. Are you involved in setting direction and goals for your team?
5. Tell me about your biggest mistake in the career and what experience you have acquired.

For a more junior position, I may ask:

1. How have you ended up in tech, what is your passion about it?
2. Tell me about your education and bootcamp.
3. What are your plans for the future career?

I may also have CV-specific questions, or I can ask to elaborate on something that caught my attention while the candidate was talking.

There is also a tech-specific part, where I do quick recap of the candidate's tech skills, as per how it is specified in their CV. If we talk about React and web applications in general, I may examine their experience with performance issues and how those can be mitigated. We may also talk about favourite libraries for state management, testing, styling, etc.

The most important part here is to ask questions on purpose, to screen for different aspects, traits and gotchas of the candidate. For instance, when I ask about native DOM or vanilla JS, I try to figure whether the candidate is used to work only with certain frameworks, or there is something more to it.

I try making the questions open-ended. So instead of a question where a simple "yes" or "no" answer could suffice, I try to give the candidate a chance to talk from their experience. I ask to talk about real life situations instead of asking "How would you...?".

It is also a good idea to start with a set of fairly simple questions, and then move on to more intricate ones. It gives the candidate a chance to warm up and properly get along with the situation.

Meanwhile, I actively write the notes down. I ask to give me a few seconds to finish writing, in case if I am too slow.

Tech assignment

Typically, the initial tech screening is more technology-focused. Due to the fact that there is a time limit of 25 minutes, I usually offer something more or less close to real life. I choose an exercise where only the basic skills are checked. Brain teasing with an algorithm-based question is a topic for the other kind of interviews.

For example, if I test knowledge of React, I may ask to build a component, check how the candidate structures it, how they work with hooks, event handling, basic CSS.

I make sure the text of the test assignment is formulated correctly, no excessive, complex and too cryptic vocabulary is used. I would rather skip wasting time explaining to a non-native speaker the meaning of advanced words such as "mitigate" or "comprehensive".

This is also the part when I expect the candidate to really drive the interview. I also try making live coding interview to look more like pair programming.

I ask to be verbose, so it helps me to understand where the train of thoughts is going. This also gives me insights on how good collaborator the candidate really is. If the candidate nevertheless stays silent, it may indicate they are in panic or simply not listening to what I say. In both cases it is not a good sign.

In general, I expect the candidate to follow this framework:

1. Read the task carefully.
2. Ask additional questions and clarify the conditions. A small recap of the task is also appreciated.
3. Briefly explain the solution they are going for.
4. Code the solution, run it, make sure it really works.
5. Tell me how the solution can be improved.

Some people say that finishing all the tasks is not crucial, since the most important thing is the way the candidate drives the technical part. Well, due to the fact that I am asking for the absolute basics here, I really expect everything to be completed within the time frame. If the candidate is unable to nail it down and fails to cope with stress, then I declare it as red flag.

Other possible red/yellow flags:

1. The candidate was not listening to me when I ask them to stop and re-evaluate the chosen approach.
2. The answer was really unstructured. For example, they jump between different parts of the code.
3. The candidate constantly got lost between == and === operators.
4. They didn't care much about variable naming or indentation.
5. The candidate stopped typing, then a short pause happened, and then suddenly resumed. It may indicate them googling at the background.
6. The candidate hasn't explained the plan of solving the challenge before jumping directly to coding.

If the candidate is failing, but still looking really motivated, I sometimes can go overtime.

Occasionally I show professional courtesy and help them to get the solution to a certain point. By doing so I let them learn something from their failure.

Q&A from the candidate and wrap up

At this point the candidate is either devastated with the failure, or encouraged with the way the interview is going so far.

Here I expect some questions to be asked by the candidate. It does not matter whether those are just placeholder questions like "Tell me about the company's culture.", "Tell me why you like the company." or anything more sophisticated, but there is got to be something.

I carefully write the questions down for the record.

Should the candidate ask no questions, it automatically counts as a red flag. It either indicates them being in 10 hiring processes at the same moment, or they simply don't care much, or they were lazy to do their part of the job.

At the very end I tell the candidate the standard phrase: "Thank you for joining me, it was pleasure. I will make a summary of my notes and pass it over to the recruiter. They will contact you shortly." After that I wish a great day and disconnect.

The Report

After the interview is done, the results must be reported within the next 24 hours. If the report time is unreasonably prolonged, the impression starts fading away, and I may start second guessing the evaluation, experience changes of heart, etc. Also, a good candidate may simply proceed with another offer where the response was quicker.

Mature companies usually have a report template as part of their learning materials. I have a pre-defined report template of my own:

1. The final verdict: yes or no.
2. Does the candidate have what it takes to functionally do the job? Here we specify if the candidate has good spoken English, a mindset of an engineer, required technical skills.
3. Will the candidate be successful in our environment? Write down all strong sides of the candidate, and how they are aligned with the company values.
4. Are there any red/yellow flags? Here goes a list of concerns about this candidate.
5. Technical assignment. I provide a link to the tech assignment, if any, and write the observations down.

All of it is not just about the numbers though. Sometimes the candidate does not possess the required skills for this particular role, but could be offered a similar position one level below.

Do-s and Don't-s

1. I always stay calm and friendly during the process. I keep in mind, that I wore these shoes once, and likely will be wearing again sometimes in the future. I remember how tough it was to be an interviewee, and the last thing I would want is my interviewer being a dick.
2. I remember, that while I am evaluating the candidate, the candidate is also evaluating me, and, through the prism of my attitude, the company itself.
3. I don't let the biases cloud my judgment. There are just a few of such biases:
   1. First impression. I don't judge the book by its cover.
   2. Appearance, tone of the candidate's voice or something else like that. Should I even mention that? The person could be in pain at the moment, or his favourite guinea pig might have just died. You'll never know.
   3. Gut feeling. Every hire should be up to certain standards.
   4. Similarity or contrast towards another candidate, another engineer or even myself.
4. I don't touch personal topics, such as sex orientation, political views, etc. All this is irrelevant.
5. I use simple language, free of jargon, slang, acronyms or nation-specific lore other people may not be aware of.
6. Eventually, I DO NOT hire "maybe-s". It's way cheaper for every party to stop the process earlier if something doesn't feel right, rather than to hire a wrong engineer and then try to fix them, or ask to leave. At the end of the interview there ought to be positive vibes between me and the person.

Well, I hope this article was helpful and gave you, my dear reader, some food for thoughts!