Skip to content

Instantly share code, notes, and snippets.

@joejag

joejag/marking.md

Last active August 4, 2020 02:03
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save joejag/7b02a3e169e869061c3d76c1d20902f7 to your computer and use it in GitHub Desktop.
Save joejag/7b02a3e169e869061c3d76c1d20902f7 to your computer and use it in GitHub Desktop.
Download ZIP
Example of how to mark a technical test
Raw
marking.md

Tech Test Marking Guide

For a given test exercise.

Out of 22 points.

  1. It works: The code implements the specification (8 points, meets spec is 8 - reduce the score for missing parts or bugs found)

  2. The code is easy to read (4 points)

  • Method names are self-describing and show intent (i.e. not misleading)
  • Comments, if any, say why rather than how
  • Methods are short
  • Clear control flow (i.e you can follow what it is doing)
  1. It's tested (4 points)
  • Test names are explanatory
  • Expected test cases are present
  • Tests are explicit (i.e. it is obvious what they do and not over 15+ lines per test method)
  • The tests are logical (i.e. makes sense that they are there)
  1. It's maintainable and robust (4 points)
  • No dead code
  • defensive at the system boundries (e.g. user input, api boundries)
  • Modularised (e.g. follows Single Responsibility Pattern)
  • Can be built and ran in one step
  1. The write up (a README.md) is complete (2 points)
  • It mentions how to run the application
  • There is some reasoning about tradeoffs made while writing the application.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment