This time last year I was doing a lots of tests for job interviews, and I was practicing with https://adventofcode.com
I know there’s various data structures and algorithms you can learn to make these easier (and I hope to come back to some of my favourites in a later post), but there’s a general approach I take to these that helps me, and might help some of you too.
Use TDD
I’ve always been a fan of Test-Driven Development, and these type of puzzles lend themselves well to TDD thinking. Often examples are provided that will form the initial test suite. The algorithm is often broken into steps (sometimes explicitly “On every clock tick…”)
Get into the habit of checking as you go to make the most of the information provided to you. Think about the problem first, and the mapping between the input and the output, before you write any code.
Check everything on simple solutions.
Have templates
Most challenges involve a few common tasks. Read input from a file (ignoring blank lines), create a list of…, output as CSV, etc.
Some of these will have standardised patterns in your chosen language, and you should use them. Some will likely require some error handling. Some will require loading from standard or 3rd party libraries. And all will require a test framework.
As you go, build up a utilities list of functions, classes and packages that you know how to use, are robust enough and have minimal clutter. They’re not meant to be usable by anyone but you, but you will use them a lot. Collect and cherish them.
Think simple
Technical tests and coding challenges, in general, are designed to have short, easy solutions. If you need to solve P == NP to make your code fast, it’s likely you’re using an algorithm that’s a poor fit. Find 2 other ways to solve the problem, and pick the simpler one.
Simpler than that
Think about the simplest solution that could possibly work and write it simply.
Make the code readable. This is not the time for clever solutions. When it fails on an input, make it easy to change.
But not that simple
You still need to think about edge cases, and memory usage, and a myriad of other resource constraints. Think about what could go wrong, within the confines of the puzzle. Advent of Code has a particular knack for detecting edge cases in your code for Part 2 of each day’s challenge.
Think fast
Beware of premature optimisation, but expect long inputs and many loops if you use the naive implementation. Learn new algorithms and data structures.
Top comments (4)
With Python it's quite comfortable to keep it short and focus on the task. When I'm doing Java and TDD I tend to overcomplicate things I feel. Java enforces it's object orientedness on me all the way 🙈and my code gets overarchitectured with objects, classes etc. While I think, it's still good to train those concepts as well, I already thought that I want to keep it shorter and more to the point, without getting into infrastructure too much.. Thanks a lot for pointing this out again!
Totally love the TDD part for this kind of challenges! I checked out your 2018 solutions but haven't seen any unittest code 😜
I tend not to use unit test frameworks for coding challenges because I like to keep everything in one file and that's not well supported. I tend to use equality assertions in other ways, and tend to focus on testing the given examples end-to-end as that's the only requirements given.
It's a unit of work, not a unitary module. As long as each test is independent of each other, and the environment, it's a unit test.
Code templates are a fantastic idea - I already use them to save time with my documentation at work, but I hadn't considered doing the same with common development tasks. Thanks for the tips!
You're welcome.