About half of my clients give their prospective hires a take-home technical test to complete. When I was searching for work, and when I was personally hiring, I dealt with these a lot. I can’t give my individual candidates feedback on their tests before I forward them on to clients – which is frustrating – but I think I can probably publish this short checklist and point people at it!
1. Use a linter
A linter looks for strange and inconsistent style in your code, and tries to find errors via static analysis of the code. If you run a linter over your codebase, it’ll probably come back with a bunch of crap you don’t care about, but in a situation (like a take-home tech test) where you can’t ask someone to code-review your code, it’s a useful tool.
- You don’t have to blindly follow what it finds, but you should be aware of everything it doesn’t like about your code
- It’ll catch stupid mistakes that we all make, but are easy to miss
- Try and make sure you understand everything it’s complaining about, because an interviewer might well complain about it too
- Running your code through a sensibly-configured beautifier (that changes the layout of your code) probably can’t hurt either
2. Check for detritus in your submission tarball
- Presence of .DS_Store, ~myfile.js, myfile.js.swp, etc files just make you look sloppy
- Have you been asked to commit your work to a repository? Are you submitting the .git directory too? Check git log doesn’t look terrible, and consider fixing up your commits in a way that you think would reflect best practices
3. Double-check your dependencies
4. Ensure your tests work, and run clean
- You should probably have tests
- You should make sure it’s very obvious how to run these tests – if nothing else, a README.md that states very simply how to do it
- Make sure they’re not generating weird warnings or artifacts that you aren’t catching
- Remove any auto-generated tests you didn’t write yourself, say those generated by a framework
- Doubly so if they’re not actually testing anything
5. Understand what all your code does
- You should really know what all the lines in your code are doing
- Any copy-and-paste jobs from StackOverflow you need to make sure you completely understand, or you’ll look stupid when a technical interviewer asks you about them
- Unless you’re applying for a Junior role, you should have at least a rough understanding of how the frameworks you’re using are implemented
6. Make your code robust
- Is there user-provided input at some point? Is your code easily broken by bad input?
- Does your code degrade nicely with edge-cases?
- SQL injections?
- Can the user create a security issue by passing you HTML where you expect something else?
- Do you need to consider text encoding? Have you done?
7. Bite off only as much as you can chew
- Aim to do a small amount of the test well, rather than attempting to boil the ocean and running out of time. Well-presented, thought-out, commented and tested code that completes 3 of the 4 set tasks is often better received than the trappings of a new framework you’ve started building to solve all the problems they might ever encounter
- Many tests set an unrealistically short time-frame to complete all the tasks