Skill library

Skill library
HRConfidentialskills/hr/candidate-tests/SKILL.md

Candidate Tests

Standardised practical tests per role with a 1-5 rubric and explicit pass criteria. Outputs feed directly into the interview decision.

Candidate Tests

Every role at Media Tech has a standardised practical test. The test is not a hazing ritual or a substitute for interviewing — it is a focused, time-boxed assessment of the work the role actually does, scored against a rubric we agreed on before the candidate sat down.

The point of standardising the test is to compare candidates fairly across cycles, not just within a single hire. We hire from a small pool, and being able to look at last year's Backend test scores against this year's is more useful than retroactively comparing live interview impressions.

Format

  • Duration. 60–90 minutes for individual-contributor roles; up to 2 hours for senior or lead roles.
  • Setting. Remote, asynchronous. Candidate downloads the test pack, completes it within the time window (we trust the time-box), submits via a dedicated upload link.
  • Disclosure. Candidate is told the rubric in advance. We are not catching anyone out.
  • AI use. Permitted. We hire people who work with the tools we work with. The test is scored on the quality of the output and the candidate's ability to explain their decisions in the follow-up interview.

Scoring — 1-5 rubric

Every test has between 4 and 8 scoring categories specific to the role. Each category is scored on a 1–5 scale:

  • 5 — Exceptional. Better than the average current team member.
  • 4 — Strong. Meets the bar, demonstrates judgement, would ship this.
  • 3 — Adequate. Acceptable, but with caveats. Needs review before going to production.
  • 2 — Weak. Below the bar; visible gaps in core skills.
  • 1 — Concerning. Misunderstands the prompt or produces work that would fail review.

Each test additionally identifies key risk areas — the categories that, if scored low, would predict job failure even if the average is high. For Backend, that's data modelling and security. For Frontend, it's accessibility and platform-specific UX. For QA, it's defect-report clarity.

Pass criteria

A candidate passes the test stage when all three conditions are met:

  1. Average score ≥ 4.0 across all categories.
  2. No category scored < 3.0 — a single weak category is disqualifying even if the average is strong.
  3. All key risk areas scored ≥ 4.0 — risk-area weakness is disqualifying regardless of the rest.

Passing the test is necessary but not sufficient. The decision to extend an offer happens after the main interview (hr/interview-templates).

Tests per role

Backend Developer

Build a small Laravel endpoint that ingests a webhook from a fictitious vendor (provided OpenAPI spec), validates the payload, persists it to Postgres, enqueues a job to call an external API, and emits a Pusher event. Scoring categories: data modelling, request validation, error handling, queue design, security (key risk), observability (key risk), code clarity, test coverage.

Frontend Developer

Implement a SPYN-style diary list screen in React Native from a provided Figma frame. The screen must support pull-to-refresh, infinite scroll, and one empty state. Scoring categories: visual fidelity, accessibility (key risk), platform UX (key risk — iOS and Android), component decomposition, state management, performance with 500 items, test coverage.

Full-Stack Developer

Same Backend test plus the Frontend list screen consuming the endpoint they built. Scoring categories: combined Backend + Frontend categories, plus systems thinking (key risk — does the architecture make sense end-to-end), plus deployment readiness.

QA Tester

A SPYN feature spec is provided; the candidate writes a functional test plan following the Welcome Screen pattern (developer/test-cases-functional). They then test a deliberately buggy build and submit defect reports. Scoring categories: checklist completeness, edge-case coverage, language coverage, defect-report clarity (key risk), reproduction-step specificity, severity judgement.

Designer

Redesign one existing SPYN screen end-to-end. Deliverables: research justification (one page), redesigned screen in Figma at three breakpoints, motion spec, accessibility annotations. Scoring categories: research grounding, visual systems thinking (key risk), motion design, accessibility (key risk), Figma file organisation.

Project Manager / Product Owner

Write a Requirement Specification for a SPYN feature given a 90-second Loom video as the brief. Use the 10-section format. Scoring categories: section completeness, business-logic rigour, stakeholder identification (key risk), edge-case coverage, language and accessibility coverage (key risk), open-question quality.

What we don't test

  • General programming puzzles ("invert a binary tree"). They don't predict success at SPYN-shaped work.
  • Time pressure beyond the time-box. We want to see what someone can produce, not who works fastest under stress.
  • Trick questions. The test is the test; nothing is hidden.

Owned by

People Operations, with the hiring manager for each role as co-owner of that role's test.