ThoughtsOct 16, 2026

AI-Augmented Interviews

How I use AI to get ready for interviews

The problem

Five minutes to prep

As a manager, my calendar sometimes gets very busy. Interviews get squeezed in between everything else. I usually have a few minutes before an interview to prep, and a few minutes after it to write up my thoughts before the next meeting starts.

A few minutes isn’t enough to read a resume closely, compare it to the job description and plan questions. So I’d walk in half-ready, ask generic questions, and spend the first ten minutes figuring out what I should have known going in. That isn’t fair to the candidate, and it isn’t my best work.

  1. 9:00 1:1
  2. 9:30 Sprint planning
  3. 10:25 5 min
  4. 10:30 Interview · Sam Rivera
  5. 11:30 Roadmap review

In those five minutes

  • Find the job description
  • Open the resume PDF
  • Find the question doc
  • Match the resume to the job
  • Decide what to ask

Still reading when the call starts.

Figure 1. The same morning, with and without the kit.

The kit

What I built

I built a system that does the homework for me. It takes a job description and a resume and builds an interview sheet for each interviewer. Claude reads the resume against the job, works out where to dig in and what to confirm, and writes questions based on what the candidate actually did. A script turns that into a single HTML file per person. There’s no server and no login. You open the file and go.

Everything in this post is made up: the candidate, the role, the stack, the questions and the scores. The real thing works the same way.

Job description
Resume
Claude preps fit · dig in or confirm · resume questions
  • David My sheet
  • Jordan Co-interviewer
  • Morgan Co-interviewer
Figure 2. Two documents in. One sheet for me and one for each co-interviewer.

The fit

How they stack up

The first thing I read is the fit. Each requirement from the job description sits next to what the resume says about it, with a quick read: strong, partial or gap. Every point ties back to a line on the resume, so I can check it myself. In a minute, I know where this person is strong and where the open questions are.

The sheet also carries the full resume and the job description. If something in the summary surprises me, the source is right there in the same file. I don’t have to dig through email or a shared drive for the PDF, and neither do my co-interviewers.

Interview sheet · Sam RiveraSenior Frontend Engineer

Six years in front end, the last three on a design system. Strong on TypeScript and on working with designers. Accessibility and performance are listed but not shown.

Fit against the job description
RequirementFrom the resumeRead
TypeScript at scale Moved a 200k-line app to strict TypeScript Strong
Design systems Built a 60-component React library used by five teams Strong
Partnering with design Built color and spacing tokens with the design team Strong
Accessibility Lists WCAG 2.2 work, no example of a fix Partial
Web performance Nothing about measuring load time Gap
Figure 3. Click through the tabs. Grade a few answers on the Rate tab, then see them on Send back.

The Rate tab walks through the interview one question at a time. Each question shows what strong and weak answers sound like, and each grade from 1 to 4 has its own description. When a resume follow-up fits, it sits right under the question it supports. I don’t have to remember the rubric or flip between docs mid-interview. I listen, pick the description that matches, and jot a note.

Focus

Where to dig in, and what to confirm

An interview goes fast. The sheet tells me where to spend the time. It shows where the candidate looks strong and where the resume leaves open questions.

Strong doesn’t mean skip. A big TypeScript migration on a resume is still a claim, so I check it with one quick, specific question. Did they lead it? What was the hardest part? If the answer holds up, I move on. Most of the time goes to the open questions, the places where the resume doesn’t tell me enough yet.

Questions

Core questions, plus their resume

Every candidate for a role gets the same core questions, in the same order, graded against the same rubric. That keeps the grades fair and lets me compare one candidate with the next.

A script alone makes for a stiff interview, though. So I weave in follow-ups from each person’s resume, where I want to dig deeper or something caught my interest. The core question still gets graded the same way. The follow-up helps me get a fuller answer.

Sam Rivera

  1. Accessibility Follow-up You listed WCAG 2.2 work on checkout. Walk me through one fix.
  2. Component API design Follow-up You built a library five teams use. What did you push back on?
  3. Performance Follow-up You moved the marketing site to server rendering. How did you measure it?
  4. Working with design

