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.
- 9:00 1:1
- 9:30 Sprint planning
- 10:25 5 min
- 10:30 Interview · Sam Rivera
- 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.
In those five minutes
- Open one file
- Read the summary and the fit
- Note what to dig into and what to confirm
Walk in ready. Grades go out before the roadmap review.
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.
- David My sheet
- Jordan Co-interviewer
- Morgan 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.
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.
| Requirement | From the resume | Read |
|---|---|---|
| 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 |
Dig in
- Accessibility: hands-on fixes, or a checklist someone else ran?
- Performance: can they find a slow page and prove it got faster?
- Component APIs: how they say no to five teams asking for five variants.
Confirm quickly
- TypeScript: the 200k-line migration looks strong. One question to check they led it.
- Working with designers: the token work looks strong. Ask what they’d do differently.
Accessibility
Build a dropdown menu that works with a keyboard and a screen reader. Talk me through it.
Follow-up from their resume
“You listed WCAG 2.2 work on checkout. Walk me through one issue you found and how you fixed it.”
Resume: Led WCAG 2.2 compliance for the checkout flow.
Strong answers
- Handles focus, arrow keys and Escape without being asked
- Tests with a real screen reader
Weak answers
- Adds ARIA attributes without explaining what they do
- “We ran an audit tool”
Component API design
Design the API for a Button that five teams will use. What do you ship first, and what do you leave out?
Follow-up from their resume
“You built a library five teams depend on. Tell me about a component request you pushed back on.”
Resume: Built and maintained a 60-component React library used by five product teams.
Strong answers
- Starts from who uses it, not a list of props
- Says no on purpose and explains why
Weak answers
- A prop for every request
- No thought about breaking changes
Performance
A product page got slow after the last release. How do you find out why?
Follow-up from their resume
“You moved the marketing site to server rendering. What got faster, and how did you measure it?”
Resume: Moved the marketing site from client-side rendering to server rendering.
Strong answers
- Measures before changing anything
- Names real tools and real numbers
Weak answers
- Jumps straight to a fix
- “It felt faster”
Working with design
Tell me about a time you disagreed with a designer. What happened?
Strong answers
- Treats the designer as a partner
- Brings evidence, not opinions
Weak answers
- The designer was wrong, the end
- Built it as designed and complained later
This gathers everything you entered into one block. In the real sheet, it copies the block and opens an email that’s already addressed to me. Here you can copy it and see what I’d get.
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
- Accessibility Follow-up You listed WCAG 2.2 work on checkout. Walk me through one fix.
- Component API design Follow-up You built a library five teams use. What did you push back on?
- Performance Follow-up You moved the marketing site to server rendering. How did you measure it?
- Working with design
Alex Chen
- Accessibility
- Component API design
- Performance Follow-up You cut the app’s bundle size by 40%. What went first?
- Working with design Follow-up You started design reviews at your last job. What changed because of them?
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:
- Intro 5 min
- Component API design 15 min
- Accessibility 10 min
- Performance 10 min
- Working with design 10 min
- 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.
Can they design APIs other teams will actually adopt?
Accessibility is listed but not shown. Hands-on, or a checklist?
Nothing on the resume about measuring performance.
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
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.
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
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.
| Candidate | Dropdown | API design | Slow page | Designer | AI tools |
|---|---|---|---|---|---|
| Sam Rivera | 3.3 | 3.7 | 3.0 | 3.0 | 2.0 |
| Alex Chen | 2.7 | 3.0 | 3.7 | 2.3 | 3.3 |
| Riley Park | 3.7 | 2.3 | 2.7 | 3.7 | 3.0 |
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
- The prep is where AI helps most. Doing the homework before the interview changed more than anything AI could do during it.
- Confirm strengths quickly, dig into the gaps. A short check on what the resume shows leaves room for what it doesn’t.
- 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.
- 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.