People we hire are our main strength and our weakness at the same time. Those who we entrust with the work that we are not capable to do ourselves can both please us with their results and let us down. By trial and error, we at Factorial Complexity invented our own recruitment criteria which we hope will help you not to fail and entrust efficiently the reliable employees with the most valuable thing that you have - a part of your business.
Fundamentally different approaches exist when it comes to hiring staff. For example, some companies may hire those developers who have the sufficient formal experience in software development (not less than 3 years of commercial experience, for example) or only those whose experience strictly corresponds to the required experience for the stated position (i.e., having experience in working with the specific frameworks results in a “yes”, absence of such experience means “no”) or, as an option, some companies may hire those developers who have a high level of soft skills.
All these approaches have the right to exist. Our position is somewhat different as we pay more attention not to a significant experience or frameworks knowledge, but to the following abilities / characteristics:
Technical skills or the ability of an interviewee to program by himself (is verified by written test and oral Q&A session)
The ability to integrate painlessly into our team which consists of people with a certain mentality and experience, a team that has also undergone a careful selection and the team he/she will have to interact every day with, solving difficult technical problems.
The ability to learn. Is the desire to understand the problem natural, the kind of desire that does not require any external support? Is he ready to work autonomously, regardless that fact that he faces this problem for the first time? Is he ready to ask if something is unclear or ask even the most stupid questions that might seem obvious?
Does he have the ability to communicate directly with the customer and tell what he/she (or the whole team) is currently working on using a simple language that is understandable for a customer with a non-technical mindset? Very often customers want to interact directly with the developers during daily or weekly team meetings to be always aware of the stage their project is on at the exact moment of time.
Who is able to determine whether a candidate meets these criteria or not? And what is the best way to do it? Let's try to figure this out.
About skills and a technical interview. Technical testing can be carried out only by a technical expert. Of course, below we will share with you the information about how we determine the level of technical skills of an interviewee, but a person without a technical background of a sufficient level will not be able to analyze completely the answers if the answers deviate from the pre-determined scheme. Therefore, for any technical expertise we recommend turning to technical specialists, not leaving the whole recruitment process to management or HR. However, the game is worth the candle because, as a consequence, you are much more likely to choose a person who can deal with a wide range of problems, write simple solutions that are easy to support and modify, and, as a result, get an application with a good code. Isn’t it what we all aspire to achieve?
Vitaliy Ivanov
We think that having an actual ability to code is much more important than possessing a knowledge of specific technologies and programming languages. A lot of developers nowafays are trained to build applications by combining third-party components. This works for many cases. However, any non-trivival problem is virtually unsolvable for this kind of developers.
We prefer working with people who are capable of solving problems. As a simple and fast filter we use a classic problem of sorting an array of integers. We give a candidate a piece of paper and a pen. Some people consider it foolish to write the code on a sheet at the interview but it's not. Written solution tells much more about the candidate than a thorough code review of a candidate’s Github repos. It is not required to write the most effective algorithm. Simple bubble sort is acceptable. The candidate must explain the written algorithm and tell about its time complexity. And show at least a bsic understanding of more time-effective solutions.
Surprisingly, only about every 10-th candidate solves the problem at a minimum acceptable level. Those who fail are not just random people - they can have 5+ years of experience in other companies. But we won't hire them.
About a person as a part of a team. The decision on whether a person is able to fit the existing company’s culture should be taken by a person who is close to this culture. In our case, it can be done by the CEO, HR manager or a person who is already involved in the project that has an open position (at least, this person’s opinion is highly valued and can be relied upon in the decision-making process). We, of course, do not check the ability to understand our local jokes, we do not invent special tests, but after a little conversation with every candidate, we can conclude how close a person is to us. Thus, it is much easier to work together with a person who has similar values. It is better to determine the corporate cherished values before the interview as it will allow to evaluate the candidate referring to a pre-determined list of requirements and treat each candidate equally.
About learning process and autonomous work. There are no magical questions and formulas that could help to determine the degree of a person's learning ability or his ability to work autonomously but this can be evaluated by the way a person asks questions or tells about his experience. Moreover, this can be figured out during his probation period which currently takes 2 months in our company.
Without errors, as you know, it is impossible to get any valuable experience and we have encountered that too. When we just started hiring people we committed very typical and, as a result, painful mistakes.
We hired people who did not fit us at all, because we needed someone immediately. The terms were approaching and continued to approach even much faster, so that it was obvious that people who were unsuitable for us either did not hurry to start their work or completely sabotaged their work for some reason. Interestingly, despite the high urgency and our fear to perish (we said to ourselves “let it be someone than no one”) the work that at that time was not completed had no serious consequences for us. It was necessary to dismiss those who couldn’t cope with the work and look for those who would. However, the process of looking for the right person took about the same time and even much more as if we initially have found the perfect employee.
We hadn’t immediately fired people who did not cope with the work or did not fit into the team. We used to be the supporters of a second chance for a long time, but it has always ended badly. We were afraid that it was not a good and widespread practice to fire people, that this would affect our image, but when we have reached some critical point, anyway, we dismissed them as it was impossible to work with them and their actions or inactions exceeded all the allowed limits. Unfortunately, most of the time this was too late, but we don’t practice that mindset anymore.
Our trial period was ’’for a tick’’. And here is the case when the duration matters. Previously, the duration of our probationary period was only 1 month and very often this month ended successfully for the interviewee and there are some simple reasons for that. For such a short period of time the potential employee did not have enough time to communicate closely with all the members of the team and did not manage to work on several projects to take part in solving various types of tasks. Everything he could do was to collect the forces and pass this 1 month. When it came to assessing the probational period, it turned out that everyone was satisfied. None could say anything bad. And after a month or two it turned out that the person had passed because of some kind of luck and, thus, his chances for dismissal began to rise sharply.
As you can see, our staff selection style differs due to its censoriousness. Accordingly to the statistics, among N interviewees for a technical position, only 1 of them succeeds. However, this does not mean that it is necessary to complicate the system of personnel selection and, thus, to complicate one's life. We, after setting the priorities for ourselves, have refused some things as several stages of the interview, psychological testing, etc. And this allows us to devote time precisely to the priorities of our company and the needs of our customer’s business.
If you have any questions considering the topic of this post, please email me tatiana.danshyna@factorialcomplexity.com, In addition, we are ready to find employees for your startup or project and do a lot more.
