STAR+R: The Interview-Prep Format I Built Into My Job-Search Tool

If I had to name the one stage of a job search where AI is unambiguously, boringly good, it is interview prep. Not the flashy part -- not the tools that promise to whisper answers into your ear mid-call -- but the unglamorous work of rehearsing until you are calm and sharp. I know this because I built a job-search system, career-ops, that treats interview prep as an engineering problem, and the interview module is the one piece I trust the most.

career-ops is an open-source command center that turns an AI coding CLI into a pipeline: paste a job URL, and it runs a fit evaluation, generates a tailored CV, and -- the part this post is about -- produces interview stories tuned to that specific role. It is deliberately a filter, not a spam cannon: it recommends against applying below 3.5 out of 5, on the theory that a recruiter's attention is worth respecting. Everything I describe below is a design decision I actually made and can point to in the repo, not a feature I wish existed.

Why interviews are an AI-friendly problem

Most of the job search resists automation because the thing that matters -- judgment, fit, taste -- is exactly what models lack. Interview prep is the exception, because prep is not the judgment call; it is the rehearsal before it. And rehearsal has every property a model is good at: it is repeatable, it has a clear shape, and the feedback is cheap to give and immediately useful. You can practice the same answer ten times and get a critique on each pass -- something no busy friend will ever do for you.

When I designed the evaluation engine, I leaned into that structure. The system does not keyword-match a job description against your resume. It first classifies every posting into one of six role archetypes -- AI Platform/LLMOps, Agentic/Automation, Technical AI PM, AI Solutions Architect, AI Forward-Deployed, and AI Transformation -- each detected from signal words in the JD. That archetype then drives everything downstream: which proof points get surfaced, how the CV gets rewritten, and, critically, which interview stories get pulled to the top.

# One archetype block drives which stories get pulled from the bank.
# Detected from signal words in the JD, not keyword-matched.
ARCHETYPES = {
  "ai_platform_llmops":   ["inference", "eval", "serving", "latency", "guardrails"],
  "agentic_automation":   ["agent", "workflow", "orchestration", "tool use"],
  "technical_ai_pm":      ["roadmap", "prioritize", "stakeholder", "spec"],
  "ai_solutions_arch":    ["integration", "customer", "architecture", "POC"],
  "ai_forward_deployed":  ["deploy", "on-site", "field", "implementation"],
  "ai_transformation":    ["change management", "adoption", "org", "enablement"],
}

def pick_stories(archetype, story_bank):
    # Same bank, reordered per archetype so the top 2-3 always fit the room.
    return sorted(story_bank, key=lambda s: relevance(s, archetype), reverse=True)[:3]

The important design idea here is that the archetype is not cosmetic. A LLMOps interview and a Transformation interview reward completely different stories from the same career. Rather than keep six separate story sets, I keep one bank and reorder it per role. Which brings me to the format those stories are stored in -- the piece I am proudest of.

STAR is not enough: the Reflection column

Everyone knows STAR -- Situation, Task, Action, Result. It is the default scaffold for behavioral answers, and it works: it forces you to end on a concrete outcome instead of trailing off into 'and it went well. ' But when I started generating STAR stories at volume, I noticed they all sounded the same, and none of them sounded senior. They described what happened. They did not show that the person had learned anything from it.

So the interview-prep output in career-ops uses a format I call STAR+R: standard STAR plus a mandatory Reflection line. The rule baked into the mode file is blunt -- junior candidates describe what happened, senior candidates extract the lesson. The Reflection line is where you say what you would do differently, what the experience taught you about the tradeoff, or the general principle you carried forward. It is the single field that most reliably separates a story that impresses an interviewer from one that merely answers the question.

Junior candidates describe what happened. Senior candidates extract the lesson. The Reflection line is where that difference lives.

Here is roughly what one of these stories looks like when the system writes it into the story bank. Notice that the Reflection is not a summary of the Result -- it is a level up, a claim about how you think.

## interview-prep/story-bank.md

