How Quadcode Hires Technical Specialists

Hi, Medium. My name is Darya Postolaki and I’m an HR manager at Quadcode. The hiring process differs from company to company, and therefore it’s nice to know in advance what to expect from a potential employer.

In the article, I’ll show how the hiring of technical specialists is organized in Quadcode. You’ll find out how many stages our candidates go through, who they’ll need to talk to, and what questions or tasks they may encounter along the way.

Stages of Interviews at Quadcode

Our teams mainly have vacancies for developers at the Middle level and above. When hiring technical specialists, we have three flows of interviews:

1. Standard.
2. With two technical interviews.
3. With a test assignment.

Standard Process

The most common flow consists of three steps:

1. HR screening.
2. Technical interview.
3. Final interview.

HR screening: 30 minutes. This is a mandatory stage for all vacancies. It involves the candidate and the recruiter. The purpose of the screening is to check the basic match and send to the hiring manager the resumes of those candidates who are potentially suitable for us and are interested in working in Quadcode. Here we check the knowledge of English, talk in detail about the company and answer all the questions of the candidates.

During the screening, the recruiter compares the expectations indicated in the vacancy with the candidate’s experience. We ask about past projects, the role and results in these projects. If the vacancy presumes specific knowledge, then we ask additional questions on experience in this area. For example, this might be a confident knowledge of classical algorithms and the ability to design highly specialized algorithms based on them.

It’s important for the recruiter that the hiring manager has complete information, and they can make the decision as to whether we communicate with the candidate further. We inform the candidate about the decision based on the results of the HR screening within one working day.

Technical interview: 1–2 hours. The purpose of this stage is to check the candidate’s hard skills. From Quadcode, the hiring manager and recruiter will be at the meeting with the candidate. The hiring manager is a team leader or the most experienced developer from the team, savvy not only in technology, but also in the issue of conducting technical interviews.

Sometimes the team leader and the lead developer of the team communicate with the candidate together. Such tandems help our developers gain experience in conducting interviews, and managers — to hear a second opinion that they trust. If the vacancy is open in two teams at once, two hiring managers may be present at the interview. They both ask their questions and evaluate the candidate together, and then agree among themselves whose team the person is more suitable for.

A recruiter at a technical interview is more of an observer. They can ask a couple of questions, but mostly just look at how the candidate interacts with potential colleagues. If the hiring manager has been conducting interviews for a long time and copes with it very well, the recruiter may not be present at the meeting.

The technical interview itself consists of two parts:

1. Theoretical questions on language and technology. There may also be tasks to find an error in some code or questions about what the result of running the code will be.
2. Live coding. Usually we ask the candidate to write a piece of code or modify an existing code. The candidate writes and narrates their actions, and the hiring manager guides them, if necessary.

We get back to the candidate with feedback on the results within two working days. If everything is fine, then we invite them to a final interview.

Final interview: 1–1.5 hours. This stage is mandatory for all vacancies. Its purpose is to once and for all check the candidate’s soft skills. The most people participate in the last interview. The options may vary, but usually they are a recruiter, team leader, head of area and HR BP. If the vacancy is open in a business unit, then a product manager joins the meeting.

At the stage of the personnel application, we form a desired portrait of the candidate’s competencies from the point of view of soft skills. For the final interview, we prepare questions based on the risks that we saw at the previous stages, and the competencies that we want to delve into more deeply. To test each competency, there can be from three to five questions to look at the candidate from different angles. We’ll talk more about this in the chapter of the article about evaluation of soft skills.

Managers, HR BP and a product manager can also ask their questions at the final interview. We try to make the narrative smooth, so that we get dialogue with a soft skills bias. We’re no longer discussing the technical part at the final interview.

The decision on hiring. We get back to the candidate with feedback and a decision within two working days after the final interview. The decision is made collectively at a meeting of all the people who participated in the interviews. There is no such thing as someone’s word having more weight: we usually agree.

After all the stages, we make an offer to the candidate or give feedback on the reasons for rejection. We try to send a detailed response to all candidates who aren’t currently suitable for us. We identify their strengths and areas for growth that should be strengthened for the opportunity to be interviewed again for Quadcode. More than once there were situations when candidates improved the necessary skills, returned to us and received an offer.

In the basic flow, the candidate needs to give us 4–5 hours of their time. From our side, the whole process usually takes about a week. For example, on Monday, the recruiter talked to the candidate, a technical interview was scheduled for Tuesday, and on Thursday we held the final interview and made a decision. The deadlines may increase if we follow the extended hiring flow with a test task. It also happens that the deadlines are stretched due to the candidate’s vacation.

