Why we Still Ask for an Assignment Task

Pexels.com

Objective

Hiring engineers has become a major part of my daily work. Doing this for a while lead me through different phases. I used different approaches, different processes, worked with different assistants supporting me and finally found a system that works well for me (but might change in the future of course).

Our hiring process is kept simple and fast and consists of a few stages only:

• Getting the application (directly, via recommendation, recruiter, etc.)
• Introduction call with the candidate to bond on a personal level and explain our hiring process
• Assignment Task
• Technical interview with the engineers who reviewed the task
• Trial day in our office
• Offer

Today I only want to talk about the assignment task part. Why do we request it, what needs to be considered to get the most out of it? This post tries to address those topics from our point of view.

Motivation

When you hire a software developer, I think it would be careless not to ask to code something for you. Or at least to show you relevant examples of past work to make sure the candidate knows his or her craft. Usually I prefer a dedicated coding task over those already existing repositories, since it allows us to focus more on our specific challenges and tech stack. It is more easily comparable with other candidates and it also shows the applicant really likes to write code and also puts some effort into the application.

Talk is cheap, show me the code!

— Linus Torvalds

Developers are a rare asset nowadays and consequently companies are competing for their service. As an employer you have to offer a great working environment, freedom, purpose, challenging tasks and a top salary on top. And nothing is wrong with it. But also we as a company have our standards and have to keep true to them. In the end coding is what a developer is supposed to like most. So why shouldn’t a candidate be willing to do so?

To have a fair and significant assignment task, a few things should be considered.

• The coding task must not be ridiculously extensive. I heard of tasks taking a week to finish. I think, given you are familiar with the technology, it shouldn’t exceed 2–4 hours of coding.
• It also should be a real world example and not designed to trick the candidate.
• It should also be clear how you review the code. What is the focus? What is important for you? How do you review? We dedicate a whole paragraph of our task description on this topic (e.g. „We’re not looking for full coverage but just trying to get a feel for your testing skills.”).
• But also it needs to be exciting. At least a little bit. And it should also give the candidate the opportunity to be creative. Don’t write a step-by-step instruction about what needs to be done in what specific order. Nobody wants to be micro-managed.
• A few companies do online-tasks, basically watching the candidate coding. I don’t like this approach. It feels a little bit like hurting someone’s privacy, increasing the pressure on the applicant and somehow not trusting the person doing the task without help. I tend to trust the candidate. You still can ask to make some code changes during a consecutive interview. If the aspirant didn’t write the code, he or she will fail at this point.
• Sometimes we add some optional bonus tasks, but in general I like to be surprised by the candidate by adding bonus parts himself, e.g. make the application deployable in a Docker container. But to be honest, this rarely happens.

Results

The majority of the assignment tasks we receive back is well written code with a clear structure, clear responsibilities and mostly properly tested. And everything in between. I have to admit the general code quality improved significantly over the last years which is great and shows that education and craftsmanship of developers considerably improved.

But on the other hand it is hard to understand why a developer, who decided to write code for a living, would deliver unformatted, sloppy written code. In the end it is the personal advertisement of the candidate. This should always be considered when handing in an assignment task.

Review

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

— Martin Golding

As I stated earlier, we make it very clear how we review, what our focus areas are and what is important to us. A few candidates like to show off and put every design pattern they know into a simple functionality. KISS and YAGNI come to my mind then. But on the other hand the applicant also tries to put a lot of knowledge into simple code to demonstrate what he or she already knows and is able to do. There is nothing you could say against it. Sometimes it’s hard to find a balance between „cool and well done“ and „over engineered“. I personally don’t like 5 layers of abstraction. Also not in production code.

A good programmer’s practice is to add a proper maintained readme file where the candidate explains his decision making process regarding the assignment. Why is it maybe a little bit too complicated or kept simple, why was a certain library used and why not, what about the testing, etc.

Feedback

Giving feedback is hard. Getting feedback even harder. Especially when you have been declined. It feels a little bit like being rejected and this hurts. I try to provide our thoughts about the code and why we think it wasn’t meeting our expectations to give the contributor the chance to improve and maybe to do better the next time.

Provide your feedback carefully. Try to be specific, direct but not personal.

But not everybody takes critique easy. We all know it hurts to find out not being “good enough” and maybe you wouldn’t agree to the feedback received. You defend your code because you put effort and thought into writing it and consequently it reflects a part of yourself. But feedback is a gift and should be taken serious. At least a few unprejudiced thoughts could be spent on it. One doesn’t need to agree but accept it as it is.

What we do is, we take some time to write down what we liked and what not and what lead to declining the candidate. Still, you cannot please everyone but you have to be honest and transparent and stick to your own standards.

Conclusion

For me and my team it is key to see and feel code of a potential candidate since this is basically the essence of a new team member. If you don’t feel comfortable with what is being provided, you need to decline this applicant. But for sure you have to have clear expectations about what you want to get out of such an assignment and you have to make it clear to the aspirant. Not being transparent in this regard neither helps the candidate nor the people looking for a new colleague. If you decline, give feedback. Most likely time and effort were put into the task, so it can be expected you also put some effort into your feedback. Show the blank spots, the weaknesses, but maybe also say what was good. We wouldn’t hire a developer without ever having touched some of his code. It wouldn’t feel right.

Do you also insist on assignment tasks? What are your experiences? And if not, what approach do you follow?

Curious about our company and the picky team? We are hiring. ;-)