Why is Tech Hiring So User-Unfriendly?
By: Vincent Vallet
Tags: Tech, Interview, Hiring, Hiring Process, Technical Test

I have to admit before we go any further into this article: I’m tired of how we try to select candidates in tech. All hiring processes look the same, they are too long, sometimes they don’t even provide solid information about the candidate and about their capacity to provide something new to your company.

The idea here is really to share the point of view of a tech guy about what we can optimize and improve in our way of hiring talented people. Otherwise, you are just another company in the long list of spam … huh sorry, in the long list of interesting companies that will never get any answers.

HR and Tech are two highly related worlds that should learn to speak the same language ;)

Promote Git repositories

This is the best way to get to know a programmer and to show them you are interested in their work.

No more basic messages like “after perusing your Linkedin profile”!

A Linkedin profile is just an “entry point” and not a skills list, and even less proof of any skill.

A lot of programmers have, at least, some private repositories that they can share with you. Projects can be split into two categories:

1) Personal projects

Personal projects are a good source of information if you want to judge:

ownership: how candidate manages a repository, how he/she organizes project structure.

deliverability: just look at how commit messages are written, how they are distributed in time, but not commit frequency (number of commits per month for instance), it’s really useless and it largely depends on the professional context, etc.

code quality: Is the code dirty? Or is it well architectured, commented, tested, etc.

Most of the time this kind of project is quick and dirty and they are not “production-ready” of course. But it’s a very good start to gain insight into candidates' technical mindset.

Of course, you should integrate such a step in your process. It’s not just asking for a repository link and inspecting the code. You should ask the candidate for some explanation about this project and why they are showing you this project and not another one.

2) Open-source projects

Here we are, probably one of the best ways to gauge candidates:

technical skills: How they code, how they implement features, their problem-solving approach, technological choices, algorithm implementation, etc.

communication skills: How they interact with other people in their team and external contributors (you can do this simply by reading messages on Pull Request/ Feature request)

work organization: How they distribute the work between them and their teams, do they give deadlines, roadmaps, etc?

candidate leadership: Do they take the lead on some topics? Are they recognized in their team as a referent on some subjects?

Open-source logo

Most Open-source projects are well organized, follow a pattern for commit messages, have a CI/CD, force you to think before you code. If a candidate helps this kind of project it means they work with many different personalities over the world in a challenging agile environment, in other words, this person probably has a very good team spirit.

Technical tests

Official definition => Technical tests are basic exercises that are written in a way to demonstrate candidates' abilities and technical skills.

Reality => bullshit

First of all, a technical test can be entirely replaced by a personal project demonstration, a git repository, or an Open-source project.

A technical test shows you nothing more than what you want to see. If you ask for a little program that should do basic operations. Then you will receive it, most of the time with an explanation that will show you nothing more than the candidate just understands your exercise! What a great result for your hiring process and what a waste of time for the candidate.

Developers don’t like to spend 10 minutes of their time doing a simple HelloWorld …. or worse than that: spend 3 days working on a full project that will never be in production.

The question of the duration/deadline?

If you choose the first approach (to let the candidate give you some personal projects) you will completely remove this question and speed-up your entire process.

If you choose to give homework, then no deadline is probably the best option. I never saw a better result in a test because you allowed more or less time to do it. Here we should take into account the candidate experience about your hiring process. If you let them the time to give the test then they will have a better perception of your company. The test is the reflection of your own mindset, if you put some pressure on candidates, they will identify your company as a stressful place to work.

Fun fact: I finished a HackerRank test after the deadline, I remembered the last exercise so I did it blindly without having access to the platform any longer. I sent my work by email and the company was able to run the result to see if it passed the tests …. and it was good, and I joined Voodoo. The most important is the quality of the result, not some arbitrary deadline ;)

The most valuable part of a technical test: open questions!

If you want to extract the best from a candidate then you should ask good questions. Open questions give candidates the opportunity to express their point of view, to explain their approach, their way of thinking, and their way of working. That’s exactly what we want to learn about each person we meet during an interview.

Knowing where a candidate has previously worked is a mere detail, but knowing how he/she goes about solving a problem is fundamental.

Process duration

The question without any (decent) answer. What is the best process duration?

If it’s too short => how we can be sure that the candidate is the one? The candidate will also find it very suspicious.

If it’s too long => the best candidates will accept an offer from another company or they will just give up midway.

