How to Avoid Hiring Bad Programmers

There is an old proverb that says one bad apple can spoil the bunch. This may not be true for all situations, but when it comes to hiring people in your company... it most probably is.

Undoubtedly, you'd want to hire the best people to work on your software development projects. After all, the projects' success greatly depends on the people behind them. And yes, hiring talented, experienced professionals may cost you a lot.

But then, hiring amateurs may very well cost you more down the road—e.g., re-work, code refactoring, expensive training, etc. You see, expertise doesn't come instantly. It needs an investment of time and money. And if you hire people who have not invested in themselves yet, then you'll end up with the responsibility to do so.

So, how do you ensure that you’re getting the right people, especially in the tech industry? Paul Graham, the founder of venture capital firm Y Combinator, believes that if the company’s founder is not a programmer, hiring bad programmers could easily be the top way to kill the startup.

This is easily understandable. After all, how can you gauge a candidate’s expertise if you are not an expert on the subject? So yes, a tech startup founder without a programming background would have much difficulty in determining the good programmers from the bad ones.

In more mature companies with good programmers already on board, hiring one bad programmer can still derail a project’s timeline—leading to additional costs if not managed properly. So how do you dodge this trap? Well, here are a few tips on how to avoid hiring bad programmers that may help.

1. Know your developer needs.

First step to staffing up is to determine what you actually need in terms of skills, availability, shift, time constraints, team dynamics, seniority level, etc. To do that, you should ask yourself these questions.

a. Do you really need a senior developer for your project?

Over the years, I've come across a lot of companies that are looking only for senior developers or rock stars to work on their projects. Some believe that getting a mid-level developer is not going to cut it and that a team should only be composed of senior developers.

But what makes a senior developer? Well, Arcanys Senior Architect Eric Jeker has written an interesting piece on this very topic, which can help you understand the seniority levels in software development.

