Interview Method

Show up with a mockup.

Most candidates answer the interview question.
Build the answer before they ask it.
A working artifact seeded with the company’s actual problem.

The Process

Research runs through every step — from the first pass on the company through the final rehearsal with the voice agent. Each pass surfaces what the last one missed.

1
What I know
Research the company and everyone in the room, then assemble a knowledge folder and audit what you actually have.
Research. The company: what keeps the team up at night, beyond what they do. The JD is a symptom — read what it implies. The people: LinkedIn is the floor. Find their writing, their talks, what they’ve publicly tried to solve. Know what each person in the room cares about before they tell you.
Company prompts:
  • What has this company said publicly about AI in the last 12 months? Press releases, earnings calls, regulatory filings?
  • What did they just ship, and what does that tell you about what they’re building next?
  • What is the regulatory or competitive pressure forcing this role to exist right now?
  • What failure mode would this team be embarrassed by in front of their own leadership?
  • What does the JD want to see that isn’t in the title? Read the responsibilities. The requirements are the floor.
Per-person prompts:
  • What did they work on before this role? What did that experience make them care about?
  • What have they posted, published, or presented? What is the consistent argument they make?
  • What role do they play in the decision — technical validator, business owner, future peer?
  • What question would they most want answered that nobody ever thinks to address?
  • What would make them look good to their own leadership if this hire worked out?
the question they want answered is rarely the one they ask
Audit. Put everything in one place: the assignment, every transcript, every piece of research, the JD, notes from any calls. Then treat it like a PRD intake — assess completeness before you start designing anything. The goal is to know exactly what you’re working with, what you’re missing, and what you can’t get because it’s proprietary or internal. That last category is an assumption you’ll name explicitly.
Completeness audit prompts:
  • Do I have the actual assignment brief, or am I working from memory? Is it written down?
  • What industry context do I have? Competitive landscape, market position, analyst coverage?
  • What is the regulatory environment? Industry-specific rules, state law, federal oversight, pending legislation?
  • What geopolitical or macro factors are relevant? Is the company exposed to anything that affects how they build or buy AI?
  • What do I know about the company’s legal posture? Any public litigation, consent decrees, or compliance obligations that would constrain the build?
  • What internal information would I need that I can’t have? Architecture docs, internal data schemas, vendor contracts, budget constraints?
  • For each gap: is it a blocker, or is it an assumption I can name and carry?
  • If I had to describe exactly what I need to build right now, what would I say? Can I write it in two paragraphs?
The output of this step is a short brief, the equivalent of a PRD: what you’re building, why, what you know, what you’re assuming, and what you’d need to revisit once you have access to the real system.
know what you have before you design anything
2
The brief
Name the one real job in a sentence, then attack your own thesis for flaws.
Name the gap. Every role has one real job underneath the listed responsibilities. Name it in a single sentence. Then hold it against the brief — the JD, the take-home assignment, whatever they gave you — and ask whether your understanding accounts for everything they asked for.
Alignment checks:
  • What is the one thing this role exists to prevent or produce? Can I say it in one sentence?
  • Does my artifact address that sentence, or does it address something adjacent to it?
  • What does the assignment explicitly ask for that I have not yet addressed?
  • What does the assignment implicitly want to see — the judgment or taste behind the ask — that I could miss if I only read it literally?
  • If I came back to this target tomorrow with fresh eyes, what would I say I got wrong?
always come back to the target
Find the flaws. Before building anything, take what you have — your research, your thesis, your plan — and run it against everything you know. Ask it to find what you missed.
KB audit prompts:
  • What is wrong or overstated in my thesis? What would a skeptic dismantle first?
  • What am I assuming that I have not verified? What would break my argument if the assumption is false?
  • What does the assignment ask for that I am not doing? What is the version of this that a great candidate would submit that I have not built yet?
  • What does someone in this role know that I am treating as if I already know it?
  • What is the most important thing I left out?
  • If they push back hard on my central recommendation, what is the weakest part of my defense?
