Code Challenge Review — What Most Reviewers Prefer

Over the past couple of months, I have written and reviewed a ton of code. My Github contributions chart says that code reviews amount to 65%+ of my contributions in the past year. I agree with this because I recall deciding to partake in a lot of code reviews at the beginning of this year.

Photo by Hitesh Choudhary on Unsplash

It is unsurprising that I eventually found myself volunteering to review the code submissions of android engineering candidates who would like to work with us. A decision which I would say turned out to be a really good one.

In this post, I intend to share some tips on how to increase the likelihood that a reviewer would find your code delightful to review. Most of what I will say are based on my experience reviewing the code submissions and would likely contain some biases, so do not see this as a fixed rule. Let us begin.

Have a seamless setup

A pet peeve of mine as a reviewer is having to jump through hoops to get someone else’s code to build and run successfully on my device. A reviewer’s first impression of a candidate’s codebase begins at this very first step.

In some cases, I would advise that only stable releases of libraries and tools should be used when writing the project. This way, you are sure that the chances of this step going bad would be low.

I should point out that experimental or unstable releases should only be used in a case where it is absolutely necessary. I would personally understand seeing the usage of experimental stuff in Jetpack Compose and Kotlin Coroutines.

Finally, the project structure should be familiar. It should be easy for anyone to know where to find dependency injection, view models, or UI classes. I also appreciate it greatly whenever the project is split into meaningful submodules that are linked through modular dependencies.

Write documentation

There should be a README file in your project. Ideally, every project needs one. Even if you do not have any documentation to write in this file, I would still advise one to create it and then put the the description of the task in this file and then put a checkmark next to each objective of the task.

If there is an additional setup that needs to be done before the project is able to build successfully, this should be mentioned in the README. For example, if you expect to read the value of aTHIRD_PARTY_LIBRARY_API_KEY in a file called, this should be mentioned in the README file.

Other forms of documentation should also be present where necessary. For example, if a deprecation warning is intentionally suppressed, I expect to see a comment that explains why the recommended approach was ignored.

A lot has been written on writing code comments already, in order not to inflate this post more than necessary I’ll refer you to this post about the best practices for writing code comments.

Keep it simple, stupid

Trying to understand a complicated code snippet breaks a reviewer’s flow. There are already some established architectural patterns which software engineers are familiar with. Violating this principle, by introducing an unnecessary complexity, rather than breaking down the complex code into simpler steps doesn’t help anyone.

A common occurrence of a transgression to this principle is visible when one’s codebase has god classes. For example, having stuff like:abstract BaseActivity, abstract BaseFragment, abstract BaseViewModel, etc, should be avoided.

The reason is that there’s an extra mental effort that is required to understand what happens in BaseFooBar before I can continue with the class that inherits from it. A tip to avoid this would be to favour composition over inheritance when adding behaviour to your classes.

Showcase your knowledge of modern tools

Utilising modern stable programming tools is one of the best ways to prove that you know your beans. What better way does one have to impress a reviewer than to have the reviewer review a project that shows that they are up to date with the techosystem?

For instance, newer android projects should use the Gradle Kotlin DSL + buildSrc rather than the Groovy DSL to declare the gradle configurations. Also, extension functions should be used instead of Utility Classes.

Speaking of extension functions, knowledge of existing extension functions in the androidx libraries is a huge plus. A final tip is that delegated properties like the View Binding delegates could be used to reduce boilerplate code.

Perform code quality checks

Before you submit your code for review, it is important to ensure that ALL lint errors are resolved. An easy way to ensure that there are no lint errors is to set the abortOnError flag to true in the lintOptions configuration.

If you are able to ./gradlew clean build your project without errors after this is configured then your project is lint/dust free. You could even go the extra mile of setting up detekt & ktlint to check your Kotlin files more thoroughly.

Finally, I cannot overstate how important it is to ensure that your code is properly formatted. As a rule of thumb, you could default to using the kotlin style guide provided by Google. If you have decided to use ktlint, it comes with a ktlintFormat task which you could use to quickly format the entire kotlin files in your project.

Write tests

Ideally, every project should have tests. There are differing opinions about this and I strongly feel that senior & mid-level engineers should have tests in their codebase.

You get bonus points if all your tests pass successfully.

What to test is another topic. A hint is to look at the objectives of the task and write test cases for these objectives. I have discovered that writing tests can make one to discover some unhandled edge case scenarios.

It feels quicker to write unit tests and leave out UI tests, however I would advise that some UI tests be present in the project.

If you decide to not include tests in the project, please delete the src/androidTest & src/test folders from your project. There’s no greater disappointment than expecting to see actual tests in those folders only to see the auto-generated ExampleInstrumentedTest and ExampleUnitTest classes.

These are not hard rules, coding challenges are usually written under some time pressure and I will understand if the entire codebase is not perfect.

The code submitted to a coding challenge is NOT the developer’s best code. It is their code that was done within the pressure of the hiring process. We could review the code, see if it works, see if the design matches our idea of the design and then decide based on that if they are any good. — Andy Davis

I hope that these tips provide some help that would nudge you towards writing code that is easier for reviewers to review. If you feel like there’s something I missed out, please let me know in the comments.

Bis später ✌🏽.

Software developer. Learning everyday.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

These are the highest paying Tech Jobs Programmers can aim to increase their Pay in 2022

Alium Initial NFT Offering / Public Token Sale

Basic Pentesting CTF Walkthrough TryHackMe

What is the Role of Python in Data Science?

How Docker Is Disrupting Legacy IT Companies

Review: Rey — Fashion and Clothing, Furniture

Review: Rey - Fashion and Clothing, Furniture

Automate Alibaba Cloud infra building with Terraform (step 2)

How to double jump in Unity

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ben Daniel A.

Ben Daniel A.

Software developer. Learning everyday.

More from Medium

Learn New Programming Language with “Auxiliary Language

Challenges of writing correct concurrent code

Challenges of Single Vs Multi threading applications

Why Software Development is a Never-Ending Process?

Testing Delayed Tasks in Robolectric