Now that's out of the way, let's go back to the question, shall we? Is it really necessary to hire only senior developers? Well, needing a senior developer is a commonly held belief. But in my experience (and I have noticed that it's more often the case), that a curious (eager to learn), hardworking, and motivated mid-level developer actually yields better results in the long run.

The fact is, most senior developers who've been working in a company for a long time sometimes have more difficulty adapting to new environments, new cultures, or new ways of doing things than junior or mid-level developers, who usually show more interest in learning and growing.

However, this highly depends on the culture of the company the developer comes from. For instance, we make sure that regardless of their seniority, our developers keep on learning new technologies, acquire new skills, and are continuously challenged by the projects or tasks they handle.

b. Other questions to consider

• Is the developer needed immediately or later?
• Is the developer going to be assigned to a specific project, or will he be supporting several projects in the longer term? If assigned to one particular project, what's expected of him after its completion?
• What particular set of skills does the project absolutely require? What other skills/tech would be nice for the developer to have? What specific conditions would the project have (shift, etc.)? Are you sure your expectations are realistic?
• Who on your existing team needs to be involved in assessing the new developer (e.g., interview, qualifying exam, etc.)?
• Etc.

2. Leverage the network of your current employees.

Besides the usual suspects (job boards, job fairs, LinkedIn, etc.), high-potential candidates can be found in two other avenues: in the platforms that the dev community frequent such as StackOverflow, or in your current employees' vast network of IT colleagues.

For the latter, you can ask your developers to recommend people they know and trust. Over the years, we've measured that hiring employees through existing team members has an incredibly high success rate, much more so than other sources. And as the company grows, this network likewise grows, and hiring can become easier and faster.

Offering your employees referral incentives is a good start, but only if you also provide them with the tools they need to promote your company’s open positions. For instance, hold a training session, and provide content to help them endorse your brand. This may include your company’s mission, a list of qualifications that makes a stand-out candidate, the steps required to refer a candidate, and even a cash compensation, to encourage constant networking. Just make sure employees leave the training knowing how to communicate to their spheres of influence, and how they can be rewarded for their referral activity.

3. Review resumes but don’t give them too much weight.

Once you’ve got your hands on those highly sought-after resumes, carefully review each one in comparison to the requirements you have, not just against the job ad they’ve applied for. Even if they came through an ad, make sure to check each resume against all the needs in the company.

It’s also important to understand what the details in the resume mean and if the experience described makes sense and represents the applicant’s real skills.

In some cases, the mention of some technologies is so broad because their application is so varied that it’s crucial to understand what the developer has actually mastered. Take JavaScript, for instance. Many developers know JQuery, but not all understand the language itself and yet they will not hesitate to put JavaScript as their main technology.

The resume can also give you an idea how long a developer has been working on a technology. It can shed some light on the fact that a developer has been stuck working on an old technology for many years, which shows that they may not really be interested in adapting to the latest trends and learning new skills. The curiosity and willingness to learn new skills is of paramount importance when it comes to assessing developers, as the industry is constantly moving, and quite fast, too.

Not all resumes mirror a developer’s skills and personality, though. And while it can surely give some valuable insight into a developer’s capabilities, it shouldn’t weigh too heavily on the assessment of the developer. Some people look amazing on paper but fail their interviews or exams. Others aren’t exactly experts in resume writing. Chances are that you’ll see some with poor presentation, inaccuracies, exaggerations, or even missing elements (and sometimes, blatant lies). Should it necessarily be scrapped, then? Not quite so. In my experience, unless the resume shows that there is a huge mismatch between what you’re looking for and what the candidate has to offer, I encourage you to actually have a talk with them.

4. Never skip face-to-to face interviews.

Another goal you should have is to quickly find out whether or not the candidate and your company are mutual fits for each other. And there’s no better way to assess this than by having a face-to-face conversation. It’s like dating—how sure are you that you will actually click as much in real life as you did through chat or email? Besides, face-to-face conversations allow you to:

• Dive deep into their experience and fill in the gaps that their resume may be inadequately providing so far. This way, you'll be able to prepare for the coming technical interview as well.
• Assess the candidate's attitude and fit with the company's culture. How and what they answer can be a strong predictor of the person's probable tenure in the company besides their skills.
• Grasp the candidate’s ability to explain himself clearly and eloquently. Communication skills are definitely key when working in a team, even more so in a remote team setup with colleagues from different countries and cultures. Being able to explain a topic clearly is also an indicator of the level of understanding the candidate has.
• Find out if the developer has a good idea of what their job is about. If the developer has been a freelance worker for many years, it may be challenging for them to join an actual company or office job in which they’re required to work in teams and a more organized setup.
• Gauge candidate's level of interest for the company he's applying to. Did the candidate do some research about the company? Does the candidate have questions about his/her potential new employer?

In some cases, however, and even more so since the Covid-19 pandemic, online interviews with recruiters can work just as well, too.

5. Perform background checks.

A bit of verification wouldn't hurt. But how to do this exactly? Well, here are some tips to verify data on resumes. Now, while these are not of absolutely crucial importance, it may be worth checking a few of the following:

a. Certifications

Request for proof of certifications in the programming languages and tools they indicated in the resume. Verify if the institution that awarded the certifications is a bona fide, registered school.

b. Past projects and character references

Compare the tools and languages they indicated with their past, finished projects. Go further and contact the references they indicated in the past projects to confirm their participation, skill level, knowledge, and even work attitude.

Important Note: Be wary. Exert some caution when assessing resumes that are too vague. Often, when candidates are unable to provide complete details of their past employment, it’s because they are hiding something that could jeopardize their chances with a new company. And often, the secret is a behavioral problem your company may very well do without.

6. Test candidates’ skills with real-life programming conditions

Nothing shows the technical skillset of a candidate better than an on-the-spot test to challenge their logic and assess their technical ability in real-life situations. But before you get on that, you might want to check out the following pointers.

a. When designing the exam

Don’t only give your candidates an MCQ or a simple programming test to perform (and avoid giving school-like programming tests that don’t reflect real-life programming conditions.) Instead, craft an exam that will require them to explain a concept, a technology, or a problem.

b. When reviewing the exam

As you look over the candidate’s answers…

• Be careful not to rely on the result too much, but more on the thought process.
• Interpret the test results as trends of capacity, not the candidate’s actual capability.
• Allow the candidate to explain why he failed at something and listen to the reasoning behind the thinking.

With experience, you will realize that it’s impossible to automate the testing process and human interaction is of utmost importance in understanding every candidate. One-on-one technical conversations with each candidate who has scored over 50% to 60% on tests and shows potential are probably going to yield very good results in the long term.

In each case, Senior Architects or the CTO should have a second review of the resume. Additional information gathered through this and during the interview with the recruiters, as well as the test results, can guide the technical interview, which will be conducted by the team that will be working with the candidate if he/she is hired.

c. Hands-on approach to building technical exams

This is a small excerpt of the content of our technical exam:

• The applicant has to choose the technology he wants to be tested for.
• First, we start with a few logic questions, like in an IQ test. They are really a small part of the exam, however, and are not related to the chosen technology.
• Then we have a batch of MCQ on the chosen technology and their related technologies (e.g., If your tech is Angular, you’ll be tested in Javascript as well.)
• After that, we have a few essay questions where the applicant has to write down explanations on a specific situation. This is one of the most important parts for us as it will show the applicant’s capability to explain and solve a problem.
• Lastly, we have a programming task. The applicant is asked to follow instructions and implement changes in a small application. The changes are tested via automated tests, and then the code is manually reviewed.

7. Involve your existing team members in the hiring process.

Technical interviewers should ideally be senior and mid-level developers working on projects that may probably end up working with the candidate being interviewed. This is because it’s so important to make sure that the current team is going to work well with the potential new developer. So, initiate a discussion between them early on.

Based on the previously gathered data, interviews, and tests, the interaction between the current team and the candidate should clear any last questions for you. And I mean questions such as whether his personality fits with the company culture or if he can actually add value to the project with his current knowledge and skills. I believe that the current employees are the best representatives of the company culture and have the best position to determine if the candidate is a match.

This exchange should also allow the candidate to get a sense of how well he would feel within the company and the team he’ll end up working with. In addition to that, the candidate will also gain a full understanding of what will be expected of him as well as the type of project he may get involved in.

8. Let candidates engage with the CEO or founder.

Since great people are usually the core of any company and the most crucial strength to delight clients and raise the level internally, it seems a no-brainer to put as much effort as possible to find the right fit. So every candidate getting the thumbs up from the teams who have interviewed them should have a final interview with the co-founder/CEO or senior executive before signing the employment contract.

This can really go a long way. How? It shows the candidate how much he is valued coming to work with his new company, becoming part of the family, as well as how important it is for the founders to know personally who may be joining the company.

9. Deliver value to every candidate. Even if they don’t make the cut, they’ll pass the word around.

Most companies do their best to have a great working environment, cool perks, and worthwhile compensation. But delivering value to developers who make it to an interview even if they don’t pass the standards is a sign that a company truly cares about people. So be transparent and communicate on why they didn’t make the cut, and offer them valuable insights into their work, profile, or attitude as a developer. Share the test results with them, along with some professional advice from your architects on areas for improvement. Assuming they like what you share with them, they could be reapplying and trying their luck again after a few months.

10. Believe in second chances.

Whether it's because of nerves or they were simply unprepared, it is entirely possible for talented candidates to miss the mark. But that doesn't necessarily mean they wouldn't make great additions to your team if given the chance.

a. What happens if the candidate doesn't pass the test or interviews?

For the candidates that did not pass the resume screening, tests, or interviews, it is a good call to give them as much feedback as possible, especially about the areas where they can improve the most technically.

Also, why not encourage them to submit their candidacy a few months later? If they feel like they have improved in the areas we have spotted during the hiring process, or if they have gained new skills that match other open positions, then, by all means, they should reapply.

b. Keep your door open to those who leave

People may decide to leave their job for a number of reasons. But when former talents come knocking at your door again, you should consider welcoming them back. When a relationship has worked great in the past, there’s no reason it can’t have a worthy sequel. Case in point, we have welcomed back old teammates before and that sure turned out quite well for all parties involved.

What next?

Don’t stop your efforts once candidates have signed on the dotted line. Working on retaining talents is as vital as hunting and recruiting them. This is why we've always worked hard on attracting and retaining our talents. And if you're wondering how we do the whole recruitment process, here's a video to give you some glimpse.

Hiring top-of-class programmers is difficult. But remember, your people are your most essential resource. This is why evaluating your options and taking the time you need to analyze applications are important, even if you’re just trying to fill a single position or building a whole new team.