### Story 3 -- "Killed the ghost-job false positives"
| | |
|---|---|
| Situation | Scanner kept surfacing dead postings that still had a nav-bar "Apply" link. |
| Task      | Make liveness detection trust expired banners over generic Apply text. |
| Action    | Reordered the classifier so expired signals win; added a bot-challenge guard. |
| Result    | Dead postings stopped leaking into the inbox; live jobs stopped getting blacklisted. |
| Reflection| A "signal" is only useful once you decide which signal wins when two disagree. |

That example is a real one from my own build log -- the moment I discovered that a nav-bar 'Apply' link was making dead job postings look alive, and had to decide which signal wins when two disagree. The Result is the fix. The Reflection is the transferable lesson, and that is the part an interviewer actually remembers.

The story bank: write once, reuse everywhere

The second design decision that changed how well the tool works: stories accumulate. Every time career-ops evaluates a new offer, any STAR+R stories it generates get appended to a single file, interview-prep/story-bank. md. Over a job search, that file converges on a small set of 5-to-10 master stories -- the ones drawn from your strongest work, refined a little more each time they come up.

This matters more than it sounds. The failure mode of interview prep is treating every interview as a blank page and re-inventing your narrative from scratch at 11pm the night before. A story bank inverts that. By your third or fourth interview you are not writing -- you are selecting. The archetype classifier picks the two or three stories that fit this specific room, and you rehearse those. The compounding is the whole point: the work you do prepping for company A makes company B cheaper.

A few things I learned wiring this up that are worth stealing even if you never touch my code:

• Store stories in one file, not per-company folders. The reuse only happens if the bank is a single place you actually revisit.
• Make the Reflection mandatory, not optional. Optional fields get skipped, and the Reflection is the field that carries the seniority signal.
• Tag each story by which archetype it serves, so selection is mechanical instead of a fresh judgment call under pressure.
• End every Result on a concrete number or outcome. 'Improved performance' is not a result; 'cut false-positive dead postings to near zero' is.

What is actually theater

The same category that delivers real value is full of tools selling shortcuts, and I want to be clear about which ones I deliberately did not build. career-ops never whispers live answers, never 'takes the interview for you,' and never emits a vanity score on your delivery. Those are the three most common AI-interview features, and all three are traps.

1. Real-time interview copilots that feed you live answers. They are increasingly detected, disqualifying when caught, and even when they are not, you have talked your way into a job you cannot do.
2. Generic question banks with no feedback. A list of 200 questions you will never rehearse is procrastination dressed as preparation.
3. Vanity scores. 'Our AI rated your answer 88 percent. ' A number with no specific, actionable note attached tells you nothing.

I made the same call at the fit-scoring layer, for the record: the system's ghost-job detector grades a posting's legitimacy in a separate qualitative tier and is forbidden from touching the numeric fit score, precisely so a single number never pretends to mean more than it does. A score is a starting point for a decision, never a verdict. The same discipline applies to interview feedback -- it should be specific and unsentimental, not a percentage.

A prep loop you can run this week

You do not need my repo to get most of this. You need one capable model and a few focused passes, run in the right order:

1. Classify the role. Read the job description and name what kind of role it really is -- platform, product, solutions, transformation. This decides which of your stories matter.
2. Generate the question set. Paste the JD and your resume and ask for the fifteen most likely questions, behavioral and technical, for that archetype.
3. Build STAR+R stories. Draft an answer for each behavioral question -- and force yourself to write the Reflection line, the lesson, not just the result.
4. Mock it out loud. Have the model run a realistic interview, one question at a time with follow-ups, and answer by speaking, not typing.
5. Bank the winners. Save the three or four strongest stories somewhere reusable. Next interview, you select instead of writing.
6. Repeat until you are bored. Boredom means it is automatic, and automatic is what holds up when the nerves hit.

None of this walks into the room for you. A model cannot read the interviewer's face, build rapport in the first thirty seconds, or make the call about whether you even want the job once you are sitting in it. Nerves, chemistry, and presence are still yours to carry. But that is the right division of labor: the tool handles the rehearsal so you arrive prepared, loose, and out of excuses -- and you handle the conversation, which was always the only part that counted. Building career-ops taught me that the trick is not a smarter answer generator. It is a Reflection line and a story bank, and the discipline to reuse both.