Skip to content

How it’s built

One template, a tailored simulation per job posting

1. Problem

A résumé that reads "customer support" gets filtered out before anyone tests the judgment behind it. And a single generic portfolio doesn’t convince a specific hiring manager — they want to see that you understand their role, not ops in the abstract.

2. Solution

For each target job, a working simulation of that exact role, built from the posting: its requirements are mapped to a real task the recruiter can play, with a competency report and transparent reasoning at the end. Currently live:

  • NETGEAR — Level 2 Technical Support Engineer
  • tQCS — Associate Consultant (PM / Business Development)

3. System design — config, not copies

The engine, console UI, scoring, and report are shared. Each company is a single config file that declares its identity, accent, KPIs, queue, requirements→proof map, role-specific competencies, and a tailored task. Adding a company = one file + one line. Everything ships in a single deploy; per-company links (/apply/<slug>) are focused, so a recruiter only ever sees their own company — never that you’re applying elsewhere. A private control panel lets the candidate toggle which targets are active when presenting.

4. Data model

  • Company — identity, accent theme, JD-derived requirements→proof map, KPIs, a domain work-queue, and a side panel.
  • Dimensions — role-specific weighted competencies (e.g. NETGEAR: Troubleshooting Methodology; tQCS: Tech→Business Translation).
  • Scenario → Steps — choice / routing / report steps, each with options carrying per-dimension scores and a model "how I’d handle it" with trade-offs.

5. Scenario engine

A step-based state machine reproduces what makes the job hard: time pressure (live clocks), incomplete information (an "Assist" that suggests but never decides), and irreversible, locked-in calls. Every important decision requires a written why — that reasoning is the real evidence — and routing steps make you choose the correct people to involve, scored against the right set.

6. Scoring

A deterministic, weighted rubric over each role’s own competencies — same input, same score, so it’s defensible in an interview. The score grades the player (the recruiter), proving the task is realistic; the candidate’s evidence is the recorded reasoning and trade-offs.

7. AI design

AI is an assistant, not the decision-maker. An optional review (DeepSeek via a Cloudflare Pages Function) comments only on the written deliverable; the deterministic engine stays the source of truth, and if the API is unavailable a local fallback keeps the demo working in front of a recruiter.

8. Edge cases

  • • Per-company session recovery (localStorage, isolated by slug).
  • • AI failure → local fallback review.
  • • No-login; focused per-company links that don’t leak other applications.
  • • Accessibility: keyboard nav, focus rings, reduced-motion; responsive on mobile.

9. Result

A scalable way to walk into every application having already "done the job" — and to hand the recruiter a 3-minute proof tailored to their exact posting.