Battle-tested technical interview plan for Lead Engineers

A few days ago I have conducted my 16th technical interview. 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.

☝️ 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 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.

Nevertheless, there is a set of questions I ask almost every time:

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?

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.

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.

⚠️ This is also the part when I expect the candidate to really drive the interview.

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.

I 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 is not listening to me when I ask them to stop and re-evaluate the chosen approach.
2. The answer is really unstructured. For example, they jump between different parts of the code.
3. The candidate constantly gets lost between == and === operators.
4. They don't care much about variable naming or indentation.
5. The candidate stops typing, then a short pause happens, and then suddenly the candidate speeds up again. It may indicate them googling at the background.

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", or anything more sophisticated, but there is got to be something.

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. I have a pre-defined report template for that too:

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 posses the required skills for this particular role, but could be offered a similar position one level below.

Final advises

1. I DO NOT hire "maybe-s". My experience tells me it is way cheaper for everyone 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. There ought to be positive vibes between me and the person.
2. I try to prevent getting biased by the candidate's appearance, tone of their voice or something else like that. The person could be in pain at the moment, or his favourite guinea pig might have just died. You'll never know.

---

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

---

Cover image by Stitch at Flickr

The meme is made using a frame from The Morning Show