By Kostyantyn Kolesnichenko, Desktop Lead at ENESTECH Software company.
Hi, my name is Kostyantyn Kolesnichenko. I am a Desktop Lead at ENESTECH Software company which is part of the TECHIIA holding. I will share my experiences on how to find the right people in the search for experienced developers and filter the ones with a lack of experience. The article is intended for fresh leaders and those who plan to become one. It will also be helpful for future candidates as they might learn what to expect at the interviews. And I will be grateful to experienced colleagues-managers for feedback and cases in the comments.
I have been working in IT since 2004. In my background, I have IMMSP (The Institute of Problems of Mathematical Machines and Systems of the National Academy of Sciences of Ukraine), game development, and mobile software development. In recent years I have been working for ENESTECH Software, where I assembled a team, created a workflow, and headed various departments. Our main product — SENET — a SaaS-service for LAN gaming centers and cyber arenas, which is used in 60+ countries. The development team now consists of more than 20 people.
In this article let's talk about the following:
- how much does a hiring mistake cost?
- what and why should be highlighted in the vacancy
- what to look for in resumes, PET projects, at meetings
- how to structure an interview
- what to do if the candidate did not show up
Why You Should Work On The Proper Hiring
According to my observations, experienced developers are primarily looking for product companies and those who do not have time for a long start-up process and training. "Experienced" are the ones who faced real practical problems and were able to find solutions. Ideally, such a person knows where to look for a solution and how. Or at least has such an intention.
For others, experience is not always important. In a heated tech job market, companies are ready to take people almost from school to train them for their tasks. We'll talk about this later.
There are two stages that will help you identify a developer with little experience. The first and most important is the search itself and the interview. The second and less likely is during work if you didn’t identify such a developer at the first stage.
Candidates with little experience might occupy almost any position. Some, after working for six months, go to another company that can offer a little more. Many outsourcing companies are used to this, but because of this, you need to choose candidates very carefully.
Every inefficient hire has its price. My colleagues from other TECHIIA companies and I have calculated that the losses from the error amount to 6-9 monthly specialist ratings. Sometimes more, sometimes less. If this figure seems huge to you, here are some arguments.
1. The manager spends time searching and approving the candidate. Instead of performing direct responsibilities, he or she prepares requirements, reads the incoming resume from recruiters, attends interviews, gives feedback, and checks tests. There may be several such cycles.
2. An employee undergoes onboarding. For example, we are working on a product, so the chances of taking a person from the street who will start giving results in a week are almost zero. It might take a month at best. But in reality, it takes two or three months. All this time the company pays the developer to:
- read the documentation;
- understand the product/project nuances;
- establish communication with technical and other managers;
- set up processes;
- join the team.
3. A manager who has his/her own tasks spends time training a rookie. As a result, the team’s performance during the onboarding period may even decrease. On average, only from the third to the sixth month, the specialist and the team reach the level of productivity for which they took a newcomer. And this is normal.
If they take the wrong person, the resources are simply wasted. Both money and time are extremely important for a product company. It is most important to do your part to deliver the product or its updates to the market on time. If this does not happen, then the loss of money spent on hiring and onboarding will be the smallest problem. After all, a company can miss the right moment and never enter the target market again.
How To Create An On-Point Job Posting
Before giving the task to the recruiter, we determine what exactly the person will do. This will save the nerves of both companies and candidates.
Here is an example. When we were recruiting a team for SENET, we needed a person with three years of experience in Python Django for the backend, who could immediately get down to work. In my opinion, three years is just the right time for a person to go through a bunch of different tasks and learn to perform them independently.
But it is not enough to tell the recruiter: "we need a Python developer with three years of Django experience." Because such a candidate can make both web pages for the online store and a complex backend. Everyone has their own specialization. Some people like to work with databases, while others enjoy security or write mega-optimal code for working with the network. Therefore, we indicate the subject area and parts of the project we are looking the candidate for.
Then we add some additional points, such as:
- Education. Preferably profile one. Such specialists, in my experience, usually think more systematically. There are also exceptions: we have a developer without basic IT education, but this is offset by talent and great interest.
- Language. English at least at the level of speed reading and comprehension.
- Technical nuances. Conventionally, if we are looking for a person on Django, we need him/her to understand SQL, databases. For C ++ — to be able to work with WinAPI, apply modern technologies and patterns.
And, of course, we describe the work itself and its benefits. I don't know how many points about a friendly team, coffee, and cookies are needed, but it's kind of a tradition. Especially when it's true.
Here is of such a job posting. Before finalizing, we review the text again to remove the excess and highlight the nuances needed for a candidate to get to an interview, such as the experience of a particular domain.
The Initial Filters: basic questions, summaries, and pet projects
Before the first interview, the HR manager agrees on the basic questionnaire with the one, who is in charge of this vacancy. Usually, this questionnaire is about the experience, but for the last three years, I have also been adding"filtering" questions.
Here’s a simple example of a basic question: "List vs Array, what are they and how do they differ?". We helped recruiters understand the difference themselves so that they could immediately recognize when a candidate gives the wrong answer.
The basic theory survey filters up to 90% of unpromising candidates, especially "seniors with years of experience."
When a resume comes to me, I first look at the answers about the database. Next, about education. Then, about the experience. For example, a candidate worked in a bank, then worked for QA for six months, after which he became a programmer. There will be many questions. Or, for example, it says "10 years of C ++, 15 years of Python", but the person was a sysadmin. Be sure to ask the recruiter about the candidate's career path and make notes.
I also ask for work and pet project examples. If there is a link to GitHub, even just with tests or university labs, that’s great. It happens that a person does not want to be easily found in social media or with search engines or works under a strict NDA. Then he/she can send examples directly to you.
Regardless of the type of code, I'm interested in how a person writes. I pay attention to the structure, accuracy, and names. A typical rookie marker is the lack of its own standard: using uppercase and lowercase randomly, starting with an underscore in one case, while with two in the similar one. Copypastes from Stack Overflow are also recognized immediately. Most likely, during a live meeting, it will be difficult for a person to explain why he/she used this piece.
On GitHub, viewing the commit history, you can see how the code evolved. Sometimes there are a couple of commits in the project: the first is initial, the second is the rest of the code piled up. That is, the person sketched something and never came back. It is unlikely that this is a pet project, it will be difficult to discuss it.
We invite people with the most interesting education-experience-cases combinations and the corresponding specialization to an interview.
Interview Question Blocks: from basic to extended (but also basic)
The technical interview takes about an hour, on average. It’s split into the following conditional blocks.
1. Questions about the experience. At this point we introduce ourselves, make contact. When a person talks about the past and something close, he/she calms down. While I read the resume more closely, dive a little deeper into the specifics.
It’s a good time to ask about hobbies and preferences. With this, you can identify a specialist who leaves work at exactly six o'clock, and in his/her spare time switches to completely different projects. Not always, but often it is a sign that this person will leave after a while. Not because I am a fan of overtime for no reason, it’s just that the interest in another job will sooner or later prevail.
This is also true for professional directions. For example, if I take a C# programmer who likes to work on front-end development in his/her spare time, there is a risk that one day he/she will switch to it completely. That was my case when I left scientific activity and switched to game development where I worked for 10 years.
2. General questions. They can be applied to any programming language. The most basic are about arrays and lists: what are they, their differences, speed, what is the algorithmic complexity. Then we move on to trees, hashes, tables. We can talk about sorting algorithms.
An experienced person must first understand the basics. Where lists are used and where arrays are used. Why in one case the bubble sort is better than the heapsort. It is not necessary for a specialist to be able to do all this by hand, but he/she must know and understand when and how to apply it.
3. Position-wise specific questions. This is still not about libraries, but about the basic principles inherent in a particular programming language.
In the case of C++ and C#, I am interested in OOP expertise. A person can give three principles of the automaton: abstraction, subtype polymorphism, and inheritance. And polymorphism is a virtual function. Here I can ask: "And how do virtual functions operate in general?". If a person knows and talks about the virtual function tables, it’s a good point towards having the job. This means that the specialist understands the mechanism, not just uses it. This approach shows a high-level developer rather than a beginner.
Sometimes C++ developers can be asked some seemingly stupid questions like "how will minus one be represented in binary or hexadecimal?" or "how many will be 2 in the 8th degree?", "why exactly?", "what about direct and additional codes?". This will allow you to see how much a person is oriented in Bit Magic, which is relevant for C++ today.
Also at this stage, when we already are having a productive conversation, diagnostic questions can work well. They show how immersed a person is in the topic.
For example, a junior C# candidate can be asked about memory leaks. There is a garbage collector that automatically clears the memory, and it seems that there can be no memory leak. But there are actually many cases in which this can happen. If a person gives several options, it indicates a number of things at once. First, the person knows what a memory leak is. Second, he/she knows how to get it. Third, he/she knows how to deal with it.
I use the same principle when asking an experienced specialist, only deeper on each parameter. Regarding Python-Django, you can ask how a person works with the Object Relations Model. After a few questions, you can see if a person knows in which case a mega-request to the database is generated, and in which everything will work quickly with data caching.
My colleague is practicing another approach. After a few standard questions, he asks something that the person most likely does not know the answer to. But the answer itself is secondary. It is important how the specialist will think and move towards a decision, what knowledge he/she will start recalling, and what experience will relate to. Or whether the person will try to find an answer at all. For example, how does a Python programmer navigate a memory management task that is more specific to C++?
Technologies and languages are changing, but the way to solve problems is a universal thing. And if you take the percentage, the knowledge of technical details is a maximum of 40% of the candidate's assessment. 60% is a way of thinking and solving problems.
The way a person behaves during an interview creates an understanding of who is in front of me: an experienced person or just some random candidate. Some think and respond. Others try to change the topic of conversation or “fight back”: "I don't know, I never thought of it, who uses it now anyway?". This is a bad reaction for me.
If a person can explain or at least understand where to dig, that's good. Even if he/she says that it needs to be googled or found on Stack Overflow, it's already an activity. I have a friend who was giving a similar answer in interviews when forgetting the details about the bubbles or trees. And his employer was satisfied. The man managed to work in Lukas Arts, and now he is in a senior position at Microsoft.
You might ask: “Is there a limit of how deep to dive into the nuances?”
It depends on the specifics of the product and future tasks of the person. During the gameplay interview, I was asked about virtual functions, orthonormal basis, vector, and scalar multiplication. If you are looking for a person to make shapes, it is not necessary to bombard him/her with questions about bits and some memory specifics. It is worth asking about arrays and tables, to understand how much the expert can make something and count.
What Subjective And Superfluous Details To Avoid
There are a few unwritten "NOs" that I use when talking to a candidate.
1. I never impose additional stress. Interviewing is an already hectic procedure for everyone. I do not sit there like an inquisitor, hitting questions into the candidate like nails. It is important to make it a conversation between the two specialists. Nervousness makes it worth it for both parties.
It often looks like this. The recruiter gives an introductory speech and asks the candidate to tell about professional or personal experience. While the person speaks and gets used to us and space, I look for where to cling to the subject necessary for me to accurately enter into dialogue.
Did you make games? And how did you work with the characters? How were the models used? Does that mean you had a common model to make people, horses, cats from?
Did you use the list? Why? If you took a tree instead of a list, what would it be?
Were you making queries from the database? How was the base organized? What processing time criteria did you have?
In this way, during a usual conversation, it is easier to find out a lot about the candidate's practical experience and the depth of his knowledge. This is the best option, though it might be difficult to implement.
Sometimes, the person is stressed trying to answer your question. If it's nerves, then after a couple of my tips, the person gets back on track and gives the answer. If the tips do not help, most likely, the candidate does not know the answer.
2. I never ask to write the code on a piece of paper. The interview is already perceived as an exam by so many, but that's not the perception I want from our candidates.
When discussing, say, the OOP principles, I can ask: “Imagine that we have a geometric figure — a square or a triangle. What will polymorphism, imitation, encapsulation look like? ” I try to disassemble everything orally, literally with my fingers. Unless it’s easier for a person to draw the answer. It is important for me not to find mistakes in the form of a forgotten parenthesis or an extra comma, but to understand the depth of knowledge. Let the machine deal with the syntax.
If it is important for the position to look at how the person is writing, I can ask him/her to take a small test after the interview whenever the candidate is ready and then give him/her the task.
3. I do not dive into the knowledge of a very specific technology. I don't care if the candidate used any particular PHP update. Especially if the basic questions are still unanswered.
It is said that there are three levels of cognition: I do not know how to use; I know how to use; I can not use. We are interested in the second category, as well as how quickly and independently a person learns something new.
If you think I write a lot about basic knowledge, you’re not mistaken :) It might seem subjective, but it does help.
I experimented several times: I took people who had some superficial knowledge but no basic knowledge. Eventually, the team only suffered from this. I had to explain something deeper to those performers, refine his/her work, or even redo it.
My experience is that without basic knowledge, a person will not be able to solve even a slightly difficult task, he/she simply will not know where to look for it.
This knowledge, in particular, helps to conduct interviews in various specializations. For example, at the start of SENET, we were looking for a Python Django backend programmer and an Angular frontend. I have no experience in either of them. But checking the basic knowledge, I can conclude that a person understands the basics that can be applied to absolutely everything, so this person can deal with anything.
4. I do not pay attention to personality characteristics as long as they do not harm the team. In the interview, we in particular agree on values, analyze a person's soft skills, and think of whether he/she will fit into the team.
But never judge people by who they are. I had an introvert on my team. He was coming to work and going home, almost not interacting with anyone. He did not like corporate parties and did not discuss his personal life with anyone. Only occasionally could I talk to him for a few minutes. It was ok for him so was it for others, everybody’s happy.
However, this does not apply to the interview.
Even the deepest introverts or the smartest people are interested in answering questions. If they answer me through their teeth or say "everyone already knows how this thing works, why do you ask?", Maybe at this moment the person tries to get the conversation off the topic. I try to get as much as possible to the specifics: “And yet, how does it work, why, what is it used for?”
For me, that’s a marker — "As at the interview as at work."
A person may not know everything, but there is a dialogue, I see reliance on previous experience and a desire to understand. Most likely, the work will be comfortable.
And it happens that you start negotiating with yourself. It seems like everything is fine, but ... something is wrong. In this case, I try to trust myself. Experience shows that superficial knowledge and low-quality work will become a usual thing.
I am sometimes asked by my colleagues: "What to do with those who managed to impress at the interview but turned out to be a low-quality performer?"
There were none in my practice. The interview is a great litmus test. Of course, instead of knowledge, you can memorize the answers to insidious questions and train your chatting mega skill. But I did not come across such tricks. And if they suddenly slip into our office, maybe it's not so bad? After all, they know how to do something, they just need to put it in the right direction.
What To Do If The Candidate Doesn’t Fit
I often say that I was lucky because I hired many specialists after the first interview. But it happens that the position cannot be closed either after the second or after the sixth interview. In this case, I look at the current situation.
For example, a candidate does not fit for a current position but perfectly fits for a junior specialist position. Five years ago, it could have been shortlisted and searched further. Now there is a lack of people everywhere. If we know that we will still look further and recruit a team, why not take a talented specialist who will grow to the needed level in a while? But this issue needs to be agreed upon with those responsible for the company's finances and growth.
It is clear that in this case, when evaluating the candidate, the priority is his/her craving for knowledge and interest in the product. Then we will motivate and help. If a person is looking for a temporary "spare airfield", it makes no sense to hire, this specialist can not be relied on at work.
When I turn down the candidate, I try to go through the competencies and highlight the "blind spots" from the interview, to make it clear what knowledge in which area is lacking. For example, you need to refresh your understanding of working with memory or bit logic. My responsibility here is to provide useful feedback that will help the specialist.
In essence, this is my background in finding experienced people :) It is definitely not the ultimate truth, rather an opportunity to discuss approaches. And I wish candidates to focus on the basics, it will help you to bring a lot of disparate knowledge together and build a proper competence that helps you become a desirable candidate.
Original article on
