I frequently review code submissions for developer applicants, specifically for the Ann Arbor office. Consider this inside information if you, the reader, ever decide to apply to Atomic Object, particularly this office. I might not always be the one reviewing code, especially if there’s any point in the future when I’m no longer at Atomic Object. But it’s a fair bet that other people might have a similar way of reviewing code.
Oh, and of note, I know nothing about the applicant before I do my reviews, besides maybe a name. This is all about the code submission. So how do I review code submissions for applicants?
1. Beginning with Documentation
I will need to run the program during my review, and I can’t do that if I don’t know how to run it. Now, I can make assumptions depending on what the tech stack is, but this becomes vastly simpler if the applicant provides documentation. This means documentation on how to build the application, how to run tests, or any other things that might be useful. The thought process behind the solution, tech stack choice, etc., are also very good to have. This is not just for my benefit but for the applicant’s as well.
While working for clients, the applicant can be sure that they will need to and should maintain documentation. In fact you can read a previous article I wrote on why you should Document All the Things. That post largely focused on handing off a maintenance project, but it applies to any project.
2. Testing Testing
Once I have things built, the immediate next thing I do is run the tests. The applicant did write tests, right? I hope they did. Tests are important. Does there need to be the absolute best tests covering every case? No, but testing the various functions written for the code challenge is still a good idea. Tests are something applicants should expect during the job, and I can use their input as samples when running the application.
3. Application Testing and QA
Now we’ve come to the fun part of reviewing code submissions: making sure the application does what it’s supposed to and doesn’t do what it shouldn’t. Yes, this means I will make rudimentary attempts at breaking the application. Does it handle the correct input and give the correct output? Does it correctly handle improper input and give the user useful information on what they did wrong? How is the user experience of the application?
Granted, this is for a developer position, not a UX position, but some basic things clearly make for a poor user experience. Additionally, items that go above and beyond what was asked to make the user experience more pleasant are a bonus. An application that provides a poor user experience can get the job done for meeting the main requirements, but this should not be considered ideal. The item that made for poor user experience was likely chosen because it made the application easier to implement. This could be good enough for a first pass, but it’s always good to go back to make those inputs more user-friendly.
4. Reviewing the Code
Only after testing out the application do I finally get into reviewing the code. If you’ve ever done a code review for a pull request before, then this should be a similar process. Does the code look good? Is the project structured well? Do I notice any particular issues that might cause problems? Are there additional features that could be bonuses and expand beyond the minimum requirements? Were external libraries used? If so, was there a reason given for choosing a particular library (either in comments or in the documentation)?
Looking at the external libraries is important. Some applicants might implement a particular code themselves, which can subject them to mistakes in their implementation. But the same thing can happen with external libraries. There are pros and cons to both and on any project.
You can bet there will be a discussion around whether to implement the code by hand or by bringing in a library. If bringing one in, and if it’s a good choice, is it still supported? Does it have outstanding issues that could cause problems, etc.? An applicant that provides this reasoning is doing the same work that would be done on a project. It’s really good to see this, especially because the applicant is likely not applying for an entry-level position.
5. Writing Up the Review
It’s at this point I finally write my review. Did the application work? Was there good documentation and commenting where needed? Did the tests pass and cover a good amount of the code? Is it really just a retelling of my process? Did I notice anything that wasn’t done well or anything exceptional? At the end of the day, I should expect the application to work as expected and everything to be above entry-level.
This whole process from start to finish can take me up to two hours for the non-entry level positions. This seems like a lot, but I’m thorough, and my reviews are well thought out. I put care into doing things right by the applicant. You might say I Give a Shit. This is also beneficial for hiring as it tends to yield greater information to base decisions on.
Reviewing Code Submissions
So, I hope this helps someone else review code submissions. If you are someone who reviews code submissions, is there anything you do that I didn’t mention?