Checklist for a Take-Home Tech Test

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

Get a job you love now!

We'll help you find your perfect role!
1  
Enter your email address so we know how to get in touch.
You're not signing up for a mailing list and I'll only use this email address to personally email you. No commitment required.
2  
We'll ask you some follow-up questions, and you can upload your CV or resume if you have one
3  
All set! We'll get back to you in one working day with some jobs we think would be a great match for your skillset.