<aside> <img src="/icons/briefcase_blue.svg" alt="/icons/briefcase_blue.svg" width="40px" /> This is Part 10 of the Just Enough Prep Guide. This workbook will explain why hiring managers request ‘homework problems’ and how you can use them to showcase your skillsets.

</aside>

“Homework” problems are increasingly popular as being closer to real work than single-function problems.

The features of homework problems

Typically the features of such problems are:

• A standard time limit, usually not more than a few days.
• That time-limit clock starts at a time that you specify
  • so the clock begins fairly, in a timeframe when you can work around personal or day-job commitments.
• A project specification is handed to you at that time.
• Often within that spec are constraints on the technologies you can use.
• Sometimes you are given a starter skeleton codebase to work from.

Some pitfalls to avoid

First let’s consider how many, many engineers end up crashing and burning on this problem genre.

• Encountering vague parts of the spec and just guessing what they mean without at least asking.
• When asking such questions, not framing them with enough context to make them easy for your company point-of-contact to answer.
• Writing code or tests very slowly because at your day job you are used to just copy-pasting starter chunks from elsewhere in your production codebase(s).
• Otherwise spending precious time looking up / recalling how to do basic things with your tools.
  • Nothing’s wrong with looking things up, but at a certain point it will eat up too much of your time-limited time. Find the balance that works for you.
• Writing code or tests very slowly because you are experimenting with:
  • a new language (if given your choice of language)
  • a new framework
  • a new IDE
  • a new keyboard layout (e.g., Dvorak)
  • ^^^ yes, maybe hard to believe, but we have seen all of these occur even in live interviews(!)
• Otherwise spending precious time on environment setup.
• Similarly, spending precious time exploring which tools / libraries / frameworks you want to use.
• Not implementing, at minimum, exactly to the spec.
  • (It’s impressive — albeit usually unnecessary — to implement bonus features, but at least it needs to match the spec).