Published: November 25, 2023 by Anthony V.
When you try to hire developers, the goal is to build confidence. You want to be certain
that your new hires are top talent to stay competitive in your market and to ensure they
will not end up slowing down your entire team.
It is also a race, if you wait indefinitely to find "THE" developer, your enterprise will
get outraced by the competition scaling their team way faster than you.
You could think about these goals as forces that repel each other. If you are too cautious
in your hiring process, your competitors will outspeed you. If you are not cautious enough,
your bad hires will end up slowing everything down
There is a limited number of candidates, so if you have a malfunctioning hiring process or
if your acceptability threshold is too high, you will miss out on excellent developers that
will be hired by your competitors.
The flip side of it is that you're also limited by the size of your recruiting team. You do
not have an infinite amount of time to perfectly assess each candidate, and candidates
themselves will not agree to do 10 interviews with you just for a "possibility" to be hired.
So it seems recruiting developers today is not an easy task:
What would be ideal is to be able to predict how candidates would perform on the job.
We have seen in another blog post why algorithmic coding
tests are bad.
TLDR: Algorithmic based coding tests do not give us relevant insight about developers'
skills, their focus is too narrow, and their solutions can be memorized.
Instead of using abstract algorithmic problems, let's create a real job-related task that
truly reflects the day-to-day job. My personal conviction is that one of the best and most
feasible ways to do it is to ask candidates to create a real
Microservice from scratch.
For brevity purposes, I will not show you here a complete coding test with all the requirements and information, but let's say we have created a coding test that forces candidates to:
Building a good microservice from scratch involves a ton of different skills. Here are some examples of skills that you will be able to assess if you ask your candidates to build a common microservice:
As you can see, building a microservice is really a "complete" experience. There is a lot
going on, and every aspect of it is constantly evolving. There are new software
architectures, more performant databases, new communication protocols, and so on. Developers
need to continuously learn and improve to stay on top of their craft.
Because building a microservice involves so many parts, it gives us a clear and complete
overview of the true potential of developers. This is not an approximation anymore; you can
truly see how candidates would perform on the job. Also, this assessment method allows us to
test skills that would be impossible to test with traditional algorithmic coding tests.
Most of the time with traditional algorithmic coding tests, there is nothing to talk about
in the subsequent interview. The interviewer will just know the candidate's score, and
that's all. There are rare cases where the interviewer will look at candidates' solutions,
but it's a minority. The time spent to complete the coding test is wasted (sometimes more
than 4 hours per test!).
Instead, building a real microservice gives us something tangible to talk about in the
subsequent interview. Because it's so complete and involves so many parts, there is a lot to
discuss. Candidates will be able to explain their choices and alternatives they thought
about, and interviewers will be able to challenge their design decisions and push them to
really understand how they think.
This exchange could be of really high value, as a recruiter you could gain a deep
understanding of candidates' true abilities.
If you adopt this assessment method, you will also see that there are a lot of different
kinds of developers. Some are experts and passionate about databases, some have extended
knowledge in software architecture and how to produce clean code, and some are medium-good
at each part. It would be damaging to not recruit, for example, a developer that lacks
knowledge about some databases if this developer is exceptionally good in other
aspects.
A complete overview of skills is mandatory to make
informed hiring decisions.
So with our new assessment method, what have we gained?
The best way to overcome the "time" problem is to create an automation engine that automatically
deploys and evaluates candidates' solutions in a real environment.
The workflow will be as follows:
Codigrade is a coding
assessment platform focused on real-world coding tests, as we just saw.
All of our coding tests require candidates to create a real microservice from scratch. Their
microservice will be automatically deployed and evaluated in a live production environment, we
take care of the whole evaluation process.
The process is straightforward (See How It Works):