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.