IT hiring process

An IT project's life is complex and split into many crucial steps. One of them is to hire your IT team, may it be one developer or a dozen of people with different roles and expertise. Though roles would require a different hiring process, you can gather a few roles into a group sharing the same method.
This article will help you to understand how to hire the best developers with titles such as Software Engineer, Tech Lead, Front-end, Back-end, Full-stack, Solution Architect, … We won't go through all steps of the process, only the IT-specific ones where I've experienced as interviewer or candidate.

Job offer

The first step to start your search is to publish a job offer online or to contact potential candidates. I won't explain how to write one since you may find a lot of templates online to create your job opportunity. I will point out the common mistakes which make your offer uninteresting or unclear for the top developers you're looking for.

Tech stack

Server-side programming experience in Ruby, PHP, Python, Go, Java, C#, etc.

That's the most common nowadays, you list every language you know but there is nothing alike and make the developer wonder:
"Do they even know what's their tech stack?"
If you prefer an actual comparison, imagine you're looking for an English speaker but your job offer accepts French, Spanish, Italian, Portuguese,... After all, they're all coming from Latin so it should be fine for them to adapt to English in a few days.
Be clear and precise on what the role will be and the technologies used.

Salary range

A vast majority of job offers are not displaying a salary range. For me, and many of the IT people I know, it's a big stop and we'll not apply for the position.
Imagine going to a shop with no prices displayed and the employees tell you to guess the price but will refuse to sell if it's not matching their expectations. That's just a waste of time for everybody.
It's the same when it goes to apply for a job, you cannot expect someone to go through many interviews to discover the benefits at the very end of the process with the risk it will not match their needs.

Technical Tests

Let's get into the most interesting and essential part of this process. Technical tests are a must when you hire someone, it ensures you the reliability, quality, and seriousness of the person you're considering. Most of the time, it will be an algorithm time-limited test to understand the logic of the applicant and that's it. I find it inaccurate since not everybody will develop at the same speed and you may miss a good developer just because he's a slow starter when it comes to unknown subjects. For me, the best schema to follow would be:

• Logical test
• Real life situation
• PR Review

Logical test

It will be the first test for the applicant. The main purpose of it is to understand how he/she'll approach a generic problem. You may do it as an algorithm test, a quiz or a debug session. I would recommend setting a time of 60 to 120 minutes for this exercise.

For an algorithm test, you may ask to implement a sort algorithm or an IT concept such as a recursive function, …
For a quiz, you may use online tools or use LinkedIn assessments where you use the same questions but ask for justification upon answers.
For a debug session, you create a piece of code with different issues or non-standard (for the language used) implementations and you ask to fix all the ones he/she can spot.

Don't hesitate to use online tools to help you with this process. Here are some I already used: Tests4Geeks, HackerRank, CoderPad or Codility.

Real-life situation

Time to get to the real deal. You cannot test a developer merely on his/her logical mind, you need to know how he/she will react to a real situation based on the project you want to build. I would recommend a time limit of 3 to 7 days based on your expectations and emergency for the position.

It may be to implement a Restful API with a DB setup, documentation, and automatic test.
It can be to set up a complex DB with backups and monitoring.
You can also ask for an automatic vertical and/or horizontal scaling project.
...
The possibilities here are pretty much endless, just make sure your subject is close enough to what you expect from your developer on a daily/weekly basis.

Few interesting subjects to include in this test:

• Deploy their project online through their favourite provider: CleverCloud, AWS, Azure, GCP or even their own server
• A document to explain their choices about the tech stack, framework, ...
• A document to explain what could be the improvement of the project, the next steps, ...

Your purpose here is to understand how the developer will interact and contribute to your project, what he/she can bring to the table basically.

The best tool to achieve this and to be able to control the code is GitHub secret gist. Since the repository won't be public but still accessible from the link the applicant will provide you. You can also control how he splits his/her work, the GitHub comments, ...

PR Review

Last but not least, a PR (Pull Request) Review test. I've barely seen this during my career but it seems, for me, one of the most interesting and efficient ways to see if a developer is able to work as a team and not only as an individual. If you think about it, the first test is about the developer's logical/problem-solving mind, the second about his/her technical skills, and this one about teamwork (thoughtful, right?).

The purpose of a PR is to let one or more developers (senior or just part of the same team) control the code quality, linting, comments, potential issues, language best practices, optimizations, ... But, by no means, it's to force one developer's logic upon the whole project. Everybody has a way to think and to build their code and if this way respects the points listed above, there is absolutely no reason to actually update the code later on. However, I met developers (even today) who will modify the code after a merge because it's not how they would have done it and you'll discover it a few days/weeks later. It will tense the relationship in your team and it will be very complicated for you to spot where it comes from since most of the people will stay quiet about this issue.

You have a few ways to achieve it.
You can send a few files and ask the applicant to review them by putting comments in the code.
You can send a few files and ask the applicant to directly update the code and justify his/her choices with a comment.
In any case, keep your code simple with a few tricks. For example, use a loop instead of a recursive function and see if the applicant directly modify it or raise a question to know the reason behind this choice (the latter is the good answer ;))

It may seem like overkill to some, but do not forget your project depends on your team's skills but also on their cohesion, and having a top developer who cannot work as a team may lead to a failure.

Questions

To finish this article, I will share a couple of questions I find interesting or inefficient during an interview, just to break the old habits.

Inefficient:

• What's your greatest strength?
• What's your main weakness?

Interesting:

• What were the most challenging projects or situations you've faced?
• What's, for you, your biggest achievement or the project you're the most proud about?

What do you expect from the inefficient questions? I mean, do you expect the candidate to say he/she's lazy or has a tendency to procrastinate? We all know candidates will check this kind of question online and come with a fake answer just to look good.

On the other hand, the interesting one will help you to understand what's the applicant think is rewarding or challenging and thus grasp a bit of his/her mindset.

Conclusion

There would be so much more to say but I think that's a good introduction to at least improve your process or have a better understanding of each step and its purposes.

If you have a problem and no one else can help. Maybe you can hire the Kalvad-Team.