PrepCrew

Project's architecture
Resume Check 1/2
Resume Check 2/2
Resume Tailoring

Inspiration

Building a project and explaining why it breaks are different skills. A student can ship a working embedded or server project, then freeze when an interviewer asks, "Why is this failing?" Most prep tools hand them another list of questions. What they need is a coach who watches how they investigate, finds exactly where the reasoning stalls, and turns that moment into practice.

AI runs on physical infrastructure: power, servers, chips and the systems that connect them. More CS and computer engineering students are aiming at roles near that stack, and those interviews reward reasoning across the hardware and software boundary. Students with an engineer in the family can get that coaching. We wanted it to depend less on who you already know.

What it does

PrepCrew is an interview gym for hardware and infrastructure roles. It closes a loop that most practice tools leave open:

Investigate. You debug a simulated Raspberry Pi server through five stages, from reading the first error to checking power, with Dana, our AI interviewer, beside you. Your terminal commands, edits and explanations are saved as separate evidence. You can also whiteboard a system design and get an annotated critique.
Review. Evaluators grade the session, and every claim has to cite something you actually did or said. We check each quote against your session, and a second review rejects judgments the evidence doesn't support.
Learn. A verified gap opens a short AI-generated lesson on exactly that concept.
Retest. You get a changed task, with a different port, directory or log setup. It tests the same skill, so repeating the same command isn't enough.
Remember. In your next session, Dana can open from the gap your last one revealed.

Where we are today. The Pi, its commands and its timings are simulated, and it isn't a real shell, real hardware or a copy of a real interview. Our rubrics haven't been calibrated by human engineers yet, so treat the feedback as practice guidance. We have no tester outcome data, so we make no claim about how much students improve. Typing always works. [Update before submitting: state whether cloud voice and the local speech fallback passed their final check.]

How we built it

The frontend is a React and TypeScript workspace over a FastAPI backend. Every action in a session (a terminal command, a spoken or typed turn, a whiteboard stroke) is stored as an ordered event in Tiger Data, using Postgres with TimescaleDB, with continuous aggregates for mastery and latency.

A deterministic engine produces the Pi's output, so the model can never invent what a command returned, and each task variant is checked against a reference solution. Gemini runs through audited jobs to write plans, Dana's replies, whiteboard critiques, evaluations and lessons. Local checks verify every evidence quote against the exact candidate event, session and step. A separate model review then decides whether that quote supports the judgment. Nothing publishes if either check fails.

Backboard helps rank remembered gaps across sessions, but the app only recalls text it has verified locally. ElevenLabs provides streaming speech in and out, Three.js drives the 3D Pi view, and accounts use Argon2id password hashing with ownership checks on every request.

Challenges we ran into

The hard part was deciding what counts as evidence. Drawing a box doesn't prove a design scales, and quoting a student doesn't prove an interpretation is fair. We separated what a student did from what we conclude about their ability, and made rejection and retry part of the flow.

Speech provider quotas, model availability and cross-device reconnects pushed us to narrow the demo to one loop we could make dependable. We also had to reconcile two generations of the codebase, a legacy interviewer and a newer session engine, and decide which paths were safe to show.

Accomplishments that we're proud of

A playable, saved Pi investigation with five checked stages, where a changed retest keeps the same rubric but alters the fault.
An assessment path that rejects unsupported evidence instead of publishing every model answer as a result.
One connected loop from a verified gap to a lesson to a retest, with memory feeding the next session.
Talking, drawing and doing in the same saved session, with accounts and history that persist across devices.
Resume reviewing and tailoring for any and all job postings.

What we learned

Validity has layers. A reference check on the simulator, a quote check, a model's interpretation and a human's judgment each answer a different question, and none of them replaces the others. We also learned that one dependable learning loop beats a wide catalog of tracks that only look playable.

What's next for PrepCrew

Calibrate the rubrics with practicing engineers, then run a consented pilot with a campus engineering organization and measure retest gains on held-out tasks. After that, we'll add constrained drill generation that validates every exercise before you play it, a circuit and embedded engine, behavioral interview practice, and networking labs, each only once it has evidence rules we trust.