TL;DR: How not to hire software engineers. The ultimate guide.

Photo by KOBU Agency on Unsplash

TL;DR

Hiring poor software engineers is an actual skill, but some companies are on a mission to take it to another level. Their process to find candidates is exceptional, and it’s worth digging into this topic a little bit more to learn from their mistakes. I encourage you to read the whole post, but if you are lazy, here is a short version…

These are the most common mistakes you can make that will help you find the perfect worst candidate.

1. Reject all CVs that don’t look “pretty enough”.
2. Use bots to filter out CVs with/without specific keywords.
3. Only talk to people with science degrees, honours and titles.
4. Find people who code day and night and have no other hobbies.
5. Make sure you have at least five stages of the interview.
6. Remember about having at least four people in each interview stage.
7. Don’t involve the team in the process, only a bunch of managers.
8. Ask dumb smart-sounding and irrelevant questions.
9. Ask the candidate to do homework which will take them at least 5 hours to complete.
10. Do a technical test with poorly written code where you ask them to find bugs and errors like missing “ or ;
11. Please make sure they are Code Ninjas and Programming Gurus, at least.
12. Seek for conflictless and agreeable personality.
13. Only hire people who never made mistakes and are flawless.
14. Don’t let them ask you any questions.
15. Offer lower salary than candidate asked for on the beginning.
16. Hire somebody who is just like you.
17. Be bad at providing feedback. Bonus points if you make it confusing.

There is a big chance you didn’t tick any of the above boxes. If you did however, think twice about how much you need these steps in your hiring process. In 90% of cases, the answer is “not at all”. The remaining 10%, the answer is still “not”, but you are just good at finding excuses.

The most common mistakes explained.

Some of these issues are more significant than others. I will let you judge the importance of each of them and their impact on your interview quality. Now, let’s unpack and explain what exactly I meant.

Reject all CVs that don’t look “pretty enough”.

❌ If people can’t make their CVs look good, they are probably not worth your time. That’s sometimes true, but not everyone is a designer.

✅ I read every CV and reject only ones that don’t fit the role or containt horrible errors. Once I received a CV for a junior front-end developer, and it said that the candidate is looking for a career in logistics. WTF? :)

Use bots to filter out CVs with/without specific keywords.

❌ Why would you bother to look at each CV when AI can do that for you and filter out candidates and give them a score. Simple and easy, less time wasted on reading an endless number of confusing documents.

✅ I always discourage using bots. In the end, we are not looking for robots, we are looking for humans (very smart ones). I saw good CVs being rejected only because they came in a weird flavour of PDF format.

Only talk to people with science degrees, honours and titles.

❌ It would help if you were only looking for people with degrees, higher education etc. They are more intelligent, apparently. You can’t be a software engineer unless you finished Computer Science, right?

✅ I never look at education in CVs. Nobody should care because it means nothing these days. The most talented engineers I worked with had higher education, but it was not related to computers. In the end, I don’t care.

Find people who code day and night and have no interest or hobbies.

❌ You want them to live and breath code. If they’ve got time for anything else, that means they are not focused enough.

✅ In reality, the section about hobbies is the second most exciting part of their CV, just after the professional experience. You want to hire a diverse team with different backgrounds; it brings innovation. One of my front-end guys was a professional magician. Another wrote a book. So much to talk about during the interview.

Make sure you have at least five hiring stages.

❌ Now it’s time for the interview process. It should be lengthy because you want to involve as many people as possible, just in case.

✅ My worst experience? Eight stages. That’s a lot of company’s and my time wasted, and unless it’s a CTO position, you should never do that! Three stages are enough — HR screening initial discussion, technical assessment with the team, personality and team fit interview. Done.

Remember about having at least 4 people on each interview stage.

❌ Each step of your interview should be stressful. The environment you work in is like that, so candidates need to show resilience and the ability to cope with stress.

