There have been whole books written about how to do well on algorithms-based whiteboard interviews, and places where candidates can practice. However, as companies like Slack , ThoughtWorks, and The Long-Term Stock Exchange move to at-home coding exercises in place of whiteboard coding, interviews call on a whole new set of skills. Take home exercises take many forms, and vary by role, but there are some commonalities.
The point of a coding exercise, unlike an algorithm question, is not necessarily to write optimal code. This may seem counterintuitive, but remember that ~80% of programming effort is maintenance: if people are bothering to look at what you can do on your own, it is because they want to see what it is going to be like to work with code that you write. This does not mean you should over-engineer or try to show off and look clever, but the code you submit should be something you can be proud of. You want people to look at your code and see an invitation to collaborate. If it happens to be an optimal solution, that’s bonus, but as an engineer my goal with a coding exercise is to be Hannelore brewing Bubbles tea:
Furthermore, the assignment is just as much an opportunity for you to try out working with them as it is for them to interview you. Assuming you have the freedom to be picky about where you work, write code that people you would want to work with will like. If the work is boring or frustrating or outside your skill set, give the interviewer that feedback; it is a sign that the position may not be a good fit. Whatever strong opinions you have that are relevant, use them loudly and see if the reviewer objects. If you want to work with a particular language, use it. Personally, I throw in a single line method that exists just to have a communicative name. If that’s not going to work for the reviewers, I probably wouldn’t be happy in that job.
The dream, of course, is that you work cleanly, neatly and carefully every day, but even if you do it is easy for those good habits to fail under the extra pressure of an interview. It’s important to take deep breaths and get on with this work as you would any other. Trust that your skills as you usually practice them will be good enough to get the job; it turns out that even if they aren’t, getting more stressed isn’t going to help. These interviews are administered by programmers, and their expectations are going to be realistic. There is no single pass/fail metric here, no magical answer to be memorized, no evaluation of whether you are “smart” or not: these tests exist simply to evaluate whether your skills are a match for the position at hand.
That said, if you want to absolutely shine there are a couple of easy things you can do:
1. Have an environment ready to go. If you are a front end developer, that means having already picked a stack and having a boilerplate or creation script you are comfortable running. If you are a backend developer, that means having your IDE set up to create a new project with minimum of fuss and all your favorite settings. Be sure to have your linting in place too: consistency is visually pleasing and it demonstrates that you know the value of standardization. You can also have a README ready to go with any necessary setup instructions. Having all of this prepared before you get to this stage of an interview will significantly reduce the length of time required to do each exercise, and it is especially important for the next point.
2. Write tests. You would not believe how many people talk about the importance of testing in a phone interview and then return code that have zero tests when given the opportunity to code. If you don’t practice TDD a coding test probably isn’t a great time to start and you don’t need 100% test coverage by any means, but at least unit test whatever the central object or function you build. If you have time to encode the directives they’ve given you in acceptance tests all the better, but even a single passing test is better than none. This can also give you confidence that the code you are submitting is correct.
3. Use a paradigm. Object-Orientation or Functional Programming or both, it doesn’t matter, but the one thing readers will be able to see at a glance is how you encapsulate data and functionality. Even if the problem is small and you could solve it without architecture, take the time to refactor, making the code as simple and easy to read as possible.
4. Communicate! Let the interviewer know about any assumptions you are making, ask about things that don’t make sense, provide updates as you cruise along. This is a chance to demonstrate how effectively you collaborate when working on a product and how easy you are to work with. Don’t go overboard or make up excuses just to email, but if a question comes up don’t feel like you need to answer it yourself: reach out! This is also the best solution if you feel like an exercise is overwhelming or becoming a massive time sink. That might be a sign that that’s what the day-to-day work would be like for you, but it might also be that you misread the expectations. I recommend sharing your work in progress and getting guidance on how to proceed, rather than continuing to plug away, and risk becoming more resentful by the hour.
5. Handle Edge Cases. These are easy and relatively objective for evaluators to check, which makes them a frequently-evaluated criteria. Verify that the program as a whole at least fails gracefully if given no input, negative input or invalid input.
6. Provide a README. This is a chance to demonstrate your documentation skills: be concise and clear. Include the problem description, any assumptions you have made, how to run the program and how to run the tests you wrote. If you can, try running the program on another computer following the steps to make sure it wasn’t relying on something you have set up on your home machine.
EXTRA BONUS AWESOME: Use meaningful version control commits. This one is a bonus hit-it-out-of-the-park kind of thing, but as a reviewer if I can see how a candidate’s code grew and evolved, that they iteratively added functionality to satisfy each of the requirements in turn, and their commit messages guide me through the journey they took, I am over the moon. It also lets you perform code reviews for yourself as you go. You can stop and ask yourself, “what would I say if someone sent me this review?”
If you want to do more preparation there’s no Cracking The Coding Take-Home book (yet), but reading a book like Implementation Patterns, Refactoring or 99 Bottles can be a good way to get a sense for what interviewers are likely to be looking for. Techniques like variable names, symmetry and delegation are important in take homes in a way they aren’t on a whiteboard. You can also consider spending some time reading code in your preferred language, especially if the company you are interviewing at has open source repositories. That will give you a sense of what this company values in particular, beyond the generally good ideas these books document.
If you’d be interested in taking a crack at The Long-Term Stock Exchange’s take home exercise, we are hiring. Reach out to careers@ltse.com!
