Pavel PolívkaI reviewed a lot of take home coding challenges. Our challenge was designed for junior/beginning Java developers. In this article I want to compile list of recommendations on how to ace this challenge. These recommendations can be applied to all developers.
In my experience person doing the review will not spend huge amount of time reviewing your code. In most cases they will not even run it. I am not saying that that you send them nonfunctional piece of code. I am saying that the most important thing you can do is have everything clear and obvious. Do not spend huge amount of time on some abstractions, complex algorithms or other bragging opportunities. Those challenges are usually designed to be simple and reviewer wants to see simple solution.
Project setup
Our assignment was always bit vague. But one of the instructions was to use a concrete library for parsing CSV files. As a reviewer you looked on how the library was integrated into the project. In Java you looked if Maven or Gradle was used. If not was the library present as a jar file? There were cases where we received full Eclipse workspace. In Java Script you would look for NPM or was the library just linked in the script tag?
This tells how familiar you are with the tooling around the language you are interviewing for. As I was doing mostly junior positions it was not necessarily bad if the person did not used Maven. That is something you can teach them. But it always was huge plus if they did.
There is a lot of project creation tools out there. For Java you can use Spring Initializer , for Java Script Yeoman. Your code will look much more professional. You increase the changes of reviewer actually running your code. And you will learn something you will need anyway.
Clean code
There is a lot of resources online on how to do clean code. You do not have to follow it one to one. But some general principles should be applied. The best principle you can follow is newspaper article analogy.
Image your code structure as a newspaper article. Headline is your class name. Public methods are first few paragraphs. Private methods are rest of the article. Each class should be its own story. This will increase readability of your code. Reviewer will have easier time reading your code and it gives you a lot of plus points, as readable code is must for working in team.
You should also choose some kind of formatting and stick to it. Most modern IDEs can reformat your code, please run it before submitting your code. It looks ugly if each method/class/line has different formatting. Do not worry about tabs vs spaces or any other topic. Just choose what fits you.
Be careful naming things. Classes, variables, functions etc.. Do not use unnecessary shortcuts. Why use Stor instead of Store? Names should be descriptive, but avoid long names that feel like straight out of Corporate Name Generator.
Logging
I always looked how logging was done. Was it present? How? Was it just System.out.print? Next level would be java.util.logging and best would be SLF4J. Obviously some logs are better than no logs. I usually did not recommend solutions without logging.
I would consider error handling as part of this. Every time I see e.printStackTrace() in catch block I am subtracting some points. Least you can do is log it properly.
Writing tests
Another huge part is test writing. Tests are the best thing you can do to standout in this challenge. I understand that testing may be hard for you, it takes some time and you want to do this challenge as quickly as possible. You do not need to TDD this challenge. You can just test the happy path. If you are out of time, you just write few tests, and rest you just prepare test methods and leave comments explaining what are you about to test.
Tests tell me that quality of the code you are writing is important for you. It tells me that you can write testable code. And it tells me that you are willing to write those.
Documentation
You do not really need to document everything and append 50 pages long documentation with your challenge. But still nice README.md explaining how to run your app is a must. Look at your favorite open source project on GitHub and try to do something similar in your README.
Bonus points
Few bonus points you can get are
- Some CI integration
- App is actually running/is deployed somewhere
- You provide doc with next steps you would do to improve this app
I can do quick code review for you if you are not sure about your results. DM me on Twitter
