Secrets from the Interview Room — What Reviewers Look For in a Take-home Coding Assignment

Photo by Negative Space on Pexels

R&D organizations have various technical interview approaches, as part of their recruiting processes.
The company I work for, BigPanda, practices a take-home coding challenge, to help determine the quality and technical fit of the candidate.
Once the task is reviewed and its level passes the needed bar, an interview takes place in which the candidate has the opportunity to present her/his work, explain her/his design decisions and answer a wide range of questions.

The purpose of the post is not discussing whether this process is better than others, as countless other blogs, talks and threads have already gone under and above.

During the past months, as part of my responsibility as an interviewer, I’ve checked a fair share of assignments and held many post-review face-to-face interviews. While each implementation differs from the others, prominent recurring mistakes are made and significant topics get ignored.

This post is written to help candidates avoid these pitfalls and emphasize several points that the assignment checker looks for.

Disclaimer: Each coding assignment focuses on certain fields and has its specific goals. I tried to gather general common issues and misconceptions, which are language and framework agnostic.

📇 First Impression: the assignment is your business card

Before diving in, I’d like to highlight a general guideline.
To the reviewer, the task you’ve submitted reflects your skills and line of thinking in the most unmediated way.
To me, it says more about the candidate than his/her resume and LinkedIn profile. Kinda like one’s GitHub account when contributing to open source projects.
While hacking the challenge, keep in mind the time and effort you invest in enhancing and bulletproofing your CV or social networks accounts.

👍 It MUST work!

This may sound obvious to most readers, but the truth is a great deal of submissions fail on execution.
Personally, when I encounter a thrown error in the first run attempt I always check whether it’s something I can quickly solve before rejecting the assignment. But you don’t want to count on the reviewer’s kindness, let alone spare debugging time.

The majority of failures are caused due to missing required packages or third-party modules. This means that these libraries were not specified in your solution’s dependencies list (package.json, requirements.txt etc.).
They were probably globally installed in your working environment.

Pro tip: My suggestion is to apply the same methodology I practice for testing a candidate’s task — run it on a “clean” environment, to prevent the effect of system-wide installed packages.
There are several ways to achieve that such as using a sandboxed environment (virtualenv for Python, RVM for Ruby etc.), running your code inside a container with a minimal image. Asking a friend to run your code on his/her machine doesn’t guarantee exceptions clean execution.

💪 3rd Party Modules to the Rescue

These days most, if not all software companies use open source libraries in their products. Some companies take an extra step and give back to the community by contributing or open sourcing their own written projects. This collaboration improves code quality and generally drives the industry forward. But that’s a little off-topic.

My point here is, don’t assume you’re expected to write the entire solution yourself. Some reviewers, me included, actually appreciate the ability to locate the right packages, integrate and utilize them in your code in a clean elegant way. As it is a common pattern in a developer’s daily routine.

There are countless of examples to where external packages can come in handy and spare you a significant amount of time. One that comes to mind is using a design library, like Bootstrap/Material-UI/Semantic-UI/other, when working on a Frontend or Fullstack exercise.

Disclaimer: the core of the solution should be solved by you, in a way that allows you to “defend” it in the follow-up interview.

Pro tip: Make sure you have at least a basic understanding of the package you’re using, you may be asked about it in the follow-up interview. And again, mention the package in your README.

Source unknown, received via Slack

🕵 Use Style Guide or Linter

Style guides, like Python’s PEP8, improve the readability of code and make it more consistent. This becomes even more important If you’re a Junior Developer and not fully familiar with coding standards in the industry.
Linters, like JavaScript’s eslint, adds another layer that helps you avoid errors and potential risks.

You have a limited time, don’t waste it wondering if you should use tabs vs spaces or looking for typos. Style guides and linters also make sure you don’t miss a leftover you forgot to remove like a TODO, comment or print.
Most linters even have automatic fixers and are pluggable in most IDEs.
It doesn’t matter which style guide/linter you choose, as long as you’re consistent with it throughout your code.

Enforcing a set of rules will help the reviewer focus on what really matters — your architecture decisions and the implementation logic (no “bikeshedding” needed).

Pro tip: Remember to state the style guide/linter you chose in your README.

🐙 Source Code Hosting and Version Control

Most companies I know use a web-based hosting service for version control using Git, whether it is GitHub, GitLab, BitBucket or others.
Having the option to host both private and open projects makes them the best platform to use for coding exercises. That is why I was pretty surprised when several candidates chose to send their code via email.

