While take-home tests can be useful for the interview process and may be great tools for interviewing junior-level developers, there are several disadvantages to using them for senior-level developers.
Not every interview process is the same, and a job seeker can’t possibly pass all interviews. This is common knowledge. Therefore, a solid strategy would be to focus on only doing interviews that you can pass.
For me, that means not doing take-home code tests. This might be because, with almost two decades of experience, I’ve learned enough to recognize that if a person doesn’t have the ability to ask questions, they won’t know what is expected. In my case, this leads to additional stress and time taken. And ultimately, this means that an interviewer learns nothing about how I’ll work once I’m truly on the job.
One alternative to a take-home coding test is a Zoom call with a shared code pad. In this case, you could work on a LeetCode-style question that can be quickly understood and has a well-defined outcome. This kind of question is a fairer evaluation for candidates because a job-seeker can study LeetCode-style questions well especially when using the Blind 75 list of questions.
Indeed, when answering these questions live in an interview, a person can ask questions about what’s expected or ask for help if needed, which closely mirrors what they’ll do at their actual job. This kind of question is much more fair than picking some code from your organization’s codebase and having a candidate work on it.
That may not seem obvious at first, but while you’ve had weeks or even years of experience with that code, the candidate will be seeing it for the first time; they need to “grok” it before they can even understand what’s required of them.
Even when a code test says, “only spend 2 hours on this,” candidates understand that an organization wants production-level code—with unit tests. This means that a prospective employee will spend 8-16 hours on a code test that might not even lead to a real interview with an engineer.
When compared to other interviews, doing an 8-16 hour take-home code test to make the code feel impressive enough and “production ready” is not the best use of anyone’s time. This is because even when someone says, “Don’t spend too much time on it,” a candidate will spend their whole weekend on it to make it the best code they’ve ever written, totally production-ready, even though the project will never see the light of day.
Furthermore, the person giving the assignment doesn’t have the same expectations as the person who grades the assignment. For example, in a not-so-recent interview, the person who assigned my code test was not the person who would be grading it. In fact, the person assigning the test was not very technical at all. In reality, the person grading the tests expected me to spend hours or days on the problem and write code tests and (probably) wanted to see me create a CI/CD setup for it.
This is very different from what happens at work when a person starts a project.
In my case, I’ll work out what the requirements are, then work out an overall design/architecture and get feedback on it. After that, I would work on it iteratively while getting feedback via code reviews.
While it’s true that a person could fire off a few questions to a company to get clarification, this is entirely different from how work is actually done on a project. In that case, you’d have a meeting and talk face-to-face. However, you must code blindly with a take-home code test because you’re missing out on this crucial requirement-gathering step.
People also put traps in the code to see if a prospective employee will change or fix it. While this may seem like a wise use of time, allowing the employer to see how closely the code is scrutinized, it reflects poorly on the company. It can make the candidate feel as though the organization is unprofessional and lacks respect for its employees.
While take-home tests may be a good tool for evaluating junior-level developers, they are a double-edged sword. For more seasoned professionals, a collaborative and transparent in-person (or Zoom) approach that mirrors real-world development would lead to a more accurate and fair assessment of a candidate’s skills. This is why LeetCode-style questions are a better tool for evaluating senior-level candidates.