Based on the results of almost every interview, we check with candidates as to their current job search status. If we understand that the candidate we’re interested in has an offer with a looming deadline, then we accelerate as much as possible and try to make a decision as quickly as possible. Then the whole process may take 2–3 days.

Two Technical Interviews

The choice of hiring flow depends on the wishes of the hiring manager. At the HR screening stage, we’ll definitely warn the candidate as to the procedure by which their interviews will take place. In the case of two technical interviews, the process is as follows:

1. HR screening.
2. Technical interview.
3. Second technical interview with live coding elements.
4. Final interview.

As previously, at the first stage, we get acquainted and talk about the candidate’s experience. Next comes the first technical interview, where we ask the candidate basic questions about technology. Usually this is theory or simple tasks.

If everything is ok, we call the candidate for a second technical interview. Elements of live coding and more complex tasks are already appearing here. Successful candidates after this stage are invited to a final interview. The whole process for applicants takes the same 4–5 hours.

Process with a Test Assignment

The third option for the hiring process involves a technical assignment:

1. HR screening.
2. Technical interview.
3. Test assignment.
4. Final interview.

We try to avoid test assignments as much as possible; there are almost none in the IT area. For example, we may give a test for Junior positions where there’s a large flow of candidates. Or for a very complex position if you need a person whose task is to be responsible for the architecture of a large project and its performance in the future.

As a rule, our assignment takes from 4 to 8 hours. We ask the candidate themselves to indicate the deadlines for completing it; our wish here is that they should be no more than a week. If there are good reasons for an extension of the deadline, we ask candidates to warn about it in advance.

How We Assess Hard Skills

The technical interview includes theoretical questions and live coding or code review. The details of the process vary from team to team, so we’ll give a couple of examples.

Denis Milovanov, Team leader and hiring manager for the Trading Platform team:

The technical interview for my team is divided into four parts. I always announce this plan at the very beginning. Approximate time:

1. Acquaintance — 10 minutes.

2. Questions on theory — 20 minutes.

3. Live coding — 40 minutes.

4. Checking SQL knowledge — 20 minutes.

During the period for acquaintance, I talk about what kind of person we’re looking for in the team and what kind of stack we have. This is a kind of warm-up. We may finish this part in the question-answer format, where I answer the candidate’s questions.

Then the technical interview itself starts. We start with questions on theory — this is the primary scoring. Here I want to understand that in front of me is really a Go specialist, and they know the language well. To get them up and running, I ask simple questions: basic data types in Go, how to handle errors, how to work with panics, etc.

Then the questions become more complicated, for example: “how does the select operator work”, “what will happen if you read from a closed channel”. I conclude this part with questions about the architecture of applications: for example, “what is idempotence” or “how can two instances of an application agree and not do the same job” and the like. According to statistics, most candidates get through the theoretical part well.

The next 40 minutes are live coding. The platform can be any that’s convenient for the candidate. Sometimes people just share their screen because it’s convenient for them to work in their editor. Also at this stage I allow Googling, because not everyone recalls certain things from memory, and I’m interested in how quickly a candidate can find the answer to their question in a search.

I give candidates a basic task to write business functionality. The task isn’t algorithmic. It usually takes about 10 minutes to write a setup. And then we start to complicate it. I say, “Let’s add this and this. And what if, like this?”

The task implies various solutions. None of them is more correct than another. Therefore, at this stage I look at how the person thinks and how they communicate. For example, how they clarify boundary conditions, consult on solution options or explain their choice.

As a result, we come to an architectural discussion: what it could look like in a real project and how the system could be developed in the future. Since I interview mostly senior engineers, I’m interested in listening to their ideas.

We devote the last 20 minutes of the interview to SQL. We have a lot of databases, and SQL is an important language for us. Here I have a small setup of two tables, and the candidate needs to register queries that do something with these data.

I’ve conducted quite a lot of interviews in this format, and it’s still amazing to me how differently people think, and do things, and how different everyone’s background is. This makes each interview unique.

Alexander Muravsky, Team leader and hiring manager for the Risks team:

We spend an hour and a half on a technical interview. It consists of two parts:

1. Theory.

2. Code review.

In the theoretical part, we ask the candidate questions about Golang and databases. Of databases, we’re primarily interested in PostgreSQL, sometimes we may ask about Redis.

We start with simple questions and an understanding of general things. If everything’s ok, then we complicate the questions up to the Senior level. For example, I’m interested in answers about what panic is and where it can be used, or what zero allocation is and where it’s used. When the candidate is answering, it’s interesting to find out their opinion and discuss it together.

After theory, we move on to code review. Depending on the remaining time, it could be one or two code fragments. One usually takes about 10 minutes. We imagine a situation when our request came to the candidate, and we need a comment on it: what they don’t like, what should be changed, and any other comments.