The problem is not the duration of the whole process but the number of steps and the duration of each one. When I see big companies which have 7, 8 or 9 steps, each of them for at least 1 hour, with exercises, questions, etc. We’re not in therapy here, we’re just trying to interview someone for a job: let’s calm down!

The only signal you will send is that of a company where everything is complicated, takes time, and is weighed down by immense inertia. This is probably not the best image you can give of your business.

Fun fact: I gave up a hiring process because it took too much time and they just repeated “we only hire talented people” during each interview. Seriously, do you know any company who says they hire weak-minded people? Everyone wants the best, no need to say it.

Experience vs studies

Another classical mistake: ask for X+ years of experience on a specific technology. I think we all know very talented people with only a few months of experience and on the other hand, we all have met someone with many years of experience and who is not able to write a single line of code without bugs or who is not able to structure a project or a simple thought!

Fun fact: During an interview, someone told me they were looking for a developer with 5 years of experience with Node.js, …. this technology was 4 years old at the time.

If years of experience are not important, some companies decide to specify which qualifications you should have. Well, that will just prevent you from meeting all the autodidacts (or people who are changing careers), which are often the most interesting profiles.

And I will finish with the best: to look for someone from a specific university or engineering school. As if someone is automatically good, just because of the school reputation.

Fun fact: I graduated from one of the most prestigious French universities, and one of my friends has the exact same training but from another university (less known). Most of my professors worked with both universities, so we had almost the same university education. But my diploma is more highly valued only because the name of my university is better known. Does that make any sense?

Avoid the Standard Job Interview

We should put an end to “traditional questions” like:

What are your 5 strengths?

What are your 5 weaknesses?

Where do you see yourself in five years?

…

This doesn’t provide valuable information about candidates, and everyone is prepared for these questions. So there is no spontaneity and no real truth in the answers: do you know someone who answered: “I have to be honest, I’m lazy”?

The following questions are more open and you will know the candidate better:

What makes you unique?

What motivates you?

What are you most proud of (in your professional or personal life)

A specific question for tech people that I like so much is: What’s the strangest bug you’ve ever had to debug? (Thanks to Nedim, one of my colleagues, for this one).

Another point, try to provide an innovative technical test. If you ask the candidate to do yet another binary tree exercise it is unlikely to create an amazing experience between you and the person you want to know.

All these exercises can be prepared for, so what is the purpose of asking questions that can be anticipated?

During an interview, you are looking for the truth about a candidate, and the truth doesn’t need to be prepared in advance.

Getting candidates out of a room

How many colleagues did you get to know outside of work? In the context of work, everything is formatted, even interviews. The best way to really know who you are interviewing is to get outside of a cold meeting room.

Bring the person in a more comfortable zone (relaxation area, bar, etc). You will learn much more, in a few minutes, about your future collaborator than in one hour of classical interview.

Voodoo’s office rooftop

To hire someone is not only about technical skills and abilities.

Don’t forget the “human” in Human Resources, even a programmer is a human (or at least we are very good at pretending to be :)).

Personify what you’re asking from candidates

If you ask candidates to be innovative, unique, convincing, precise, …. then be so, yourself!

First approach

The first approach is very important in the final decision of a candidate. Some of us receive dozens of messages per week. If you are really interested in the candidate, maybe it’s time to look at his/her work (personal repo/contributions), hobbies, etc. The most pleasant approach I had was the one where I was contacted following one of my talks to find out more.

Avoid sending a test just after a first phone call, it will clearly demotivate a lot of candidates. And try to put the candidate in contact with his/her future team as soon as possible (avoid HR interview as the first step of your hiring process).

Job offers

Avoid formatted job offers. Nobody wants to read a cold and meaningless description. The job offer is the first impression you will give to the candidate.

And please, avoid the “endless list of required skills” syndrome. In addition to being counterproductive, it will harm diversity and inclusion. As a study shows, women only apply if they satisfy 100% of what’s asked.

Insist on perks rather than the job’s prerequisite skills.

Hiring process

Same for the hiring process, you should be different and avoid certain mistakes (see previous chapters).

Be transparent

One of the most important points: try to not hide the drawbacks of your company. Always be sharp and honest. Candidates prefer to know where they will land and in what kind of mess they got into :)

The best is probably to tell why you need their help and so what are you looking for.

Some good articles about the subject