ask for the flaws
3
What to build
Build it on their stack, then walk through the decisions you made.
Build it. Built on the company’s actual domain: their document types, their risk classes, their named failure patterns. The artifact should be able to fail in the ways their real system fails — and show you catching it.
Use their actual stack. If they run on Databricks, build on Databricks. Supabase, Salesforce, Monday.com — whatever the JD names or the research surfaces. Free accounts are available for a low-scope project in almost every platform. When you demo on their infrastructure, they don’t have to imagine the translation. The question shifts from “could this work on our stack” to “when do we start.”
Build to reuse. The highest-leverage build is one you can expand and re-apply. A bespoke artifact you throw away after the interview is worth less. If the work is genuinely in the domain you want to work in, build it as a real piece of a real platform — one that gets better as you add to it. Each new interview surfaces a different angle on the same system. A monitoring layer built for one company teaches you something that improves the evaluation layer for the next. A help system built for one platform becomes the reference architecture you reach for in the next conversation about knowledge management. You stop starting over. The platform grows, and so does your depth in it.
Build checks:
  • What platform does the JD name, or what does the research say they run on? Am I building there?
  • Is the data shaped like their data, or is it shaped like a tutorial?
  • Does the artifact fail in the ways their real system would fail? Can I demonstrate a failure and a catch?
  • What is the honest limit of what I built? Where does it break down, and am I stating that upfront?
  • What would this look like in production at their scale? What would I do differently with six months and a team?
  • Does the build address the specific sentence I wrote in step 2, or did I drift to something easier to build?
their stack, their data, their failure modes
Show the decisions. What you chose not to build is as important as what you built. Walk through the decisions out loud. Then return to the assignment and confirm: does what I built answer what they asked? Not what I found interesting — what they asked.
Final alignment check:
  • Re-read the original assignment or JD. Does my work answer it directly?
  • What did I build that they didn’t ask for? Is it additive or is it a distraction?
  • What did they ask for that I still haven’t addressed? If I can’t answer this, I am not done.
  • Can I state the honest limit in one sentence without hedging? If not, I don’t understand it yet.
  • Have I named my assumptions explicitly — what I inferred from public sources, what I couldn’t know, and what I’d validate once inside?
  • If I were them, would I see myself in this role after reviewing what I submitted?
the assignment is the target — always return to it
4
The deck
Short presentation, grounded in what you found. Write the talk track as a full script alongside it. You need to know exactly what you mean to say on each point before anyone asks a question.
State your assumptions explicitly. You did not have access to their internal systems, their actual data, or the full context behind the role. Say that. Name what you assumed, what you inferred, and what you would need to validate once you’re inside. That honesty is proof of judgment. Candidates who present as if they know everything they couldn’t possibly know signal worse than candidates who are honest about the edges of their research. The framing: “Based on what’s publicly available, I assumed X. I’d want to confirm that against your actual setup before committing to this approach.”
5
The rehearsal agent
Shape the agent like the room, set the difficulty, then run it until it’s easy.
Voice agent. Use your research on the actual people in the meeting: their roles, their background, what they already know, what they care about. Give the agent everything they would walk in knowing. The questions it asks should only make sense if you understand the org’s specific situation.
research the people too
Difficulty. Build the agent with multiple settings. Early runs: surface-level questions to find the obvious holes. Later runs: hard questions from someone who knows the domain well. The hardest setting should be harder than the actual room — so when you get there, the questions feel slow.
Run it. Present to the agent. Its questions find what you left out, what you got wrong, and what you glossed over because you assumed it was obvious. Revise. Run it again. The questions get easier as the gaps close because you actually know the material now.
you’re ready when you answer without thinking
The presentation is the eval. The agent’s questions are the score. The gaps it finds are the findings. You iterate the deck the same way you’d iterate an agent that keeps failing the same check — fix the source and run it again. You’re running evals on yourself.
© 2025–2026 Charlie Fuller