While it may not be a requirement, my advice is to always submit your assignment through the code hosting service the company you’re applying to is using, for 2 main reasons:

1. It makes your interviewers’ life easier — she/he can simply clone it to the working environment as opposed to downloading specific files, moving them around and in some cases even renaming them.
   An alternative can be to use the code hosting web UI for checking and the post-assignment interview.
2. As I’ve mentioned before, it has become an industry’s standard.
   Less experienced developers may be a little intimidated by working with GitHub for example, but the truth is, it is simple enough that companies nowadays expect candidates to know or learn by themselves.

Pro tip #1: If you’re concerned your current employer may see your submitted task, make sure to use a private repo.

Pro tip #2: Break your code into logical commits (if you aren’t already following this paradigm). It helps the reviewer check your assignment and better understand your line of thinking and the development process you followed.
It is OK, of course, to rearrange the commits once you’re done, just don’t squash them all together.
I wouldn’t go as far as ensuring each change functions independently, like I do in my day-2-day work, especially for tasks that aren’t too complex.

Will It Work, Git Commit by xkcd

🛂 Tests

Tests can be a lot of work, and may not even be a demand in some exercises.
But that doesn’t mean you shouldn’t include them, here’s why:

1. Aside from verifying correctness and logic, tests prevent regressions caused by refactors, performance improvements and lint fixes (“making it pretty”).
2. The reviewer can use them to easily spot the different variations and edge cases you’ve handled, as well as areas you consider logically complexed. Tests can also be seen as a form of code documentation.
3. They make your task stand out, simply because other candidates tend to spare them.

R&D organizations have different takes on writing tests. Some expect their developers to write unit-tests only, while others strive for code ownership and sense of responsibility, with integration and system tests.
Regardless, it is a skill worth crafting even if the company you’re applying to sees its QA department as the sole liable for tests coverage.

Pro tip: Try to use Test Driven Development (TDD). I truly believe it speeds up the development process by forcing you to plan before you execute and by catching regressions. At the end of the day, you have limited time don’t spend it manually testing after each change.

testing-in-a-nutshell by Monkeyuser.com

✍️ Documentation

Writing code documentation is an integral part of a developer’s work, whether in her/his daily tasks or in a coding assignment.
By Documentation I mean instructions and messages for the reviewer, not inner code comments.

Going back to the hosting/version control section, IMO the simplest and quickest form is specifying all the required data in a README.md file.
It has a straightforward formatting syntax and in general probably the most commonly used lightweight markup language, at least for code projects.

Before listing the sections, one thing you should have in mind when writing your README:
Don’t assume the reviewer has any prior knowledge of your submission. If there is any doubt you need to explain something, there is no doubt.

Must Haves

1. Installation Instructions
   Trying to test a challenge without them can be very frustrating and time-consuming.
2. Usage and Examples
   Though it may look obvious to you, your CLI/API implementation could be significantly different from the ways others solved the assignment.
3. Technologies and Packages Used
   Going over a list of building blocks will save the reviewer time and allow them to focus on the actual logic. Use this part to double check you have a decent understanding of what the framework you utilized actually do and double check no unused libraries left.

Nice to have

1. Code Complexity Analysis
   Though really exercise-specific, reading why the candidate chose an algorithm or a data structure demonstrates thought and perception. I recommend using the big O notation for time complexity.
2. Assumptions and Disclaimers
   If your solution is based on certain assumptions you’ve taken make sure to list them.
   Using the programming language/framework/database for the first time? that’s perfectly fine, just make sure to note it so that you won’t be valuated as a veteran.
3. The Extra Mile
   There are other ways I haven’t mention to make your submission shine.
   Whether you solved the bonus, implemented data validation and error handling or covered the trickiest edge cases, don’t rely on the examiner to notice it.

Pro tip: At the end of the day, reviewing candidates submissions isn’t the most thrilling task for the recruiting manager. Adding ASCII art/MEME/gif related to the company or the assignment might make it stand out and bring a smile to your reviewer’s face.

I hope this post will help you get a better understanding of the reviewer’s point of view when hacking your next coding assignment 🙏

If you have other tips you think others could learn from please write them in the comments section below 👇

For (almost) daily “Today I Learned” coding tips n tricks checkout my website.