FDE Project Trainer — Think Like an FDE

Problem

Most FDE interview prep drills technical trivia, but the job's hard part is judgment — deciding whether a project should exist, what number will actually improve, when to recommend NOT building, and where to keep a human in the loop. Candidates have no easy way to practise that reasoning against real-shaped projects, or to see the RANGE of defensible answers instead of memorising one.

Constraint

The output has to model how an FDE actually thinks — outcomes before technology, scope shrunk until the number is defensible, an explicit never-touch list, humans in the loop where errors are costly — not vendor-speak that promises to "ensure quality". And it had to run for free for candidates with no budget, on shared community models that are slow and occasionally reject requests, without ever pretending the answers are authoritative.

Architecture decision

A browser-first React app that makes four sequential model calls — one per tier — instead of one giant call, so partial results stream in, a failed tier retries on its own, and each later call is fed a compact summary of the earlier tiers (so the economics can reference the outcome number). A small Node/Express proxy holds the shared key server-side behind a three-model allowlist and a per-IP rate limit, so no key is ever shipped to the browser; own-key mode calls OpenRouter directly and unlocks any model, including Claude. Rejected — JSON response-format mode (several free models reject it, so a JSON-only system prompt plus fence-stripping and a single parse-retry do the job), a database or accounts (state lives in React), and paid models as the default.

Notes

Interview prep for the role usually rehearses the wrong muscle. The FDE difficulty isn’t recalling an algorithm — it’s the sequence of judgments before any code exists: should this be built at all, what does “done” mean in a number, and what must the system never touch.

So this tool asks you to describe a project — a support-ticket copilot, invoice automation, an on-prem drilling-reports assistant — and answers it back the way an FDE would, across four tiers of reasoning:

Is this worth doing? — the business, the one metric that moves, and the economics (including when to recommend not building).
Can it be built? — data reality, where the system fits and what it never touches, what it remembers, and day-to-day model ops.
How will we deliver? — the smallest end-to-end slice, the test harness with a zero-tolerance failure class, and quantified acceptance criteria.
Will it survive the real world? — the stakeholders who can kill it, and the worst credible production incident plus its kill switch.

Every one of the twelve parameters comes back with 2–3 differently-framed answers, each labelled with the angle it takes — “pick a clear number”, “cost of doing nothing”, “shrink the scope” — because the point isn’t a single right answer; it’s learning the shape of a defensible one.

Two ways to run it: on curated free models with no key (a shared server-side key, capped to three free models), or on your own OpenRouter key with any model you like for sharper output. Either way the tool tells you exactly which model produced each tier.

The method it’s teaching is written up here: What a forward deployed engineer actually does.

Live demo

Open demo ↗https://fde-project-trainer.onrender.com

Still unfinished

Free models are slow (~100s per tier) and the free web service cold-starts after about 15 minutes idle (~30–50s on the first request); heavy use can hit the shared rate limit. Bring your own OpenRouter key and pick a stronger model for fast, sharp output.
A Coaching and Grading mode — paste your own answer to a parameter and get graded against the FDE rubric — is stubbed in the UI, not built yet.
Responses occasionally run a sentence past the 2–4 sentence target; this is a study aid to train instincts, not authoritative project advice.