I’ve done my share of technical recruitment task reviews — you know the things that companies send to people they want to hire as homework. At least the better ones do, some just ask you to do a hacker rank type of test and boy oh boy do developers hate those.
The discussion for which one is a “better” test — puzzle tests, whiteboard scribbling, homework tasks etc. is a long and heated one, and I don’t want to go on a tangent here, just want to state that I’m firmly in the make-the-test-as-close-to-real-work-as-possible camp.
After some reviews and some feedbacks I think I can confidently give you a guide how to do it in reasonable time and get a 100% positive response! OK I jest, every company is different, but the following ideas would definitely improve your chances, and make the task fun in the process.
So without further ado — here we go:
Think about the audience
When working on a task for prospective employer, its usually wise to think of it as a piece of literature with a very specific audience. It has to compile/execute/do its job correctly, but that’s usually the bare minimum to be accepted — how it does it is usually much more important. You’re writing code that will be scrutinized to its last curly brace and you want to really shine with comments, proper names and general cleanliness.
You might be thinking — “Who will read that code? They will simply run it to see if it works and that’ll be that!”. But do you really want to work in a place like that? Where you’re carefully crafted prose is not appreciated? Anyway people usually do code review those tasks, and most often with great vigor.
So if we take it that the code would be throughly analyzed as a given, you want to make sure to reduce boiler plate code as much as possible. You want to communicate that you know a lot of concepts and ideas, but do so in as few code lines as possible. Its going to be read mainly by humans, and they might get annoyed with reviewing irrelevant code. You’re writing for a tired and critical audience remember, so respecting their time goes a long way.
You can think of it as a private conversation with the reviewer, show off some parts you’re proud of, highlight places you feel might be better, but that you didn’t have time for. It can also be used as your own filter, to see if the reviewers have noticed those little gems. If they haven’t, that would tell you something about them as well.
Visual Polish
Now lets talks about polish — funny enough, we as programmers are often given tasks that require some design or UX to implement correctly. The best ones usually push back on bad design decisions and give advice on how to improve it. So its a great idea to develop those sensibilities, even if other people would be doing the artwork. We’re the ones that have to implement it in the end, the final arbiter if you will, so knowing what looks good and works well is a highly praised skill.
That goes doubly so for implementing recruitment tasks — you’re giving a small glimpse into what you consider a well finished and presentable task, and making sure the final product looks good is half the battle.
But what if you’re a regular developer Joe like me and struggle to distinguish good design from bad? Well you can always ask a friend to review your finished project. Non-developers are especially good for this as they will point out obvious stuff that we usually miss. What I personally do is ask my significant other for a quick look. And every time without fail she points out simple UX mistakes and I have facepalm myself.
Conclusion
So to summarize — people get noticed for showing they care about their work. You can do it with code — making it clean, simple, readable, extensible, performant. Or you can do it with polish — making sure its beautiful, fun, accessible, desirable. Or best of all you can do it with a combination of both of those, but the important part is to show craftsmanship.