<aside> 💡 Before delivering a take-home to a company, we recommend you submit it for light review to Gabriel Benmergui on Git Hub (username: conanbatt).

</aside>

♟️ Interviewer Experience

The key to a great take-home is focusing on the interviewer's experience.

Companies that choose to use take-homes do so to save engineering time. Live coding interviewing takes a toll on engineers and reduces the number of candidates you can evaluate per unit of time. By providing a take-home, they filter out people for commitment (the time required to do the take-home filters out a large pool of candidates) and allow for async/faster evaluation of candidates.

As take-homes are used to filter and make the workload easier, making it easy for the interviewer to review your submission is key. Your submission is very easily comparable with other submissions, so being the easiest to evaluate will give you an edge.

<aside> 💡 It is easier to reject a take-home than to appreciate valuable contributions. A take-home with a fantastic solution but a glaring bug is a reject. Your take-home must be polished not to give the interviewer any reason to say no

</aside>

✅ Interviewer Experience Checklist

• Stack Choice
  • Choose the stack that is most up-to-date and closest to the client as possible.
  • If you choose a different stack, your interviewer might NOT be able to evaluate it thoroughly or compare it with other submissions
  • It would help if you always built it with the latest tooling/frameworks however experimental. Learn them if you must, showing your capacity and propensity to learn. If you deliver a submission with a stack older than the company uses, you look outdated.
• Git history
  • [MUST] Separate boilerplate code from your original contributions.
  • Chunk your work into reasonable commits - a legible and GitHub-navigable history looks professional
  • Make informative commit comments (avoid “fixed this, worked this, improved this”)
• Easy to try
  • If applicable, deploy the project so the interviewer can test it without installing anything, or can use it with a phone
• Documentation
  • [MUST] Instructions to run the project and test it. Make sure the instructions work from scratch.
  • If the interviewer follows the documentation and encounters a build or running issue you will be rejected.
  • Add use cases or test cases - tell the interviewer what they should do or check to see your program and make sure the steps work smoothly. We want to avoid the interviewer entering into guessing or bug-fixing mode - those are cognitively expensive.
  • Sr. Developers are expected to show judgment and experience. Mention different technical choices that were made and explain them. Why choose one library over the other? What were some of the non-trivial decisions made and why?
• NO BUGS
  • Any bug is enough for immediate rejection. Finding a reason to say no is easier than finding an exceptional delivery, and bugs instantly put your delivered material behind other submissions.
• Conform to requirements
  • Both technical and product requirements must be strictly met.
  • Need to include details or instructions. Any other submission that conforms to requirements perfectly will win by default.
  • Triple-check requirements and ensure submission fits perfectly
• Speed of delivery
  • Some takehomes have time limits and some others don’t. The reality is that the speed of delivery is a huge signal for capacity.
  • The practical approach is to complete a take-home within a weekend or 7 working days.
  • ❗ Cutting corners because “it’s good enough” is a surefire way to put your delivery in the reject pile. The best candidates do not do this.
• Testing Code
  • Some interviewers will penalize submissions without testing the code. You may want to ask what the expectations are for your particular submissions to ensure the right amount of coverage.
  • At the very least, writing 0-1 tests to showcase your willingness and capacity to write testing code is recommended. It is always easier to add tests than to write the first ones.