Alex Chen

  1. Accessibility
  2. Component API design
  3. Performance Follow-up You cut the app’s bundle size by 40%. What went first?
  4. Working with design Follow-up You started design reviews at your last job. What changed because of them?
Figure 4. Two candidates for the same role. The four core questions match, so the grades compare. The follow-ups change with each resume.

Each follow-up starts from a specific line on the resume, like “You listed WCAG work on checkout. Walk me through one issue you found.” I set it up so every follow-up names the line it came from and the part of the interview it belongs in. Click a question to see where it came from:

  1. Intro 5 min
  2. Component API design 15 min
  3. Accessibility 10 min
  4. Performance 10 min
  5. Working with design 10 min
  6. Their questions 5 min

Resume · Sam Rivera

  • Built and maintained a 60-component React library used by five product teams.
  • Led WCAG 2.2 compliance for the checkout flow.
  • Moved the marketing site from client-side rendering to server rendering.

Helps probe

Pick a question.

Figure 5. The interview plan. Each resume question comes from one line on the resume and goes in the section where it helps most.

The follow-ups also change the feel of the interview. When I ask about something they listed, the candidate knows I read their resume, and they get to talk about work they’re proud of. People relax and open up when the conversation is about what they built.

Dig deeper

Questions that tie the candidate to our own code and tickets

Dig deeper

Context from our repos and tickets

The kit can also read our code and our ticket history. None of it goes to the candidate. It’s context for the interviewers.

From the repos, it builds a profile of what the team uses day to day. The fit then compares the resume against our real work, not only the job description.

From the tickets, it finds recent work that lines up with something on the resume. Then it suggests a question that connects the two:

From our repos · what the team actually uses

  • React
  • TypeScript
  • Server rendering
  • Design tokens
  • Playwright
  • Storybook
  1. From their resume

    Moved the marketing site from client-side rendering to server rendering.

    From our tickets · WEB-482

    We moved product pages to server rendering last quarter. Hydration errors on the price widget took two sprints to fix.

    web-app/src/components/price · Jordan knows it best

    Ask

    “We hit hydration errors when we moved to server rendering. Did you run into that, and how did you handle it?”

  2. From their resume

    Built color and spacing tokens with the design team.

    From our tickets · WEB-517

    A token rename broke the themes of three teams that use the library.

    design-system/tokens · Morgan knows it best

    Ask

    “How did you roll out a token change without breaking the teams that use it?”

I get a sharper question, and my co-interviewers get background on work they might not have touched. The candidate gets a real look at the kind of problems we work on.

When I ask, I keep it general. The candidate doesn’t need ticket numbers or internal names.

This only works because the system knows what our terms mean and where they live in the code.

One level deeper

The knowledge base behind it

Dig deeper · One level deeper

The knowledge base behind it

Behind the kit is a small knowledge base I keep next to my AI tools. It’s a folder of plain text files that every agent reads. Here’s how it’s organized:

  • my-workspace/
  • house-rules.md Instructions every agent reads first
  • knowledge/ What the team knows, in plain text
  • lexicon/ One file per term
  • learnings.md Patterns across terms
  • repos.md Which code each term lives in
  • skills/ The agents: ticket triage, meeting prep, interview prep
  • code-cache/ Local copies of the repos the agents read

The core is the lexicon, one file per term. A term can be a product name, a concept or an acronym. Each entry says what it means, where it lives in the code, what past tickets say about it and who knows it best.

Lexicon · Product

Price widget

What it is
The component that shows a product’s price, sale price and stock on every product page.
Where it lives
web-app/src/components/price
Past tickets
6 in the last quarter, mostly hydration and caching bugs
Knows it best
Jordan

Read by

  • Ticket triage
  • Meeting prep
  • Interview sheets

It grows as I work. When something uses a term the system doesn’t know, it flags it. I define the term once, and every tool uses it from then on.

  1. 1 Spot A ticket, meeting or resume uses a term the system doesn’t know. It flags it.
  2. 2 Define I write it down once, with a pointer to the code.
  3. 3 Use Every agent reads it from then on: triage, meeting prep, interview sheets.
  4. 4 Clean up A regular pass catches duplicates, conflicts and stale entries.

That pays off well beyond interviews. When a new ticket comes in, the system matches it against the lexicon, points to the right code and pulls up similar past tickets. Meeting prep uses the same terms. New teammates get the team’s vocabulary on day one, without picking it up over months.

The AI suggests new terms and edits, and I decide what goes in.

Sharing

Built to share

I didn’t want a tool only I could use. Every interviewer gets their own sheet with the same questions, the same rubric and the same description of what each grade means. It’s a single file, so I can send it the way we already share things. My colleagues open it in a browser. There’s nothing to install and no account to set up.

The resume goes inside the sheet too. When the script builds each sheet, it converts the resume PDF into text and saves it in the HTML file, along with the job description. When someone opens the sheet, their browser turns it back into a PDF. So I send one file. There’s no attachment to forget and no shared-drive link someone can’t open.

Notes and grades save as they go, so nobody types anything up afterward. When they’re done, the Send back tab copies their results and opens an email that’s already addressed to me. They paste and send. That fits in the few minutes before their next meeting too.

Figure 6. Sheets go out as files and results come back as email. Step through it.

Feedback

Objective, consistent feedback

Because everyone works from the same questions and the same rubric, the feedback lines up. A 3 from Jordan means the same thing as a 3 from me. Everyone grades on their own before we talk, so the first opinion in the room doesn’t pull everyone else along.

When the emails come back, a script merges them. It checks that each reply is for the right candidate and the right set of questions, and it sets aside any that aren’t. Then it builds a debrief that puts every score side by side and flags any question where scores are 2 or more points apart.

  • David
  • Jordan
  • Morgan
  • Build an accessible dropdown
  • Design a component API
  • Debug a slow page discuss
  • A disagreement with a designer
  • How they use AI tools discuss
Figure 7. Each mark is one interviewer’s score from 1 to 4. The green bars show where scores are 2 or more points apart.

That keeps the debrief short. Questions everyone agrees on take seconds. The flagged rows are where the real conversation is: someone noticed something the rest of us missed, or we read the same answer differently.

Every candidate also lands in one spreadsheet. When it’s time to decide, I compare candidates on the same questions, scored the same way, not on who I happened to remember best.

Average score per question, per candidate
CandidateDropdownAPI designSlow pageDesignerAI tools
Sam Rivera 3.33.73.03.02.0
Alex Chen 2.73.03.72.33.3
Riley Park 3.72.32.73.73.0
Figure 8. The spreadsheet view: each candidate’s average on the same questions, from 1 to 4. Darker means higher.

The point

AI does the homework

This is the kind of work I want AI to do. Reading a resume against a job description, matching lines to requirements and planning where the time goes is homework. It is valuable, but it takes time, and it starts over with every candidate. Claude does it ahead of time, so I don’t have to cram it into five minutes.

That leaves the parts that I’d like to focus on: listening, asking a meaningful follow-up that stirs up a conversation, and making the candidate feel like they’re talking to someone who cares. The kit doesn’t replace any of that. It gives me room to do it. I walk in prepared and calm, and I’m a better interviewer for it.

Claude doesn’t decide who gets hired. My co-interviewers and I grade the answers, and the script just adds up our scores.

Takeaways

What I learned

  1. The prep is where AI helps most. Doing the homework before the interview changed more than anything AI could do during it.
  2. Confirm strengths quickly, dig into the gaps. A short check on what the resume shows leaves room for what it doesn’t.
  3. Specific questions make better conversations. Asking about something on their resume shows I read it, and it gets people talking about work they care about.
  4. Make it easy to share. A file and an email meant my colleagues could use it right away, and their feedback came back in a shape I could compare.