✅ My worst experience? Eight people on one call that lasted 2 hours. There is no real value in such meeting. I see this as an option only when hiring a software engineering manager and an opportunity for her to to meet the future team. Still, that’s not an interview, just a casual chat and a chance for her to ask more questions.

Don’t involve the team in the process, only managers.

❌ It is important to show other managers how important they are in the process. Ask them all to get involved. Why not?

✅ I only ask for external feedback when hiring for a senior or leadership position. At the same time, I’m making sure it doesn’t add too many stages to the whole process.

Ask dumb and irrelevant questions.

❌ Ask as many smart-sounding dumb questions as you can. If you dig on the Internet, you can find plenty of examples of what they are. Ask where do they see themselves in 5–10 years. Or maybe if they are more a princess or a pirate. Or what is the average airspeed of an unladen swallow?

✅ These type of questions bring zero value. They don’t check if someone is a quick thinker. They do not magically expose what sits in a person’s subconscious. There are better things to talk about during an interview that will allow you to learn something interesting and helpful about the candidate.

Ask the candidate to do a 5-hours long homework.

❌ They probably don’t have a life anyway, and they should be able to spend 5–10 hours on a task.

✅ Not only it’s a long process and usually creates a tremendous drop-off rate during the interview, but it is also ineffective. People can cheat. You won’t learn how they think. The code itself is not helpful. In the end, it’s a wasted opportunity to learn more about the candidate.

Do a technical test with poorly written code.

❌ There is nothing more enjoyable than reading through a code and finding all missing commas, semicolons or mistakes in variable names. Ask them “what this poorly written code will do” and watch their misery.

✅ Many years ago, I had a technical interview that was all about finding mistakes. After the meeting, I politely withdrew my application. That’s how you will learn absolutely nothing about your future employee, so don’t do it.

Make sure they are Code Ninjas and Programming Gurus, at least.

❌ You want a person who thinks he is amazing, and nothing less.

✅ They often come with a big ego and are called “talented jerks”. You don’t want such people in your team. I joined a company once and inherited two guys like that. Both exceptional coders, but their actions were often toxic and affected many people. The cost of keeping a jerk in a team is always too high.

Seek for conflictless and agreeable personalities.

❌ You want a person who will follow your orders, no question asked. You know they will do only what they’ve been asked and not get distracted by new ideas or improvements.

✅ I always prefer diversity, and disagreements are the best way to spark progress and innovation. Even if sometimes I wish things would just go smoothly ;)

Only hire people who never made mistakes and are flawless.

❌ Nobody wants to hire a person who made mistakes in the past.

✅ I want. There is nothing better than learning from our own mistakes. If someone never made a mistake, means they never left their comfort zone.

Don’t let them ask you any questions.

❌ Why do they have to ask anything? Shouldn’t they be just happy to get the job?

✅ We can learn more about the candidate if we listen to his questions. It reveals what they truly care about. Unfortunately, companies don’t give enough time for them. At least it was always the case for me. I ask a lot of questions :)

Offer lower salary than candidate asked for on the beginning.

❌ You know you achieved your goals if you can get the perfect candidate and squeeze out the maximum from negotiations.

✅ If you are looking for talent, don’t do it.

Provide no feedback, or at least make it confusing.

❌ At the end of the interview, provide no feedback, positive or negative. Your candidates don’t need it, and you are sooooo busy, right? The last thing you want is for them actually to learn from your comments and improve.

✅ I’ve seen it so many times. No feedback is popular, and it’s very common when you deal with agencies. What is worst? When companies go with you through a lengthy interview process, giving you only positive feedback, and tell you in the end: “You are an amazing candidate, but we decided not to give you the job”. I’ve even been in a situation when a company decided to hire someone else as they changed their mind what they are looking for :)

Congratulations!

If you are hiring software engineers (and not only), now you know what you should avoid. If you want to hire true talent, avoid all the above points and focus on what really matters.

If you are looking for a job and experience the above problems, you should treat each one of them as a small red flag. 🚩

Good luck!