Young TeamLead Notes: Interviews
Foreword
Every TL wants to show high results in their work. This is necessary not only for career growth, some preferences from the company, but also for your own ego, to understand that you are not standing still. Unfortunately, as far as I know, there are no dedicated “team lead” performance metrics. There are general ones – the time of closing a task, closing a sprint, achieving goals, delivering a functional / project / product on time, etc.
In the previous post I talked about the importance of the people with whom you work, about their development and results, and I ended with the following thesis: “Your result depends on the team.” But the question is the following – how to recruit a team so that the effectiveness of TL, even in “parrots”, is high? How to understand at the interview stage, which is limited in time, the level of competence of an employee, will he be part of the team, will he be able to get along with colleagues and with you?
During my time at two large TL companies, I spoke with a huge number of other leads, people partners, HR and Senior’s who specialize in technical interviews. This article is a rough sketch of the interview process that we have put together with these people in different companies that you can aspire to.
Overview
Companies often have the following interview system:
– Conversation with HR
– Technical interview (1 hour – 3 hours)
– Interview with TL (1 hour)
We will not consider the first stage in detail, since it often does not concern TL very much.
Most of all I am interested in the last two stages – technical and interview interview (acquaintance) with TL. Many may say that the last stage is not so important, but in fact at this stage it is decided whether YOU are suitable for the candidate. I did not highlight this by chance and will consider this thesis below.
With the technical, too, everything is not as simple as we would like. There are constant debates on the network about the need for a livecode session, about assessment methods and questions during interviews. The level of uncertainty is high enough that one candidate can be assessed in three companies at three different levels. Agree, was it the same?
We’ll talk about passing the technical part first.
Technical part
Three interviewers or two or one? What matrix to ask? What to ask? Giving livecode? How do you organize the structure of the interview to evaluate? And what grade to give? And 100+ more questions, to which there is no single answer. Although there is – “Everywhere in different ways.”
Interview style
To begin with, it’s not just the candidate who needs to prepare for the interview. The interviewer should prepare a list of questions in advance, or at least to keep the interview flowing.
Regarding the flow – here you can take it literally. My colleagues, with whom I have worked and work, see in the interview a technical dialogue that begins from afar, touching on projects and the technologies that were used in these projects. And so, gradually, gradually, you can go into implementation details, ask about something fundamental and switch to a theory that no longer strongly concerns the projects the candidate worked on. The key to such a dialogue is a pre-designed structure. A list of the very topics that we talked about earlier.
And how to build a dialogue if there is a partner with TL in the form of TechLead or Senior? Prepare in advance and walk through the structure of the interview. One such preparation is just 15 minutes of time before the interview, a small page in Notion with a structure and a list of topics with a time stamp and assigning the topic to the interviewer.
In an interview where there is more than one interviewer, there should be a leader who keeps track of the time, tries to turn the dialogue in the right direction. Time is needed here so that after the interview, the interviewers understand that they have not missed anything and asked everything that was planned. Such a “fine-tuned” interview rarely lasts more than an hour and a half.
Competency Matrix as an Assessment Tool
When we choose topics, we should roughly figure out what questions we will ask. After all, time is limited, and the candidate must be asked, preferably “everything”. Of course, we cannot ask everything, but we must strive for the ideal.
Questions by topic can be found in the competency matrix. There are hundreds and hundreds of them on the Internet, but not every matrix reflects the specifics of your work and your requirements for the candidate. There is also a way out in this situation – to collect all TL and make your own matrix for the requirements of the products / projects that you create. This will be the best solution, and this matrix will fit perfectly into the interview process.
The matrix is just an agreement on how we will measure, what we will measure, and by what means we will measure. It can be of any kind, but the key one in it:
Themes
Levels (junior, middle, senior)
Questions
Evaluation criteria
Livecode
Many people often say that giving livecode is outdated. And this is a big stress for the candidate – not everyone can write code openly in front of everyone. And in general, forcing a Senior developer to write code is sometimes strange, I agree.
But on the other hand, it is a necessity. If we are evaluating a person with little experience, then a livecode is required, since, unfortunately, you can write anything you want on a resume. We must be convinced of the candidate’s ability to write code, to approach the problem from different angles.
The task can be either a simple algorithmic or a complex one, let’s say a piece of business logic with some kind of error. Here again, everything depends on the future responsibilities of the candidate. It seems to me that the assessment of the livecode session should be spelled out in the general competency matrix.
During livecode, I have always paid attention to:
On the style of writing
On the speed of solving the problem
The complexity of the solution
On the number and relevance of the proposed solutions
Final grade
After passing the section, a grade is given. The score, of course, is set on the basis of the candidate’s answers, the result of the livecode. A brief description is given, feedback is written.
Interesting fact
If the competency matrix works well and is sufficiently “debugged”, then the two interviewers give the same assessment independently of each other.
Outcome
As a result, after a few scattered paragraphs above, we get a structured interview model. It looks like this:
Host: Nick
16:00 Welcome, interview plan – presenter
16:15 Questions about projects from the previous place of work – assistant facilitator
16:30 General Questions (CI / CD, Architectural Principles) – facilitator assistant and presenter
16:45 livecode session – Host
…..
At first glance, it may seem that it is impossible to conduct some kind of seamless dialogue in such a structure, but this is a matter of time and habit. Even for simple projects, you can ask a huge number of questions, with a deeper understanding of the implementation details.
It is worth paying attention to the recording of responses. Otherwise, it will be very difficult to give an assessment in the future (you can forget anything)
Also, in such an interview, it is necessary to allocate time to talk about the project, to the candidate’s questions.
Conversation with TL
Well, the technical interview is passed, now the interview with TL. I would not even call it an interview, rather a conversation to find a general flow of work. Or a TL interview for adequacy.
The candidate is looking for a comfortable place of work for himself, where his nervous system will be at rest, where he can receive adequate feedback, develop and be part of the team. Everything that I have listed depends on the TL of the team. And the task of the candidate is to determine whether the TL is toxic, but the task of the TL is to determine whether the candidate will be able to interact with the team and with him.
There are no rigid criteria for evaluating a candidate. Perhaps the result of such an interview will be some semblance of a psychological portrait of the candidate, but this is already a cosmos.
Usually, a decision is made here about the possibility of cooperation with the candidate.
Feedback
The most controversial part of the article.
Not everyone writes detailed feedback at the end of a technical or non-technical interview. Sometimes there is simply not enough time, but I think the feedback to the candidate is a good trend.
Feedback should reflect both a good understanding of topics and gaps in knowledge. And this feedback should be aimed at ensuring that the candidate, after a series of interviews, can improve the level of knowledge.
I often attach the necessary articles on topics, some sources of information, general recommendations that will help the applicant to improve the level of knowledge. Who knows, maybe in a few months (or years) we’ll meet again for an interview.
Conclusion
What is it all about?
The fact that even such a “conveyor” process as interviews can have a human face, where each applicant is given a sober assessment without arrogance (which is sometimes found in interviews in some companies). And the process of giving this assessment is not just the opinion of one person, but a whole system.
In turn, the system must be debugged. With a competency matrix, with assessment criteria, with atypical questions and a friendly attitude towards the applicant.
The article is essentially a blueprint of the interview process, which actually builds up in a relatively short time.
It seems to me that with such a process, you can very quickly assemble a team that will move mountains.
Acknowledgments
This article is the collected thoughts of many people whom I have met during my work. They shared their experience with me, partly mentored me, together with them we created some processes within the companies, and someone was just a good example.
I want to thank:
Senior Frontend – developer Dmitry Tusaev,
PM Andrey Ponomarenko,
TL Yuri Sekin,
L&D specialist Nelly Lakosin,
HR Elizaveta Lagireva,
TL Stanislav Shurupin,
TechLead Backend Dmitry Yakovlev
