Software developer is a career famous for having a lot of opportunities in the market, where many companies are looking to fill their multiple positions from arguably a “small” pool of talent.
But, have you ever thought? Is it true the number of good developers is so little? I have seen opinions, where they believe less than 10% are actually good enough, even people who say less than 5%! or perhaps the recruitment process in many companies is not the most efficient neither fair?? From what I have experienced, also from the opinion of some others, the hiring process seems somehow broken. Probably the biggest problem with software recruitment is how companies qualify skills from candidates, I have experience, also heard some interesting stories regarding the way they try to achieve this, from the "nonreal" life algorithm puzzle, to rejections due to the developer not adding eslint to the takeaway home exercise.
Let’s break down some of the different ways companies “makes sure” a developer has the right skills:
The algorithm puzzle Kata
Usually, this test gets sent on an email that contains a link that will redirect you to a coding interview platform like codility, right away, before starting the test, you will see some instructions similar to the following:
A few things before you start:
- This assessment consists of 4 tests. It will take approximately 80 minutes to complete.
- The assessment is timed. A timer is shown per test or per question.
- Please allow the use of your camera/webcam and do not leave full-screen mode. Snapshots will be taken of you periodically during the assessment. These measures are taken to ensure fairness for everyone.
- Your assessment contains one or more coding tests. You may leave full-screen mode while working on the coding test. Full-screen will be re-enabled after you finish the coding test.
- Turn on your speakers or headphones (to play audio).
- You are free to use a calculator, pen and paper.
- We recommend completing the assessment in one go.
From all these things, probably the more interesting one, is when they say “Please allow the use of your camera/webcam and do not leave full-screen mode. Snapshots will be taken off you periodically during the assessment. These measures are taken to ensure fairness for everyone”. This translate as “you can’t cheat”, right? Well, I find this unfair, even somehow rude, we as developers, search for information, “answers”, opinions, etc, all the time, is part of our daily job, some people say, it is even a skill! Also, why would I allow anyone to take snapshots of me because the company can not simply trust its own process?
An important aspect to mention, is once you see the challenge, most of the time, it is a not real-life scenario problem, from a messy piece of data you need to somehow loop in different ways to finally get the expected result, to the ones that require applying complex regular expressions, I can honestly say have almost never written a complex regex without googling, it is just not an every day ( or even a monthly ) task for me to remember, apart from not being fun at all.
Another characteristic to notice from these automated tests is the expected result, there's some unit test checking the output, if you make them pass, a real person will then review the solution at some point, however, if it fails, you can probably get an automatic rejection without even having the opportunity of someone looking at the code, even if the solution is 99% close. Now, how do I know this? I actually did an experiment once, can not exactly remember what was the challenge about, but let’s say after applying the corresponding logic to the algorithm, the expected output was to return a string with “Hello world”, instead I on purpose did “Hello world ” (notice the extra space after the word world), as a result of this, the unit test(s) fail, I still submitted the code this way tough, not long after, a rejection was made, even though it was 99% close to the solution, there is a high probability no one reviewed the code. This is another reason why I do not believe in companies who tries to automate their recruitment process this way, the lack of human involvement is not a very good sign.
In regards to the code interview platforms, usually, they try somehow to offer an experience close to what you get in a text editor but inside the browser, however, is not even close to what you feel when coding with VS Code or even something like code sandbox, this adds a not need it layer of difficulty to the test
The take away coding task
I have done a few of these, they’re somehow fair, the majority do represent a real-life problem, you might be building a mini-app from what you can possibly be doing during the job. The problem sometimes is that you don’t know exactly what they expect, the README file with the instructions might not be the best, some of them mention things like “production code”, but each company have a different idea of the so-called “production code” term or “scalability”, others might expect the opposite, they want you to just focus on a straight solution without overdoing, you sometimes wonder what direction to take, again, this is mainly because the instructions are not well defined, therefore it is recommended to email back asking any question if you don’t feel something is clear enough, otherwise you might be delivery something different from their assumptions.
This test should not take you more than 2 hours
Unfortunately, some of these tasks can come with a time indication that does not seem to represent the reality of what you need to do, I’m not the only one who has seen a weekend test with a 2 hrs expectation. When I was a Jr dev, I use to think, “am I that slow?”, “the good developers can do it in this time frame but not me?”, A lot of the time, it was a wrong estimation from their side, especially when they ask for “best standard”, “production code”, “good file structure”, “testing”, etc, if you want quality code, then enough time is simply need it.
The white board test
Arguably the least favorite one, you spend your career writing code in front of a screen, now's time to go back to school, write on a physical board in front of people you probably don’t know well, an unnecessary intimating process were the candidate is supposed to explain his approach while writing also.
I have not been so unlucky to do many of these, but on one occasion a company made me do a whiteboard test which I could not quite solve, at the end of the test, the interviewers almost walk away from the room without explaining what I was supposed to do, I ask them if they could please tell me what was the “right’ approach for the problem. When they tried to explain it, they were not sure either on how to solve it, meaning they did not quite understand their own test, believe it or not.
Live pair programming test
Like the title points out, the interviewer and candidate work on a problem to solve, it can be quite intimidating, not sure many people like being look at while coding, especially when you don’t know the other person well ( it is hard to show your best potential here ), some interviewers might not be "compassionate" enough, where they just stare at the screen while you are coding without trying to make the atmosphere a bit more relaxing, also, if it is a real pair programming, the interviewer should somehow help the candidate out a bit, or give them a little push forward if they seem nervous, especially knowing the interviewer is familiar with the code, she/he knows the test well, is not a surprise for them. If the interviewer want’s to imagine how this person behaves, acts, and code in a real app scenario, then the candidate should be allowed to google as well, if we do it in our everyday job, why would you not do it in a test?
History
Now, who are the persons behind this process?? Well, the answer is none other than the Sr devs who have previously face a similar recruitment process, they just continue with the trend today.
How did all this started? Hard to know, but looking at the past, they are some clues
The giant company ( maybe a couple of others as well ) were famous for doing the whiteboard test some years ago, not sure what is their process now, but back then a lot of developers “dream” of getting a job in one of these companies, due to this, a book called Cracking the coding interview came out, becoming very popular, all sort of companies from 2 person startups to mediums ones became to copy the Google approach, if they did not do the whiteboard test, at least asked about the famous Big O theory explained deeply in the mentioned book. What these other companies did not do, is ask themself, are we Google? are we that big? do we faced the same type of challenges? I guess you know the answer, if you are not Google or Facebook, why would you qualify people so similar to them?
Fizz buzz
Probably the most famous coding test ever to be made, when you do a search on Fizz buzz, the following definition is found : “The "Fizz-Buzz test" is an interview question designed to help filter out the 99.5% of programming job candidates who can't seem to program their way out of a wet paper bag”, wow, some big words are written here, “99.5% who fails on this test can’t write code”, boy, how did they end up with this conclusion? Where was this experiment made?
From stories I heard and read, a few Sr dev got rejected after falling the test, some people argue saying things like: “how can she/he be a Sr dev, charge that type of money if she/he does not know how to solve a simple exercise like this?”
To explain more or less what happen in some of those rejections, I will like to compare it to a sport call baseball, yes baseball. When a hitter faces a pitcher in a professional level, the player usually has his swing timed to hit a ball which is throw at a velocity between 80 and 105 miles per hour ( very hard ), however, they are some “funny” situations, where after a long game, in some random occasions when a team almost runs out of pitchers, they tend to bring a position player to throw ( a non pitcher ), the new “pitcher” tends to throw the ball at a velocity between 50 and 70 miles per hour, this sometimes puts the hitter to a situation were he’s completely out of balance, he’s mind and body are used to much bigger challenges, but now, they are being surprised, resulting sometimes in a fail at bat for the player. Now, does this means the hitter is not good enough? Or he did not deserve to make the team after even decades of hard work?, absolutely not! As a fact, this type of situations last very little ( one inning or less ), the “pitcher” then is taken out of the game, because if the “slow” arm guy stays throwing longer, the opponent hitters will make the adjustment sooner than later and massacre whatever he pitches.
On the other hand, others candidates did pass the test, but the reason why, was not always because they had better thinking or skills, no! You see, the test got so popular, that many companies were testing candidates this way, to the point that many knew the Fizz buzz quiz could come, so of course they came prepare! I sometimes wonder how many wrong hires happened after doing this, or how many good hires were actually missed.
At the end, the Fizz buzz trend did more harm to the recruitment process than any good.
What is the solution?
I have made some arguments on why I think the recruitment process is not great, but, how can we do it better? I can only offer some thoughts that might make a difference.
What ever type of test you do, it is always best to set a challenge that represent a common task your team does on a daily basis, the word common does not necessary means easy, I believe when we hire someone to help our team, is to “push” the product forward by building features, improving code, communicating, planing, sharing ideas, to finally, solving some very hard problems, but, for some reason, most focus on testing the hard problem part, this problems are usually not the most frequents, when they appear, usually the person search, dig, or ask for help, until the solution is found. If your company have to many hard problems, then, there might be some bad decisions made some where else, by the way, who made those decision? The same person who pass the 4 tricky kata interview?
There is also ways of qualifying someone by just having a technical chat, specially if they already on a senior level. Many topics, fundamentals, approaches, etc, can be discuss by just talking with the person, but, not asking the obscure, edge case, like the famous Kyle Simpson once said “I’ve forgotten more JavaScript than most people ever learn” but off course that does not mean he doesn’t know enough Javascript to find a job in any good company
Take a way test are not so bad, but please remember is a test, something were they can showcase skills, logic, but always small ( 2 or 3 features max ), try assigning something that can be interesting and fun. Remember candidates are doing this in their spare time when they might feel tired, they could also be doing other tests from other companies, appreciate their time and effort
If you are going to do a live pair programming test, try to be as kind and friendly as possible, make the first move if you notice the candidate is somehow a bit unsure on where to start
It might sound obvious, but the test should be something members of your team can solve with confidence, otherwise you might have to review the recruitment process applied in the pass
Conclusion
Personally I do not participate in process that involve algorithm puzzle kata neither white board tests, more than happy to face a well done take away test, a "friendly" pair programming, and off course a technical chat about different interesting and challenging topics
Before getting into a recruitment process, make sure to ask what type of process they fallow, how many stages they do? how do they test technical skills? look at recent interview reviews in Glasssdor, do they even bother to give feedback to the candidates? the more you find out, the better, If they don’t meet with your standard, is better not to get involve, you will be saving a lot of hassle, be patientan, the right opportunity will eventually come. On the other hand, If they do meet with your standards, and you decide to participate, please add your experience in Glassdor, so it can be public for everyone, the more open, transparent this process are, the better community we will be able to build and offer
Top comments (0)