Stop giving homework to programming job candidates
Introduction:
There is only a small number of programmers that have never been asked to deliver extra code at some point in the recruitment process. I constantly hear that it is still a popular method of examining new technical employees. I am here to explain, why as a programmer you should not do the extra task (with a few exceptions, which I will cover later) and why as a recruiter you should avoid giving one.
Why have I taken the liberty of speaking on that topic? I participated in tens of recruitment processes as a candidate and as an interviewer. I’ve also done a dozen of homework tasks (and left even more of them undone). The context of this article is mostly related to front-end development, but there is a high chance that the problem is universal for all technologies. Also to note — this is based on Polish IT market reality.
How it starts:
You probably all know that situation. Your conversation with the HR department goes smoothly, it seems that you understand the company culture, and there is a good vibe. The following stage is usually your English skills check (for not native candidates only), so with a little bit of stutter you assure the recruiter that your hobby is fishing and fast cars, and of course, that you always wanted to become a software engineer. A technical interview comes after that — you are not afraid of this part, after all, you are a few years in the industry. You answer all of the technical questions. At some point, the recruiter stops to chat about some exciting future technologies and what the daily job looks like. Until this particular moment, everything seems to go fine, and most likely you will be offered the job. Then the fairy-tale atmosphere goes away and here comes the question…. “Would you mind doing an extra task that our team prepared? It is a small thing, and by finishing it you will allow us to get to know you better”.
The exciting challenge:
As the recruiter assured, the task is meant to be done in two or three hours- “if you’re a good specialist”. And of course, you are a good programmer, right? You are not sure if to proceed, but somehow you say yes. Soon you receive an email containing a list of things that need to be dealt with. In most of the cases, it is a CRUD, how exciting — who would expect that? Down the road, you find out that it’s some new JS framework like React or Angular, and it requires creating a basic node server — after all a self-respecting frontend developer can write a basic API. Well, instead of giving your eyes a break after daily hard work, you can’t wait to create a GUI for electrical car loading points locations, statistics for vessel cargo at a seaport, or creating a wall with posts, photos, tags, and likes. If you are not lucky enough, you were just asked to build an Instagram or other tinder clone. (these are real-life examples).
…are you kidding me?:
Where to start? If it’s a recruitment task, there is a high chance that you will need to write detailed tests (soon to find out that the company does not have time for testing in most cases). Well — do they require you to write tests for the frontend part only or extend them to the API chunk as well? Are you allowed to use libraries to write CSS layouts or not? You probably don’t want to be seen as lazy people who use someone else’s code, but on the other hand, if something is ready out of the box and well-tailored for a solution, somebody may think that you are trying to reinvent the wheel. The recruiter often provides little or no info about task solutions, so you will be advised to “just give your best”.
You haven’t started yet and you’re already facing the eternal problem of programming — every bigger piece of code can be refactored almost indefinitely. There is always a place for improvement, making better performance or better readability of code, etc. (of course keeping in mind that sometimes readability is more important than performance or vice versa). You haven’t even created a line of code and you already got a headache. Did I mention that it is a good manner to deploy an application?- having your code placed on GitHub is not enough.
No, there is no way to do it in two hours, it is probably impossible to do it even in ten if the code has to meet any standards. Additionally, the solution needs to be responsive, so you should consider mobile devices' layout as well. It doesn’t sound like fun, does it?
The other way:
There are tasks that are a lot easier obviously- some of them rely on adding parts of CSS, fixing a piece of broken code, or creating a more complicated function or algorithm. Tasks like that can turn even worse. They don’t really verify any skills, as solutions can be easily copied from the internet or advised by more experienced “friends” of the candidate. We may not “steal” the candidate’s week this time, but we already upset him, gaining no valuable information in return.
Room for improvement:
What should the programmer do then? Refusing to work on a task, tells the recruiter one thing — the task is probably too hard for you and you are nervous about sharing your code, or even worse, you don’t care about this position. In my opinion, there is only one case when you should deliver the code. The task is interesting for you and you think that you will learn something new from it. (or you don’t have an alternative). After refusing, sometimes the recruiter asks you to show your private code, but let’s be honest here. No one is obligated to be a super-duper passionate programmer developing their own startup after hours.
My main problem with recruitment homework was not only a lack of respect for someone’s private time but mostly no responses, not to mention any kind of technical feedback. Many candidates decide to spend a lot of valuable time delivering some code and after two weeks their phones stay silent. The feedback is exceptionally important for junior or mid developers especially. In most cases, they end up unmotivated and angry.
On a senior level, recruitment tasks frequency drops significantly and you are sometimes offered an extra payment for your work (what sounds a little bit more reasonable). I am not sure if it comes with more trust or worry that the candidate will lose interest. In some of the cases, they probably will, if they have a list of similar offers to choose from (a decent software engineer has). As we all know, according to human nature, everyone will try to get the best results for the smallest amount of work possible.
Today’s market searches for programmers like crazy, the pace of life keeps speeding up and there is no time for complex recruitment tasks. There are far better ways to check people’s competencies, sticking to partnership rules, in an interesting manner, respecting time, and most importantly more substantively.
To sum it up — Dear Employers, by giving recruitment tasks to programmers you steal their time and risk discouraging the candidate. You also receive code that does not fit organization standards or sometimes even someone else’s code. You will never know what the candidate was thinking when resolving the task, how he approached problems — and this is one of the most crucial things in recruitment and hiring new programmers.
In the following articles, I’ll try to come up with realistic solutions to the well-known issues of the recruitment process in IT.
Follow JIT Team, the human factor of IT
https://www.linkedin.com/company/jit-team
https://www.instagram.com/jit.team/
https://www.facebook.com/jit.team.poland/
https://dribbble.com/jitteam
