Tips for Code Assignments

Use the programming language you’re best at

You might feel this is a good time to test a new programming language you have been learning. The problem is that using a language you don’t have real experience with will lead to mistakes. If the reviewer knows the programming language in your submission, they will quickly spot places where you don’t measure against experienced developers using that programming language.

Another reason developers do this is that they feel the need to use the programming language listed in the job posting. Ask about this ahead of time, but in my experience, great companies don’t care what programming language you use. They understand that a good developer is a good developer, and picking up a new language will not be a problem.

Run your code through tools

Take the time to run your code through formatting, static analysis, and other tools. It shows that you care about code quality, and it will catch common errors. If the person reviewing your code runs it through these tools, they will be put off immediately by warnings.

Test your code

I’m surprised by the number of developers who still don’t know about TDD or testing in general. If you’re one of them, take the time to learn it and use it on your code submission. If you are applying for any company where high-quality systems are important, tests will be a requirement. Even if they are not specified in the instructions, add them, they will make you stand out.

Make sure your submission is correct

Sometimes I get submissions that are straight-up wrong. This is because the developer forgot to test against corner cases like when the input is 0, an empty string, or something along those lines.

After making changes to your code, test everything again. A few times, candidates would make last-minute changes and forget to test running the program. There’s nothing worse than your submission crashing on the first run.

Write clear documentation

Document how to test and run the code. Add a description of your design decisions. This might be controversial, but I’m going to come right out and say it: reading three paragraphs on why you chose “dynamic algorithms” is boring. Add documentation for humans.

Even though this is something I will forgive if the code is good, it’s a place to stand out. A developer needs to communicate clearly with everyone in the company, not just other developers. Its something a lot of engineers struggle with, myself included. If you show me you are better at it than me, I want you on my team.