Twenty minutes, one design, and an assessor who has read it

Your instructor or admin creates your account. You receive a set-password email from the simulator; follow its link, choose a password, and you land back on the sign-in page. Sign in with that email and password.

• No email arrived? Check spam, then ask your instructor to resend it. They can do that from the admin dashboard.
• Forgot your password? Use Forgot password? on the sign-in page. A reset link goes to the same email.
• See "Create challenger account"? Only use it if your instructor told you to self-register. Otherwise sign in with the account they made, so your sessions are assigned to the right person.

Three cards. Only the first is required.

Getting a Groq key

1. Open console.groq.com/keys and sign in (free account).
2. Press Create API Key, give it a name such as flight-sim, and copy the key. It starts with gsk_ and is shown once.
3. Back in Settings, paste it into Groq API key and press Save key. The simulator checks it against Groq immediately, then stores it encrypted. It is never displayed again; Remove key deletes it.

Connecting GitHub (build scenarios on the hosted server)

Build scenarios on the hosted server work from a repo you fork and push to. Open the Workspace app: it shows the starter to fork, the clone commands, and a box for your own repo URL. Paste it once; Files then browses what you have pushed (press Refresh after each push) and grading reads your commits.

To edit in the browser instead of pushing every change: press Connect GitHub in Workspace. It shows a short code; enter it at github.com/login/device and approve. From then on the Files app edits your fork directly: every Save is a commit, and What changed shows your diff against the starter. Disconnect revokes it here (and you can revoke the app under GitHub → Settings → Applications). Pasting a token in Settings never unlocks editing; only Connect does, and the classroom's own token can never write to your repo.

Connecting GitLab (when the starter lives on your class's GitLab)

If the starter link points at your class's own GitLab, a second card appears in the Workspace app: Connect GitLab. It works the same way: a short code, approve it on the GitLab page that opens, and Files can then commit to your project. The link box accepts either a GitHub URL or a project URL on that GitLab, and the simulator works out which host to read. GitLab sign-ins expire after a couple of hours; the simulator renews them quietly in the background, and if that ever fails you just press Connect again.

Getting a GitLab token (read-only alternative)

1. On your class's GitLab open your avatar → Preferences → Access tokens (the address is /-/user_settings/personal_access_tokens). GitLab's own walkthrough is at Personal access tokens.
2. Create a token with the read_api scope. That is enough for browsing and grading; it cannot write to anything.
3. Paste it into GitLab token in Settings and press Save token. Checked against the instance, encrypted, never shown again.

Getting a GitHub token (read-only alternative)

1. Open github.com/settings/tokens. GitHub's own walkthrough is at Managing your personal access tokens.
2. Create a token. No scopes or permissions are needed: the simulator only reads public repos, the token just raises your API rate limit. A 90-day expiry is fine.
3. Paste it into GitHub token and press Save token. Same treatment as the Groq key: checked, encrypted, never shown again.

Each assigned session has an Open button. It takes you to the workstation: a desktop with a dock of apps along the bottom. The desktop's subtitle tells you which kind of scenario you are in. For an interview it reads: ask the interviewer clarifying questions, write DESIGN.md in Files, Submit it, then defend your decisions with the assessor.

The moment the session starts, the interviewer posts the problem. It is deliberately short. Each interview has its own interviewer (Sol in the parking-garage one below); the assessor is always Rowan. Here is the parking-garage brief:

Everything you need to design well is missing on purpose: how big, how fresh, what happens when sensors fail, who reads the numbers. The interviewer has those facts and will hand them over only when you ask the right question. That is the first thing you are graded on.

The interviewer answers with facts and never with architecture. Ask about scale, freshness, failure, and who consumes the output. Each good question unlocks a little more; the chat shows a signal line when that happens.

Questions that usually pay

• Scale. How many users, items, events per second? Peak versus average?
• Freshness and consistency. How stale can a read be? Does anyone need exactly-once?
• Failure. What breaks in the real world (sensors lie, networks drop, clients retry)?
• Consumers and reports. Who reads this, on what schedule, and what do they do with it?
• Non-goals. What is explicitly out of v1?

Open Files. DESIGN.md opens automatically in an editor with syntax highlighting. It already carries the section headings the assessor and grader expect; fill them in, in your own words, from the facts you extracted.

• Preview opens a live rendering beside the editor that updates as you type: headings, tables, code, and any ```mermaid block drawn as a real diagram, so you can sketch your own architecture picture. It opens by itself for DESIGN.md on a wide screen; Hide preview gives the editor the full width.
• A gold dot on the tab means unsaved changes. Save writes to your workspace; the server also keeps a copy, so a refresh or a dropped connection does not lose your work.
• What changed in the Files toolbar shows everything you have altered since the starter as a diff, one block per file, so you can check your work before you submit.
• Editor shortcuts: Ctrl+F find, Ctrl+H replace, Ctrl+B / I bold and italic, Ctrl+K a link (⌘ on a Mac). Insert diagram drops a starter mermaid block, the status bar counts your words, and the divider between editor and preview drags.
• The status line at the bottom confirms each save and shows the workspace revision.

The Tickets board is seeded with one ask: write tickets so an engineer who has only the tickets, not DESIGN.md, could implement this system. If you have time after the design, do it in TICKETS.md or as tickets on the board. Each ticket needs context, the interface or data shape, and acceptance criteria.

Extra credit is scored separately and can lift your total by up to 15 percentage points. It never lowers it. Whoever grades chooses whether to include it with the tickets extra credit toggle.

The Submit app has one button for interview scenarios. It reads DESIGN.md (and TICKETS.md if you wrote one) from your workspace as they are right now, records the submission, and draws a diagram of your architecture. The drawing appears at the top of Team Chat under Design diagram, and your instructor sees the same picture in their replay. Save first if the tab still shows a gold dot.

• You can submit again after edits; the latest submission is the one the assessor and grader read.
• "DESIGN.md is empty" means the file has no content yet. Write it in Files first.
• Telling the interviewer "I'm done" in chat is fine, but it does not submit. Only the Submit button does.

The moment the submission lands, the assessor joins Team Chat.

The assessor has read your document and the diagram drawn from it, and asks one probing question at a time about something you wrote. They do not propose a better design, teach the textbook answer, or reveal constraints you never asked about. They are checking two things: that you made the decision, and that you can defend it.

• 🔈 Voice in the Team Chat header reads each reply aloud with your browser's own voice, so an interview can feel spoken; it is off by default and remembers your choice.
• Answer from your document. "In section 4 I estimated …" is a strong opening.
• A defensible alternative is fine. "I chose X over Y because Z" beats guessing what they want.
• If you realise something is wrong, say so and say what you would change. That is graded as communication, not as failure.
• Vague answers get "point me at where your document covers that." Have it open in Files while you talk.
• Every probe you answer counts: the grader is told how many of the assessor's questions you answered and how long your answers ran, under the communication criterion. Do not leave a probe hanging.

Grading reads the whole transcript (your questions and the defense), your submitted design, the diagram, and the tickets if the toggle is on. It scores four criteria and cites evidence for each. The last grade is kept, so it is still there when you reopen the session; your instructor can regrade after reviewing the replay.

The engineer level your instructor set (intern through distinguished) changes how demanding the personas are and how the criteria are weighted. A senior-level session expects a v1 cut and explicit trade-offs; an intern-level one rewards asking and clear thinking.