8 most common mistakes that people make during the technical recruitment tasks

During the last few years at SoftwareMill company, I’ve had the opportunity to make around 50 code reviews for candidates. We care about making reviews as good as possible and giving the most accurate feedback, so often we spend 2-3 hours on a single review. I would like to share with you my thoughts about some most common mistakes that people tend to make.

We won’t talk here about specific technology decisions because those are context-specific. If some decision is good or bad often depends on many assumptions that the author makes. I will focus more on the approach which you can apply to all recruitments, not only for our company - we invite you to try it, though. :)

So let’s start!

1. It's not a real task approach.

Have you ever heard about interviews when a recruiter comes to the meeting and doesn’t even know the name of the candidate? There is a special place for that kind of people - on the block list.

But what if you would treat your job as something unimportant and not worth getting involved in? Also, not great, right? Sometimes I’ve met a solution when the developer thinks that they don't need to care about the quality of the task because it’s only recruitment.

It's true, this solution will not be deployed in production. Nobody will use that, and nobody will gain from this code. Nobody but you. As a reviewer, I would need to know your definition of a fine solution. Would I like to work with someone like you? Would you treat your code as a good engineer or not?

If your solution is poorly written, I honestly don’t know what the reason is. Is it your skill? Or maybe you just assume that you don't need to care about quality? Hard to make an optimistic assumption here.

2. I did not have time, but I’m also not saying it.

Life is unexpected, and even if you agree to do a recruitment task in two weeks, you may get surprised. Maybe you or your family member got sick, maybe you had to take care of the kids, or you could not focus for some other reason.

It's really fine. 

Most people-focused companies will understand that. That’s why you should inform them about the lack of time and just ask for more. As the reviewer, I personally like it when someone treats me like a buddy to work with rather than an obstacle to overcome. A recruiter's answer is a good way to validate if you want to work for this company. Because who would want to work in a place that does not care about its own employees?

Thanks to that, you will be sure that your solution is good enough, and the reviewer will not wonder why this code is so great in one place and so bad in another.

3. Too many assumptions

During the creation of the solution, you may stumble upon a problem, what exactly does the company want from you? Most of the time, that is caused by unclear requirements. In this situation, it's good to avoid complex assumptions because your solution will highly depend on that.

Just like in the point above, communication is key. Ask the recruiter how your solution should work in some edge cases. Just treat them as a client who has all the requirements for your application. Most companies appreciate this approach because they know that’s how you will behave with business or their clients.

Also, it's possible that they don’t know about mistakes in requirements, so your questions could make them better. It's a win-win situation.

4. Let’s play with some new tools

Who doesn’t like playing with some new tools, right? Learn a new framework, library or discover something interesting. That's amazing and god bless people who learn that in their free time. Thanks to them, we evolved as an industry.

But it’s good to ask yourself if recruitment is the best place to try those new shiny things. If your task will be reviewed by a veteran of the technology which you are just playing with, you will have a problem, because the reviewer does not know why you made some mistakes.

Of course, that raises a question, should a reviewer care so much about technology and details done by the candidates? But we all are humans, and when something is simple for us, we tend to forget about how hard it was to master that skill.

That’s why to avoid this problem, you can mix new shiny stuff with something that you are great with and inform the reviewer in a README file or email that some of the technologies are new for you.

5. Solution with no tests

Would you ever ride a car knowing that no one tested it? Yea, no one would like to. That’s why solutions without tests will raise a red flag. Testing your own solutions is so crucial during software development. So during the review process, most reviewers will look into that. But not only on the percentage coverage but also on the quality of your tests.

Tests are also a great place to understand your domain, edge cases, and how your business flow looks like. In your production code, readable tests will make a lot of developers happy when they go deep into your solution. And this is the reason why you should care about naming tests, their structure, and how easy it is to understand them.

So please, do yourself a favor and write tests.

6. Over-engineering

There are some solutions where candidates go wild, add new features, change the whole stack, and even introduce new architecture solutions.
I once had a solution when the author introduced event sourcing in a quite simple application. Was that bad? No, trying hard to make a good solution is fine, better than making a solution poorly. Remember though, that solution should work very well because if you add too much unneeded sugar to our code, a question will be raised - “What if this candidate does that when working with a client?”

7. Under-engineering

The point with over-engineering may scare you off, but it’s better to spend some time with a better and more clean solution than leave your code in a half-baked state. There are many reviews where I wonder, “What if the author spends some time with this code?”.

Sometimes time is a problem, but like I just mentioned, you can communicate with the company to ask for more time.

8. Git History

If we want to see your solution as close to production as possible, that would be great to see how you organize your commits. Naming conventions or how you split your work into specific commits. That may introduce a good vibe from your code at the beginning. The cost is low, but you can gain a lot.

Summary

If you take into consideration those 8 things, your recruitment task will have a better evaluation. It’s worth mentioning that those points are subjective, every company and even every person has their own things that are important for them during the review process.

Good Luck with your future recruitments!