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 perlcritic
- 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 like forgetting to turn use strict; and use warnings;
- Try and make sure you understand everything it’s complaining about, because an interviewer might well complain about it too
- A sensibly configured perltidy run probably won’t hurt either
2. Check for detritus in your submission tarball
- Presence of .DS_Store, ~myfile.pl, myfile.pl.swp, etc files just make you look sloppy
- Are you submitting the .git directory too? Check git log doesn’t look terrible
3. Remove auto-generated and boilerplate POD and code
- You get no points for your modules having the Module Starter POD in them
- You’ll probably disappoint someone who’s expecting it to be well-documented and then finds the alleged POD is just cruft
4. Double-check your dependencies
- Use a cpanfile unless you have a good reason not to
- Quick ways to check dependencies:
- Using perlbrew switch to a new Perl you’ve not used before that has no modules installed
- Upload your work to GitHub, and see if it smokes on Travis-CI
5. Ensure your tests work, and run clean
- prove –r t/ should just work and pass
- Nothing to STDERR – warnings or diag() output
- note() is more appropriate for general non-failure output from your tests
- Remove any auto-generated tests you didn’t write yourself
- Doubly so if they’re not actually testing anything
- Do you really need an xt/ directory? Probably not
6. Understand what all your code does
- You should really know what all the lines in your code are doing
- If you have: PACKAGE->meta->make_immutable
- … make sure you know what PACKAGE returns
- … make sure you know what ->meta() returns
- … make sure you know what ->make_immutable() does
- If you’ve used DBIx::Class’s search and search_rs make sure you know the difference
7. 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?
- Use placeholders for SQL
- Can the user create a security issue by passing you HTML where you expect something else?
- Do you need to consider encodings? Have you done?
8. Avoid hipster modules
- Modules the reviewer hasn’t seen before are more likely to elicit a response of WTF? rather than admiration…
- If you’re going to use strictures 2; you should probably explain – at length and in comments – what it is and why you used it
9. 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
- Most tests set an unrealistically short time-frame to complete all the tasks