Code review helps to understand how deep a person’s knowledge and experience in Go is, how familiar they are with the best practices and what their overall understanding of the organization and patterns of writing code is.

I advise a candidate to respond honestly here if they don’t know something. They shouldn’t worry that they miss an answer to some question. At the interview, we check their overall body of knowledge, and if they don’t know some small detail, it doesn’t mean that they won’t fit in. For my part, I try to help with leading questions. We don’t require an ironclad knowledge of everything — sometimes a fundamental basis and the ability to reason based on our experience are important.

How We Assess Soft Skills

The recruiter meets with the hiring manager and clarifies the competencies needed by the candidate before the vacancy is published. To create the list of soft skills that we evaluate at the interview, we:

• Ask what soft skills are important in the person who’ll join the team.
• Clarify which person won’t work out.
• Collect background information about the team: what kind of person is currently missing to improve results.

The final portrait of the candidate usually includes three to five competencies. Here’s an example from the Compliance Development team:

• The ability to work in a team — talks about problems, compromises, is ready to help.
• Organization — doesn’t come late, doesn’t trip up others, is independent, doesn’t need micromanagement.
• Stress resistance — is able to cope with stress, isn’t lost when the main flow breaks down.
• Work for results.
• Ambition.

Based on the list of competencies, we prepare interview questions. 3–5 questions are allocated for checking each competency, because a conclusion made on the basis of only one answer is highly likely to be incorrect. We try not to ask questions from one block sequentially, but build a logical dialogue with the candidate. Otherwise, the interview risks looking like an interrogation.

Different Quadcode recruiters use different assessment techniques and tools, or a mixture of them. These could be:

• The methodology of Ichak Adizes.
• Projective questions.
• Case interview.
• Profiling: psychotypes and metaprograms.
• S.T.A.R — situation, target, action, result.

The choice of an evaluation tool doesn’t affect the process for the candidate in any way. The interview remains just a dialogue.

For example, for a team lead, the skill of working with a team is important. To test this competency, we might ask:

• Tell us about your most pleasant/unpleasant experience of working in a team.
• Have you ever worked with people who were difficult to interact with? Why were they, from your point of view, difficult? How did you work things out with them?
• Tell us about a case when you asked colleagues for support in solving a task or a problem.
• What did you do when your colleagues didn’t support your proposal or idea?

Projective questions, on the other hand, ask the candidate to immerse themselves in some other person’s situation. The method is based on the hypothesis that a person is inclined to transfer their life experience to explain the actions of others. For example, we might ask:

• What do people like about work?
• Why do people aspire to a career?
• What should a good employee be like?
• Why do some people work according to the same models from year to year, while others try to make changes and optimize processes?

Answering the question about what people like about work, the candidate is likely to hold forth on what they like: interesting tasks, a common vibe with the team, employer bonuses or salary and awards. The recruiter here looks at the motivation of the candidate: what motivates them, what’s important to them, what kind of relationships are they used to building with the team, what are their priorities.

The case is most often not tied to the verification of a specific competency; we ourselves extract the things that interest us from the candidate’s answer. It might go like this:

We have a task facing us. We’ve gathered for a discussion, and within the framework of it we need to work out a solution to the task. There’s a proposal with solution A, there’s your solution B, and there’s the rest of the team with a neutral position. What do you do?

There’s no single correct answer here. We look at what the person thinks about first of all, how they make decisions, what arguments they bring, whether they’re ready to defend their position if the group is opposed.

During the interview, the recruiter briefly records the candidate’s answers in a separate document. Then we analyze them and compare what we get with the portrait of the employee we’re looking for. You get a clear result, for example, three competencies are confirmed, and one isn’t. We also draw conclusions about the motivation of the candidate and what risks their hiring may involve.

Of course, we look closely at how the candidate interacts with future colleagues in the communication process. It’s important that these people feel comfortable working together in the future. After the interview, we also check with the candidate as to whether they were comfortable and liked the team. And already having this data in our hands, we collectively decide on an offer or rejection.

Checking soft skills is also necessary in order to understand what things in the work process may disrupt adaptation of the candidate. This helps to give recommendations to the hiring manager about what will be important when communicating with the future employee, how to maintain their interest and build a long-term working relationship.

Summary

The hiring process is similar to speed dating, where both parties aim to quickly learn as much information as possible about each other in order to understand whether there’s a match or not.

The task of the recruiter is to help the candidate to open up in the interview as much as possible and show their strengths. Therefore, participate actively in the interview, ask questions, argue. The main thing is to try not to answer in monosyllables, so that there’s an opportunity to build a dialogue and better understand each other.

You can find our open positions on the website. We look forward to hearing from you.