How to Hook Software Developers Right from the Start: Mistakes to Avoid

This Article is Part of the Guide: How to Hire a Software Developer: The Ultimate Guide guide-cat-arrow

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, bringing it into action 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. 

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 navigating technical skills proves challenging, consulting with experts can provide invaluable assistance. With years of experience in tech recruitment, expert guidance ensures hiring candidates with precise technical competencies to drive projects forward.

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 the required soft skills of developers 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? This can shorten or lengthen the search range. Here’s a brief overview to shed light on each:

  • Traditional on-site model: In this model, developers work within the physical premises of the hiring company. It offers real-time interaction, immediate feedback, and easier integration into the company’s culture. However, it may limit access to a global talent pool and increase operational costs associated with office space and infrastructure.
  • Talent tech recruiting model: Rather than directly hiring developers, companies engage talent tech recruiters to identify, assess, and onboard skilled professionals. Talent tech recruiting services leverage extensive networks, industry expertise, and advanced screening techniques to match companies with the right candidates. This model offers scalability, agility, and access to specialized talent pools, helping businesses swiftly meet their staffing needs. However, effective collaboration between recruiters and hiring companies is essential to ensure alignment with organizational objectives and culture fit. Clear communication, transparency, and a shared understanding of hiring requirements are vital for the success of this collaboration model.
  • Remote work or IT staff augmentation: With advancements in technology, remote work has become increasingly popular. This model allows businesses to tap into a diverse talent pool regardless of geographical constraints. Remote teams offer flexibility, reduced overhead costs, and potentially higher employee satisfaction. However, effective communication and collaboration become paramount, requiring robust tools and processes.
  • Offshore outsourcing: Often chosen for cost-effectiveness, offshore outsourcing involves contracting development work to teams located in different countries. It offers access to specialized skills at competitive rates and allows businesses to focus on core activities. However, time zone differences, cultural barriers, and communication challenges can hinder collaboration and project success.
  • Nearshore outsourcing: Similar to offshore outsourcing but with teams located in neighboring or nearby countries, nearshore outsourcing minimizes time zone differences and cultural barriers. It offers cost savings compared to on-site development while facilitating easier collaboration and communication.

Each collaboration model comes with its own set of advantages and challenges. The key is to assess the unique needs, priorities, and constraints of your business before making a decision. Consider factors such as business requirements, budget, desired level of control, and the importance of proximity to foster effective collaboration.

In-house vs Freelance vs Dedicated Software Developers
Learn the difference between in-house, dedicated, and freelance developers.
In-house vs Freelance vs Dedicated Software Developers

Rule to follow: Don’t build a sandcastle on a high tide.

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, adopted Buddhism, didn’t stay for long at any job, suffers from dyslexia.

If you decide to throw away your CV and not 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 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, the senior vice president of 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 companies are still asking mind-teasing questions. Such questions bring no value to an interview. 

An interview is a respectful dialogue 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 an understanding of each other: what your goals and objectives are, what competencies and wishes of a candidate are.

Instead of brainteasers asking 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:

  1. See how a developer interacts with projects in real-life situations.
  2. Get an understanding of what a candidate considers challenging in projects. 
  3. Understand what hard and soft skills a developer possesses. 

Rule to follow: By 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 are determined 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: 

  1. 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.
  2. 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 logical 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 they will be invited to another interview tomorrow.

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 only to the local labor market. There is another great option to consider – a dedicated development team.

You can: 

  1. Find a developer with the required qualifications. 
  2. Quickly scale your development team.
  3. Focus on the project but not on HR processes. 
  4. Save on salary, taxes, and allowances. 
  5. 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.

Hire Dedicated Developers You Need
Hire Developers
Hire Dedicated Developers You Need
Hire Developers

Rule to follow:  Broaden your angle of view – get more talent. 

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. 

  1. Don’t ignore the need to prepare yourself for job interviews. Especially concerning technical aspects, soft skills, and motivation. 
  2. Avoid bias, and give a chance to people with “non-exemplary” CVs but have the right stack.
  3. Don’t ask useless questions. Wonder more about a developer and what he plans to do with his knowledge. 
  4. Don’t stand in opposition to a developer. On the contrary, it helps him win and show himself in the best possible way. 
  5. Don’t believe in beautiful words, believe in direct answers to your questions. Ask peers for assistance. 
  6. 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.
  7. Don’t forget about the quality of made decisions. Find the optimal number of interviews to be arranged daily to avoid false negative decisions. 
  8. 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.