The scenario while hiring a software developer in most cases is almost the same: search, filtration, an invitation to an interview, and choosing the best of the interviewed candidates. Sounds pretty simple, right? However, when bringing into action it becomes quite a complicated and costly initiative.
In the words of Akito Morita, a co-founder of Sony Corporation “Your business and its future are in the hands of the people you hire”. The success of your company and the project you are working on fully depends on the staff members you employ.
Since we hired developers ourselves, we decided to share some of our experiences, probable mistakes, and ways to avoid them.
1. You are not prepared
You have decided to hire a developer. Now it is important to prepare to create a vacancy and hiring in general. If you think that you need no preparation this is your first mistake.
Developers are in high demand. Professionals can receive up to several job offers daily and don’t stay unemployed for a long while on the labor market.
Hiring a software developer can be compared to hunting. The hunting ground surely depends on who you are chasing. If you don’t think about it other “hunters” will. Guess who is going to get the prey.
Not knowing who exactly you need is one of the factors why you fail to hunt a developer. It leads to permanent doubts that result in excessive deliberation while hiring a developer.
To avoid this create a persona of your best candidate.
Key aspects to think about before you start hiring:
1. Tech skills. What duties do you want a future developer to carry out? Define what technical skills are required in your work. Specify them in your vacancy description. If you struggle to define the core skills for your project you should ask a CTO for assistance. Learn how to hire a CTO in our blog if you don’t have one.
2. Soft skills. What are the must-have soft skills a developer working on your project should possess? Can these skills be developed if a candidate doesn’t possess them at the moment? Our blog covers required developers’ soft skills in greater detail.
3. Domain experience. Consider if a candidate needs experience in some specific domain area. For instance, eCommerce, video streaming services, or fintech. It will help weed out candidates faster.
4. Collaboration model. Which model of collaboration suits you best? Remote or InHouse? Offshore or Nearshore? This can shorten or lengthen the search range.
Rule to follow: There is no fuss – just speed in hiring.
2. You give preference to Elite
Imagine you receive an email with a CV: the candidate was raised in a foster family, finished only one semester at the university, and then dropped out, spent a year living in India and adopted Buddhism, didn’t stay for long at any job, suffers from dyslexia.
If you decide to throw away the CV and not to give a chance for an interview you have a great chance to let another Steve Jobs go.
A CV tells a story. Say you have two CVs in front of you. Both candidates are equally qualified in the tech stack you need for your project.
In the first one, you see that the candidate graduated from Oxford. Ideal CV with good references. It can speak in favor of the huge effort the developer had made to enter and to graduate from an elite university.
In the second case, the developer graduated from an average state university, changed a couple of jobs in different companies, and had his first job as a waiter in a neighboring restaurant to pay for his studies. It can either mean aimlessness and unpredictability or that a person is struggling against circumstances from birth, doesn’t give up, and even succeeds. Such people have a sense of goal. Therefore, such a person at least deserves to be interviewed.
As you learn more about the stories and characters of successful people, you’ll find something they all have in common. Not all, but many of them faced hardships from an early age. If a person goes through poverty, violence in the family, or something similar, it is very unlikely that bugs and production issues can frighten such a person.
Stop and think before you reject a candidate with a “non-perfect” CV. Give this person a chance. Who knows, maybe he is Dr. House in the software development world.
Rule to follow: Labels are for clothes, not for people.
3. You ask useless questions
You might have years of hiring experience or no experience at all. Before an interview, it is worth spending time to understand why you are going to ask questions you want to ask and what value should they have.
You might have heard such questions from software developers from Google and Microsoft, like “How many golf balls can fit in a school bus?”. In 2013 senior vice president for people operations at Google gave an interview to The New York Times where he clearly expressed his opinion about such questions: “We found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations are in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.”
It’s 2021 but still, companies are asking such mind-teasing questions. Such questions bring no value to an interview.
An interview is a respectful dialog when both sides get to know each other better and the ultimate goal is to understand if they can work well together and bring value to each other shortly.
Questions at an interview form understanding about each other: what your goals and objectives are, what competencies and wishes of a candidate are.
Instead of brainteasers ask questions about a candidate. Let a person provide more personal information. Listen. Lead a conversation in a way where a candidate tells about their wishes and areas to be engaged in, previous projects and preferable projects for the future, difficulties faced, etc. By doing so, you’ll:
- See how a developer interacts with projects in real-life situations.
- Get an understanding of what a candidate considers challenging in projects.
- Understand what hard and soft skills a developer possesses.
Rule to follow: Asking hypothetical questions you’ll get hypothetical answers.
4. You are struggling
Sometimes confrontation between a developer and a hiring party can occur. Reasons can vary, starting from a wish to create a stressful situation and ending up with the willingness of an employer to raise self-esteem.
Interviews are not Mortal Combat fights. The goal is not to make a cool fatality and defeat the opponent. You want to hire an experienced developer and a candidate who aims to work for your company. You are on the same side. Help him win, and this is how you win yourself. Win-Win.
Many developers are introverts by nature having issues with self-presentation skills. There are two ways out. First – create a stressful situation when you further oppress a person. Second – make a friendly environment, draw a developer into the conversation, and let him present himself in the best possible manner.
Candidate’s success by default means the success of your project. Help the candidate demonstrate the best sides during the interview and then conclude if he suits you. Don’t pressure the candidate. Joke and try to create trusting relationships.
Rule to follow: Turn up the developer’s self-esteem, not your nose.
5. You are trying to do everything alone
The first part of an interview is a theoretical test. The issue with technical questions is that a developer might answer a question but change the theme and avoid specifics, thus saying a lot but not much sticking to the point.
If you lose track, the wrong person can be hired and a less talkative candidate can be overlooked. For instance, when you ask about the difference between an attribute and a property in Java Script you should hear a concise answer: attributes are determined in HTML, and properties in DOM.
If a developer provides concise answers and examples of cases from his previous experience – this is a professional. Hire this person. If on the contrary, a candidate changes subjects, waffles on, and is good with sweet-talking – this person is bad at development. Subjects are changed just because a clear answer to the question can’t be provided.
You can avoid this mistake in two ways:
- Your experience. You’ll spot insignificant talking as the interviewing experience grows. If you don’t hear a clear answer, repeat a question once again or reword it. No straight answer means a lack of knowledge of the subject.
- Ask one more person to join an interview to follow up on the answering process in terms of correspondence to a subject of asked questions. It can be a team member, manager, recruitment consultant, or any other concerned party.
Rule to follow: Four eyes see more than two.
6. Wrong coding task approach
The coding task is the second part of an interview. You give a technical or logic task to a developer. The goal is to vividly see how a developer is writing code and contemplates the issue. Unlike theoretical questions, the practical task doesn’t provide room for long, wordy, and vapid talking. However, other mistakes can be left unattended:
You didn’t think about the level of complexity. It is worth noting that coding task is not appropriate for juniors. Candidates who can explain the solution are middle or senior developers in most cases. As an employer, you should prepare a technical task conforming to the seniority level of a candidate.
You take too much of the developer’s time. You give a developer a task or a mini-project (for instance – take-home tests) to be done at home. As a rule, it takes a weekend or the same amount of time to fulfill it. Such tasks are reasonable only if a developer has serious intentions to join your team. Mature developers don’t want to spend so much time on a test task, since tomorrow they will be invited to another interview.
Your coding tasks have nothing in common with real project coding. Many tests taken from such resources as hackerrank, codify, etc., are not related to real projects. There is not much use of these resources if you need to test whether a developer can practically design a class property or structure an object-oriented program.
Task complexity should correspond to the developer’s level. It shouldn’t take too much time, ideally no more than 2-3 hours, and be as close to real project work as possible. This will help you to evaluate practical knowledge in the best possible way.
Rule to follow: Real Coding Task – a real result.
7. Too many interviews on the same day
When you urgently need a developer, there is a temptation to arrange as many interviews as possible within a given time frame. As a result, the hiring process turns into a nightmare with 14 interviews a day. Making quality decisions is out of the question with such an approach.
While interviewing candidates, you have to be sure that your decision will be right. You won’t be able to make such a decision if you have several interviews during the day.
The diagram demonstrates the dependence of the quality of decisions and the number of daily interviews. Say you aim at 8 interviews a day. However, the optimal number is 4 which means you’ll reach the critical point X. After the X point the quality of made decisions drops, and you get into the trap of false-negative decisions. This means that developers 5-8 might be strong candidates, but you will say no to them.
Think about how many interviews you can hold a day to avoid reaching the X point. Spread candidates evenly among weekdays instead of stuffing all the interviews into one day. When creating an interview schedule, consider the position, seniority, and geographic location
Rule to follow: Festina lente – make hustle slowly.
8. You search for developers in your region only
Talented developers are spread globally, not just 2 blocks away from you. Don’t set bounds to the local labor market only. There is another great option to consider – a dedicated development team.
- Find a developer with the required qualifications.
- Quickly scale your development team.
- Focus on the project but not on HR processes.
- Save on salary, taxes, and allowances.
- Avoid being involved in matters of working conditions, social security, etc.
A dedicated team – is a team of developers or a developer provided by another company for the period of your project execution.
You won’t be able to meet a developer in person, but having an online interview is as easy as shelling peas in our digital world.
Don’t be afraid to look outside your region, especially if you work in a region with a shortage of talented developers. The broader the search, the more talents you can find and choose the best match accordingly.
Rule to follow: Broaden your angle of view – get more talents.
Goodbye to all that
We learn how to do things right by making mistakes. Most likely you’ll hire and fire dozens of developers that won’t be efficient. But as your knowledge grows, you’ll be able to find better professionals. We hope that our experience will help you avoid mistakes.
- Don’t ignore the need to prepare yourself for job interviews. Especially concerning technical aspects, soft skills, and motivation.
- Avoid bias, and give a chance to people with “non-exemplary” CVs but have the right stack.
- Don’t ask useless questions. Wonder more about a developer and what he plans to do with his knowledge.
- Don’t stand in opposition to a developer. On the contrary, help him win and show himself in the best possible way.
- Don’t believe in beautiful words, believe in direct answers to your questions. Ask peers for assistance.
- Don’t give coding tasks taking much time to accomplish. Ideally, they should be relevant to real projects and the developer’s level of seniority.
- Don’t forget about the quality of made decisions. Find the optimal number of interviews to be arranged daily to avoid false negative decisions.
- Don’t frame yourself within the local region or a single country. You can hire a developer from worldwide. Just try different models of cooperation, such as a dedicated team for instance.