You’re a junior developer, you have your first tech test, and you want to impress the potential employer. Here’s how.

README
This is the first thing I look at. Your README should have:
– the specs (what the problem is you’re trying to solve)
– instructions to run the code (assume I will clone the repo – then what should I do?)
– any explanations you want to give for why you did things
– further refinements / features you would add given more time

Git Usage
While there have been other version control systems, git is industry standard now and I’d expect to see it on any tech test.

.gitignore
Even if it’s blank (and it won’t be if you are using npm packages or an IDE), it shows you’ve thought about what needs to be committed to a git repo and what doesn’t.

Commit History
This is a more controversial one, as looking at my own history, I see the occasional gem such as “3312: make code less manky”, and I’d hate for people to think every commit message has to be a work of art. However, a good commit history can show your thought process and your collaborative skills – what happens when you win the lottery and I have to take over your project? First thing I do is look at the commit history as a summary of what you’ve done and how you approached the project.

Code Analysis
I want to understand how you’ve thought about the code. In particular, I want to see:
– code coverage (SimpleCov for Ruby, for JavaScript use Jest’s built-in –coverage flag or Istanbul/nyc)
– linter (Rubocop for Ruby, eslint for JavaScript)

Testing
The first part of the code I look at is your tests. Poor test coverage is an immediate cause for rejection. In addition to 95% or higher line coverage (there is a law of diminishing returns so don’t worry about getting it to 100%), I also want to see:
– boundary test cases: if you’re working with numbers, have you tested one above and one below your highest/lowest number? Or if working with text, have you considered whitespace before and after the word/characters?
– error handling: particularly in dynamically typed languages such as JavaScript and Ruby, what happens if the calling code gives the wrong type of input, or no input, or too much input? E.g., if you have a function to multiply two numbers, what if one of the inputs is a string? (Side note, this is why I prefer statically typed languages, which specify a type and will fail to compile if the type is wrong!)

And finally, do yourself a favour and learn TDD. It will solve most of your test and code problems. Kent Beck’s book is a great place to start – it’s in Java, but you can translate as you go to the object-oriented language of your choice.

Code
The last thing I look at is for your code. And the first thing I look at is whether you follow Sandi Metz’s Rules for Developers. While they might not always be relevant in production, real-life code (although they often are!), there’s generally no reason that in the artificial environment of a tech test you can’t follow these rules. And in fact, you should also apply these rules to your test code.

Then, when I’m looking at your code, I’m thinking, “If there is a bug in this code on Friday at 4pm, will I be able to understand clearly what’s going on or will I be tearing my hear out?” In other words, does it communicate its intention clearly? Code does this by:
– short methods that do one thing only
– methods and variables that are named according to what they do (if you have a method that is called getResponseFromServerAndComputeFunction, that method is too long and doing too many things)

Immediate Rejection List
The following will guarantee you an immediate rejection from a lot of reviewers, myself included:
– no README. We are busy and don’t want to use a crystal ball to figure out what we’re supposed to do
– no tests or poor test coverage
– not using git or all code in a single commit

And finally, I want to clarify that this is my personal list, heavily informed by my training at Makers, coding best practices, and my experience as a professional developer. Not everyone will have this same list and I also try to approach each candidate with an understanding of their individual circumstances.

Good luck and let me know what you think in the comments!