About hiring. View from there
A short preface
I was inspired to write this article by my recent communication with HR of Russian companies. And my considerable surprise is how poor, disorganized and makeshift it looks compared to their colleagues on the other side of the globe. This looks very surprising, considering that many, if not most, Russian software companies are guided by Western practices. But for some reason this “view” does not transform into borrowing and adapting hiring practices, but any company is formed by people. Hiring people is the first thing all founders face: who to take with them? Who can do this or that? Where can you find such people with the right motivation? And money won’t always help here. To paraphrase Machiavelli, the right people will bring you a lot of money, but I doubt that a lot of money will attract the people you need. Therefore, finding, assessing and hiring the right people is a very important part of the company's foundation and it cannot be a bad thing. You cannot build a good house on a bad foundation. My goal in this article is not simply to criticize Russian companies, but to try to point out obvious problems and, perhaps, suggest possible solutions. If Russian companies are going to become big and international, and I hope they are, then we need to work on problems.
A small note. I am not a personnel officer and everything I write below is my personal experience of many years of working in the USA and my impression, which may differ from the real state of affairs.
About hiring in the USA (FAANG)
It’s worth talking a little about how hiring happens in BigTech in the USA and how the hiring process itself works.
Let's start a little from afar, namely with the question of what, exactly, does HR do? What role does he play in the organization? What is his strategy? Abstractly speaking, strategic HR helps to organize life in an organization in such a way that it most clearly corresponds to the business goals of the organization. And the larger the organization, the more formal and more detailed HR planning becomes. HR (strategic) is not only hiring, but also the life of an employee in an organization in general, namely:
Planning for the future workforce (should we hire or fire? how many? who? how much will it cost?)
Training and competencies (whom to teach? what to teach? how?)
Performance (does the staff work well or poorly and why?)
State Assessment (Who do we have and what are they doing?)
Motivation (how motivated are employees, how many want to leave and what to do about it? who to promote, etc.)
Competition for labor (How do we attract people? How to do it to attract more, etc.)
These are the main issues that HR deals with at the organizational level.
About imitation
I have seen that many Russian companies copy, sometimes very blindly copy, the practices of Western companies. It looks very funny sometimes. Please understand that these companies are located in the USA, they are subject to legal, cultural, economic and other factors specific to the USA. The size of the company, its business goals and its financial position, again, form a unique picture. It's all interconnected and it all affects how big, and sometimes not so big, companies hire people. You should not blindly copy practices, without taking into account the specifics and detailed understanding of the reasons why these practices were introduced, how and under what conditions they work.
About corporate culture and psychological interviews
Bigtech are huge companies. The largest is Amazon – 1.5 million employees, the smallest is Meta with 65 thousand employees. With such numbers, managing such a company is like managing a small town with its own culture, its own demographics, clans and its own problems. In such companies it is physically impossible to keep track of everyone. It is impossible to read all the reports of all managers and decide to whom and for what to allocate money, and who to fire. Therefore, the “company culture” that HR inculcates plays a big role here. This and 14 Amazon PrinciplesAnd Googleyness in Google, and Meta's “Be Bold.” Make impact. Live in the Future” and so on. Each company, from a certain size, begins to develop and inculcate its own culture, which is subordinated to business goals (yes, it’s always about money) and simultaneously solves both management issues and issues of attracting people. Companies do this not because these are “fashionable practices” and everyone does it, they might be happy not to deal with all this “bullshit”, but it is simply impossible to do otherwise. (Once again about copying – you don’t need to copy it blindly. These are American companies operating in American conditions, which are very specific, with people from extremely different societies, which is also very specific. You need to comprehend all this and develop your own approach.) Because culture is very important for the company, no matter how nonsense it may seem, almost all BigTechs include a round called a psychological interview (behaviour interview). Amazon goes even further, with each round of interviews containing one or two questions about the 14 principles. It is impossible to pass all the technical rounds but fail the behavioral interview and get hired. Some details about such an interview from interviewer Meta*
Questions for each stage of the interview are selected very carefully. There are no random questions here, and every question, right down to the wording, is chosen so as to receive one or another “signal” from the candidate. It almost never happens that the interviewer sits and, looking at the ceiling, thinks “what else should I ask?” It’s hard to speak for all companies, but Google and Meta have their own pools of questions that can be used in interviews. Of course, they are constantly updated and supplemented – some questions are removed, others are added. Statistics and notes are kept on all issues.
As a result, the candidate is assessed both from a technical and psychological/cultural perspective, and for engineers the interview structure looks something like this: two or three rounds of coding/algorithms, one or two rounds of design and a round of psychological interviews. They try to select questions in such a way as to find out a specific skill, experience or behavior. The company wants to know who you are and what you are capable of and a little about your training. Knowledge itself does not play a role if no conclusions are drawn from it. For a large company, it is strange to hire a person who knows several programming languages, but is not able to master another one. On the other hand, if a person is able to master any programming language, then it is strange to demand knowledge of a specific one.
About the coding task
The technical part, unlike the psychological one, will probably be a little more understandable. This assesses the candidate's current skills, training and ability to solve problems in general with the range of available tools. Two types of interviews: coding with algorithms and design.
The coding part is probably the most formalized. Given a problem, he gave a solution. The code will need to be written on the board, sometimes in the IDE – everywhere is different. The purpose of this or these rounds is to understand whether the candidate can write code, whether he knows the most popular algorithms and whether he can apply them. In a particularly difficult case, but here I am not very sure, intuition and creativity in relation to algorithms and coding are tested.
What is assessed when solving a problem? The problem, of course, needs to be solved, this is the main thing, but there are some reservations. If a candidate, having received a task, immediately starts solving it, this is a bad sign. It takes about 45 minutes to solve the problem, and this time includes several stages – setting the problem, clarifying the requirements, explaining the algorithm, the code itself, discussing the solution and testing. Jumping straight to the solution can reduce the rating down to a negative one with the wording “The problem is familiar to the candidate. There are few signals to evaluate.” Optionally, if you have time, you can give one more task and this will be a plus. However, if the solutions for both problems are written down in complete silence, then this is a big minus. Communication is important. Reasoning is important.
About the design task
Design is a little more complicated, but this is where experience is assessed and there is room for both the candidate and the interviewer. Relatively speaking, the purpose of this round is to evaluate the candidate’s ability to approach large and complex problems, the ability to break them into parts and, ultimately, assemble a solution from these parts. There is no need to have detailed and in-depth knowledge of any specific technologies, although this would be a plus. If you have experience and know it, great, but if something is missing, then it’s not a big deal. The point is a little different. The point is to assess whether the candidate is able to see problems, understand their depth and find or synthesize some kind of solution, be able to evaluate the pros and cons of this solution, etc. Design and architecture are always various compromises and prioritization of various properties of the resulting system. There are no clearly correct or unequivocally incorrect answers, there is no dogmatism. The candidate is not required to know SOLID or Clean Code, like the Lord's Prayer, but if such a topic comes up, he must explain why these approaches were chosen, what their advantages are, what their disadvantages are and how they could be mitigated, etc.
A few words about what is NOT asked.
They don't ask about deep knowledge of a particular technology. There are, of course, exceptions, but in general no. It doesn't matter if you know the details of how the garbage collector works or how many ways objects can be created in java. Nobody asks you to know the API of standard libraries by heart. There are no questions like “what will this code output”, etc.
Usually, knowledge of any specific language is not required. Maybe, as an exception, C++ only. It is enough to know and be able to use at least some language: Go, Java, Kotlin, Python, C, etc. It is taken for granted that one can master any language in three or four months.
No specific tool knowledge is required. No one will burn at git commands with tricky rebases and merges. Nobody demands to know the configs of Kubernetis or Docker or anything else by heart. Microsoft, for example, has so many internal tools that it is simply not reasonable to require knowledge of them.
About interviewers and hiring decisions
Interviewers are also not completely random people. Just anyone is not allowed to be interviewed. Everyone undergoes training, which explains in detail how to behave during an interview, what to pay attention to, and what can be ignored. In some companies, interviewers do not make recommendations to hire or not to hire. Instead, they write a report, which is then reviewed by the hiring committee. This makes the assessment process less subject to personal preferences of interviewers and less volatile.
Etiquette
Overall standard business etiquette and respect for the candidate's time. Lateness, if it happens, is extremely rare. Everyone understands that candidates have their own schedule, and someone may have even taken a day off just for the interview and canceling or postponing it is a waste of time and resources. Cancellations and transfers will not be made without a valid reason. Everyone is doing their job. No snide or caustic questions, no personal assessments like “you are not qualified enough” or “your Java knowledge is poor.” You can't answer like that – it's very rude. They simply inform you that they are not ready to make an offer and invite you to try again in a year.
The hiring process in BigTech is complex, tries to evaluate candidates from all sides and is tailored to the global goals of each specific company. The higher the candidate level, the more rounds there will be. For a beginner, for example, you can skip the round on design; for an experienced developer, there may well be two rounds on design; for a team lead or manager, you can do one round on coding, but add a specialized round on leadership skills and project management. This process works well for wealthy companies with a good budget, but small companies also use it in some simplified version.
About hiring in Russia
How are things going with hiring in Russia? In short, “so-so.”
Lack of strategic HR
Of all the companies I interviewed, none showed signs of strategic planning. Most often, hiring falls on the project (or department) manager, who determines (if he determines) the structure of interviews and the types of questions. Companies do not plan for staffing needs and have no plans to develop the skills of existing staff. Most often, this is simply profanation in the form of purchasing courses that teach skills that are not used in companies. The entire strategy for attracting candidates comes down to the issue of upper and lower salary limits. This is certainly an important parameter, but far from the only one. For some reason, issues of employee retention are left to immediate managers, in the absence of a general strategy and motivation system at the organizational level. The positioning of companies (HR brand) in the labor market is very weak – it all comes down to “we pay more” or “we have cookies and ping-pong.” The median age of a developer is 39 years old, what kind of “ping-pong” are you trying to tell a person with a mortgage and a family?
Lack of structure for the interview process
But the biggest sin, in my opinion, is the lack of a well-structured and clearly defined hiring process. Only Yandex and Sber have some fragmentary understanding of how this process could be organized. But most often it is not organized in any way, to the point that the interviewer does not know in advance what questions he will ask. Almost no one collects or stores information about candidates and interview results, let alone analyzes the process (no process, nothing to analyze). Most likely, information about candidates who did not pass the interview is simply thrown out. No one tries to invite them for a second interview after some time. Due to the lack of a unified assessment system, as a result, no one tracks the candidate’s growth/stagnation compared to his previous attempts. As a result, the quality of hiring remains questionable, and the lack of a system does not allow identifying problem areas and finding ways to eliminate shortcomings.
About interviewers
The main difference, with a few exceptions, among our interviewers is their excessive arrogance. Sometimes justified, but more often not. Sometimes, it seems that the interviewer's main goal is to find a question that the candidate cannot answer, regardless of whether the question reveals the desired qualities or not. With a sound hiring process, HR should certainly not tolerate this kind of behavior in interviews. Ideally, each interviewer will undergo a short interview training where they will be told how to conduct an interview correctly. Just remember that knowing how to program and understand Kubernetis is not something that is difficult to master or requires a lot of mental effort. Almost any sufficiently diligent person is able to master this, fortunately there are plenty of textbooks, training videos and other documentation in the public domain. The rest is experience. In general, there is no point in turning up your nose here; on the contrary, arrogance is more a sign of incompetence than qualifications.
The next “sin” of our interviewers, which is often encountered among their colleagues in the West, is the lack of understanding of WHAT they are looking for in a candidate and, as a result, they do not understand HOW to look for it. As they say, if garbage in, garbage out. Here, probably, the limited transferability of knowledge and skills is quite clearly demonstrated. Developers who understand program testing well cannot translate similar techniques to testing people, even in basic principles like “what are we testing”, “what methods”, not to mention more advanced techniques for assessing the effectiveness of testing. Simply put, the ability to test programs and software systems does not translate into the ability to test (test skills and knowledge) people, despite the similarity of the process. Hence there is no understanding of either the purpose of the questions asked or the answers received to them.
What are we looking for
Due to the biases described above and the lack of a system, interview questions at best test whether a candidate knows a specific API or language syntax and do little to test their skills and ability to solve problems encountered in real work. Of course, knowing the intricacies of the language syntax or any features of the API used is a plus and somehow helps in the work, but there is one problem. Languages evolve, and tools and their APIs change. Worse, the given knowledge is not even the basis for new ones. Let me clarify my idea a little here. Yes, familiarity with one programming language helps to learn another, experience using one API helps in mastering another. However, this is a horizontal transfer, not a vertical one. One language is not always an extension of another, and new APIs often use new idioms altogether. In this case, by hiring on the basis of such volatile knowledge, the company risks getting an irrelevant employee within a year. Of course, if a company is hiring for an urgent project, then this approach is quite valid, but more often the hiring is for an indefinite period. If specific knowledge quickly becomes outdated and does not meet the needs of the company, then what should you ask in an interview and how to evaluate the answers? Each company must find the answer to this question in detail, but in general, you can think and find some recommendations based on the experience of Western colleagues (adapted, of course).
Candidate image
In relation to developers, we need to look at it as a whole, what do they actually do? Various programs will be sent, or developed, but this is only part of the answer. The second part is that they write and develop these programs based on verbal descriptions. Sometimes detailed and clear, but more often quite lengthy received from non-specialists. that is, the developer is the one who transforms the requirements into a program, clarifying them along the way and resolving conflicts that arise. From here, in my opinion, we can determine WHAT we are looking for, and from here follows the following set of skills that a candidate must have:
Some basic knowledge and skills. (Most of this knowledge and skills are obtained in specialized universities. Whether to trust them or not is a personal matter. You can only conduct a sanity check.) This knowledge and skills usually include basic algorithms and data structures, knowledge of at least one programming language and a certain general outlook .
The ability to analyze a problem, that is, break it down into parts, determine the properties of these parts and synthesize a solution
Ability to convey your idea
Be a team player (usually this just means not being confrontational, being open to criticism, and not causing problems in general)
Understand the goals of the company or at least the project
Some additional requirements depending on the position and nature of the work, which each company must determine for itself.
These are approximately the qualities that most companies want to see, even if they do not realize it. It would be ideal if each part is checked in a separate interview, which will probably make the process more expensive, but the task will be easier for the interviewer. If you combine everything into one or two interviews, this will create a greater burden on the interviewer and require more experience and preparation from him. In any case, it's good to have three clearly separated parts: coding, architecture/design, behavior.
Coding task
As mentioned above, the goal of the task is to understand how much the candidate has coding skills and how he applies popular algorithms and data structures. You can also include questions on knowledge of the syntax of the language, if this is really important. Problems need to be selected so that reading the conditions does not take too much time, and the solution is not too long, but not too short. Be sure to have two or three tasks in reserve, in case the candidate is familiar with the task.
No need to give a problem that you found an hour ago on leetcode. The interviewer must have a good understanding of how the problem is solved, what problems there may be in each solution, what tips to give and how to evaluate the solution. Otherwise, the interviewer is simply not ready for the interview and risks failing it, i.e., missing out on the right candidate.
In general, it is not necessary to set problems in leetcode style. You can come up with another format if it allows you to assess the required skills of the candidate. It is only necessary to accurately distinguish the assessment of skill from the assessment of background knowledge. For example: writing a traversal of a tree counting something at each vertex is a skill, but implementing bubble sort or even worse, asking about the structure of strings in Java is a reference book. Asking for background knowledge, as well as the implementation of a popular algorithm, does not make much sense. They do not signal the skill of using the algorithm and can say little about the ability to construct a solution. And this is precisely what is most important.
My top useless questions asked in interviews:
Tell us how GC works in Java.
Name the classes from java.util.concurrent or some other package or library
How does Hashmap work?
How does Red‑Black Tree work?
How much memory does an object take up?
Write a singleton. (and further with all questions up to thread‑safe singleton)
If you really need the candidate to know these things from memory, then you can simply ask him to learn it before the interview, and just test his knowledge at the interview.
Design and architecture task
Here, as many say, there are no right or wrong answers. In general, the task should be such that it cannot be fully covered during an hour-long interview. Both in breadth and depth. The task is specifically set as broadly as possible and it is the candidate’s responsibility to reveal it as widely and as deeply as possible. Here you need to clearly explain what you want from the candidate, and gently guide him in the right direction if he suddenly “flies into the stratosphere.” The goal is to understand how the candidate copes with complex and unclear problems and how much experience he has in the area of interest to the company. The candidate should speak 90% of the time in this round, and the interviewer acts more as a reference and sometimes asks questions. As was said earlier, the main thing here is the ability to analyze the problem and synthesize a solution. Of course, within the professional domain area of the candidate. You probably shouldn’t ask a backend developer a question about the design of a mobile application. The point is not to get the “right” answer or an answer that is similar to a system implemented somewhere – after all, this is an interview, not a system design – the point is to find out the specific abilities and experience of the person.
Again, companies may choose to use a different format that is more relevant to their goals and the area in which they operate.
What should you pay attention to in this interview? The task is given in the most general form and it needs to be “revealed”, which means communication is needed. If the candidate begins to just silently draw squares on the board, this is a big minus. Further, how realistically are the boundaries of the system delineated, how clear are the requirements for it, at least at the top level, and is all this based on some reasonable assumptions. What approaches have been chosen and to what extent these approaches meet the requirements of the system. Is the candidate with his head in the clouds and designing a “spherical system in a vacuum” or is he too carried away by the details as opposed to the overall structure. There are a lot of aspects in this round and, as already said, it must be specially structured so that it is impossible to cover all aspects during the interview. For Russia, the specificity of this section will probably be that the industry here is not sufficiently developed and operates on a slightly different scale. And, although the training of Russian specialists is on average very high, they still have less opportunity to work on truly global and complex projects. Because of this, some aspects of design may elude Russian developers or may not play a big role.
What are our interviewers doing wrong here? The first is a cargo cult interview. It's similar in form, but in essence it's completely different. Probably, our interviewers believe that there is a correct answer and are trying to assess how close the candidate is to the “ideal”. The second is the dogmatism of the approaches, which is very strange for me – SOLID, DRY, KISS, MVC, MVI, Clean Architecture, GRASP, SQL vs NoSQL vs NewSQL, there are a legion of them. That's not what this interview is about. Third, excessive pickiness about details that are not key to the given task. For example, what is better, throw an Exception or return an error code and then discuss this case for half an hour.
Similar to a coding interview, at the end you can go through the checklist and give a certain score to the candidate (for yourself).
At the end of the interview, the answers to questions like:
Can the candidate code? Does the candidate understand the task? (sometimes they don’t understand, but they are already writing a solution). Did the candidate voice the solution algorithm? Does he have a good understanding of algorithmic complexity? Have you considered/suggested alternative options? Does he listen to the interviewer's prompts and how does he react to them? And similar questions. It’s just that no one is interested in solving the problem.
For each positive answer, you can assign a point, which, when added up, will give the final grade for this interview.
Behavioral interview
A behavioral interview for Russian IT will probably be the most unique and unlike a similar interview in Western companies. If Western companies value independence and openness, as well as adherence to rules, then in Russia diligence, obedience and adherence to traditions may be valued. In the USA, people prefer to be polite and are afraid of offending a person with the truth, but in Russia they prefer the truth to politeness. In the United States, a culture of communicating with hints and half-hints has been developed, while in Russia they prefer directness. In Russia, life and work are intertwined very closely, but in the USA there is a clear boundary between these areas. In general, there are many cultural differences that should, of course, be taken into account. Otherwise, everything depends on the company, its leadership style and its internal culture (or lack thereof). In any case, it seems to me that the most important thing in this interview will be the opportunity to get answers to the following questions:
What are a person's goals in general?
Is he interested in IT in general?
Is he interested in the company and product (or project)?
How does he interact with people?
How conflicting is it, let's say?
This is not a mandatory list; each company defines it differently. It seems to me that the answers to these questions will allow us to form a definite opinion about a person. Will he be conflicting or, on the contrary, will he become the soul of the party? Does he like what he does and does he have professional pride that does not allow him to do a bad job, or does he just work for money (which is also quite suitable for some types of projects)? Did he come to the company because “your product is complete crap and I want to fix it” or did he come because “your product is very cool and I want to get in on it”? Overall, will such a person bring more positive or more negative to the company? It is difficult to give any specific examples here; everything very much depends on the company itself.
Decision and evaluation
So, we conducted a series of interviews, even if it was all compressed into one hour (although I can’t imagine how you can fit everything into an hour and get meaningful signals) and need to decide whether to hire or not. One of the main properties of this process is that it should be as independent as possible from the personal preferences of the interviewers.
One of the simplest, but not without costs, methods is consensus – all interviewers must give a positive or at least not negative answer. Or 2 out of three. Or 3 out of 5, etc.
Another option is to simply add up the scores for each round and hire the one with the highest number.
For large companies with mass recruitment, you can set some bar. Let's say hire the top 80%. For example, we score each interview from 1 to 5, and the passing score is 12 or higher (top 80%). The candidate received a 3 for coding, 5 for architecture and 4 for behavior. 3+4+5 = 12, which is passing. Of course, for greater accuracy, you can enter more parameters and points for each round.
After hiring
It doesn't end with hiring, of course. After hiring, you should also continue to collect information about the employee and compare it with information obtained during the interview process in order to improve and clarify the hire. For example: during a behavioral interview, an employee performed well, but later it turned out that he constantly gets into various conflicts. Perhaps you need to find out the reason and change the behavioral interview accordingly. Likewise in the other direction. We complicated the tasks for coding interviews, but this did not affect the number of bugs per person or, for example, the speed of project implementation remained the same. Probably, increasing the complexity of tasks does not increase the quality of candidates in this parameter. These are all illustrative examples and should not be taken literally.
Total. Strategic HR, based on the company's goals, among other things, develops a structure for hiring and motivating employees. Depending on the adopted strategy, a system for analyzing the effectiveness of these actions is developed. A set of required competencies is determined for programmers/developers. Next, the specific stages of the interview and the expected results of these interviews are defined. The goal is to collect as much information as possible about the candidate and find out at what level he has the necessary skills to perform his job duties. Depending on the skill set, the appropriate style and questions are selected for each round. Based on the results of the interviews, depending on the company's plans and recruitment strategy, a hiring decision is made. The entire process is analyzed and optimized from time to time.
Of course, the described system seems large and cumbersome. And this is true – its full form is not suitable for all companies – but I believe that there should be some kind of hiring system, albeit in a simpler form. Having built at least a simple system, it will be possible to evaluate it and gradually improve its parameters. Without a system, no matter how talented your interviewers are, the quality of your hires will always suffer. The system beats talent. People are an important element of the company’s foundation, and hiring people must be of high quality and systematic.
* Meta, Facebook are organizations banned in the Russian Federation
