Few months ago, I caught up with one of my former colleague. They told me that they have been applying for a role in a several places, and our discussion moved towards the interview processes that companies had. They mentioned that in one of their interviews, they were flat out rejected in the initial stage of the interview process because of there was no unit tests submitted for their take-home test.
Normally I would have agreed with the decision. However after being shown the email conversation, I could see that there was no indication that they had to submit any tests of any kind, and the take-home test did not have any in the first place. This particular situation got me thinking, is it fair to reject a candidate outright simply because they did not provide any unit tests, even though it was not required of them to do so? There are few things in mind before I can answer that question.
Software engineering is not about just writing code
Irrespective of my former colleague’s complaint, it is still a fact that unit tests have existed for quite a some time. I remember discussing about it during my first year of university learning about computer science and software engineering. One would have to be living under a rock to not know of unit tests and the benefits that it brings. Note that I specifically mention unit tests, and not engineering practices based on tests such as TDD or BDD.
These days, however, software engineering is much more than just writing code. Sure, writing good quality code guided by engineering best practice is still a large part of it, but it also encompasses designing a robust infrastructure, configuring the deployment pipeline, ensuring maintainability of applications, and tending to the evergrowing technical debts. These are all on top of other non-engineering tasks such as retros, cross-team collaboration, and contributions to their special interest groups in their workplace.
This means that unit test is only but a small part of the software engineer’s day-to-day tasks. One might argue that good quality code implicitly means that unit tests should be included, however I would challenge that notion. I have seen repositories where the code design was brilliant, but the unit tests leave much to be desired. There is nothing worse than unit tests that do not serve a purpose for validating anything. Might as well not have any tests in that case.
If the take-home tests was given in the middle of the interview process, then sure, you would have the chance to gauge the candidate properly. But normally take-home tests are given as the first hurdle for candidates to go through. By eliminating candidates just because they do not have unit tests in their take-home tests, you are essentially depriving yourself (and your organisation) to see how the candidate work and what they have to offer in further interviews.
Never assume others follow the same engineering practice as you do
Interestingly, the feedback that was given to my former colleague was that the code submitted was not up to par with the engineering standards in their organisation, and that unit tests are a big part of those principles. I don’t have any issues with organisations setting up their own engineering standard, however, what I take issue was that they assumed that everyone has the same engineering standard as their organisation’s engineering practices, which to be quite honest, is dumb.
First of all, as a candidate, how would you have known what the reviewer expected if the expectation was not clearly communicated? Are you setting up the candidate to be successful in this role, or are you setting them up to fail by maliciously having “gotchas” in your process? If it is the latter, then I would say good riddance to my former colleague because that’s exactly the type of company you do not want to work for.
Secondly, even though unit tests are such a standard practice these days, it is still a fact that many companies and organisations put unit tests as second-class citizens. For companies that have QA engineers, these responsibilities are normally assigned to them, rather than the engineer responsible for the code.
Even for companies without QA engineers, often times software engineers have to juggle between delivering a feature versus taking their time to write unit tests. And sometimes these decisions are simply overriden at a managerial level, and especially in a fast-paced environment, writing unit tests can be seen as a waste of time.
So you cannot always assume that the candidate is familiar with the practice of unit tests, and if it is such a critical piece of software engineering practice in your organisation, make that expectation extremely clear in the communication to the candidate.
Is it fair or not?
Coming back to the initial question, is it fair to reject a candidate because their take-home test does not have unit tests, even though there was no requirement to submit them? Now to be completely honest, the answer for this will depend on where you are as a (software) engineer, and how you perceive what an engineer should be doing in their day-to-day operations.
From an engineering perspective, I see unit tests as something akin to pair programming. Everyone knows of it, but not many have actually invest themselves in it. Would you say it is fair to reject a candidate simply because they never did any pair programming, and your organisation is heavily reliant on it?
Nevertheless, for me, the answer to both questions is a resounding no, it is not fair at all. As I’ve mentioned earlier, software engineering is much more than simply writing code, and if you are truly setting up a candidate for success (as you should be) and that your company is as good as you make it to be, the candidate would be able to pick up unit tests in no time.
The existence of unit tests are not and should not be a measure of competence. It is but a small part of good engineering principles, and one that can vary from one organisation to another. Just because the candidate does not submit unit tests, it does not mean they are not competent.