Generating Interviews

The Generate screen lets Rubric author a complete interview package — candidate board, interviewer guide, and rubric — from a short prompt. Use it when you want a question tailored to a specific role, scale, or domain that the bundled library doesn’t cover.

This page covers when to reach for it, how to write prompts that produce useful interviews, and what happens to the generated files.

When to generate

Generate when at least one of these is true:

  • You’re interviewing for a specific role (say, “Staff Data Engineer, real-time analytics”) and the bundled library is too generic.
  • You want to vary the same problem at three difficulties for different rounds.
  • You want a refresher problem the team hasn’t seen, on short notice.

If a bundled interview already fits, use it. Generation is fast, but a hand-curated interview that’s been used a dozen times has known-good follow-ups and known calibration. Don’t generate just to generate.

The form

The Generate screen asks for five things:

  1. Role — free text. e.g., “Senior Backend Engineer”, “Staff ML Infrastructure Engineer”.
  2. App type — what the system is. e.g., “real-time leaderboard”, “feature store”, “multi-region payment ledger”.
  3. Difficulty — easy, medium, or hard. Hard interviews probe trade-offs and failure modes; easy interviews stay closer to the happy path.
  4. Cloud context — optional. AWS, GCP, Azure, or “cloud-agnostic”. This shapes the suggested services in the interviewer guide.
  5. Custom context — optional free text. Use this to bias toward (or away from) specific topics. Examples: “must explore caching trade-offs”, “candidate has no SQL background”, “focus on consistency, not throughput”.

Click Generate. The model spends a few seconds and returns three files.

Prompts that work well

The model is good at concrete, narrow inputs and weak at vague, broad ones.

BetterWorse
”Real-time leaderboard for a mobile game, ~50K writes/sec""Some kind of game backend"
"Multi-region key-value store with strong consistency in one region""Distributed database"
"Senior Data Engineer, batch + streaming hybrid""Data engineer”
Custom context: “must include a discussion of cache invalidation”Custom context: “make it good”

Treat the form like a brief, not a search box. The more specific you are, the more the generated rubric and follow-ups are tailored to what you actually want to evaluate.

What you get back

A successful generation produces:

  • candidate-board.excalidraw — the whiteboard the candidate will see, with a problem statement and any starter shapes.
  • interviewer-guide.md — the private Markdown brief: problem statement, evaluation criteria, suggested follow-up questions, red flags, and hints.
  • interview.yaml — the structured metadata and rubric, with three to five weighted categories and descriptors per score.

You can preview all three before saving.

Where it gets saved

Generated interviews are written to whichever storage backend is configured in Settings:

  • Local filesystem — files land in the directory you configured. Default for solo use.
  • Git repository — files are written and (optionally) committed to a configured repo, so you and your team share a history.
  • AWS S3 — files are written to a configured bucket. Useful when several interviewers want a shared library that’s not version-controlled.

See Storage Backends for the trade-offs.

The newly generated interview is added to your library and ready to launch right away. Its source files (board, guide, rubric) are saved to your configured storage backend, where you can also find earlier generations.

Iterating

If a generated interview isn’t quite right, regenerate with a sharper prompt — usually faster than trying to make a near-miss work. Each generation is a fresh run, so prompt deltas like “lean harder on consistency trade-offs” or “include a SQL angle” are the right way to steer it.

If you have direct filesystem access to your storage backend (e.g., the local-filesystem backend), the generated candidate-board.excalidraw, interviewer-guide.md, and interview.yaml files are plain text and can be hand-edited between generations. The interviewer guide in particular benefits from human polish once the bones are in place.