Interview prep starts with your own resume
Your resume is the question bank. Interviewers pick a bullet and dig: what did you do, how, what happened, what would you change. So prep by probing your own page first: for every line, be ready to go two minutes deep with specifics. If a line cannot survive that, fix the line before the interview does.
Where do interview questions actually come from?
Mostly from the two documents on the table: your resume and the job description. Interviewers scan your page, pick the claims that matter for their role, and dig. "Tell me about this project." "How did you measure that 20 seconds?" "What was your part, exactly?"
That is good news. It means the exam is open book and you wrote the book. The bad news is symmetrical: every line you cannot back up is a question you are choosing to fail in advance.
How do you probe your own resume?
Go line by line and ask what a skeptical, friendly interviewer would ask:
- What was the actual situation, in one sentence a stranger would follow?
- What did YOU do, as opposed to the team?
- Where did the number come from? Could you explain how you measured it?
- What went wrong along the way, and what did you change?
- What would you do differently now? Growth reads as seniority
The two-minute test: if you can talk about a line for two full minutes with specifics, it is interview-ready. If you dry up at thirty seconds, either go re-learn your own story or tighten the claim until it matches what you can defend.
How do you tell the story without rambling?
Use the same shape your bullets use, expanded: the situation in a sentence, what you did, and what happened, with the result carrying a number when you have one. Lead with the outcome when the question is broad, then let them pull the details they care about.
Practice out loud, once per bullet. Out loud is different from in your head: the rambly version shows up immediately, and so does the fix.
So basically we had this group project and there were a lot of moving parts and I did a bunch of different things, like some of the backend and also helping other people, and it turned out pretty well I think.
Our team of four built a budgeting app in six weeks. I owned login and payments. The riskiest part was the payments integration, so I built that first behind a test flag. About 30 classmates used it during finals week.
Why honest resumes are easier to defend
Interviews are where resume inflation gets collected. A padded claim means spending the interview managing a story instead of telling one, and interviewers are better at noticing that than candidates are at hiding it.
An honest page flips the dynamic: every question lands on ground you actually stand on, and you get to be interested in the conversation instead of afraid of it. This is why the coach checks every edit against your real experience before it goes on the page. The resume it helps you build is one you can sit across a table and defend line by line.
What should you prepare beyond your own page?
The other document on the table is theirs. Read the job description the night before and map each requirement to the story you would tell for it. Prepare one honest answer for the gap they are most likely to poke, because "here is what I would do to close it" beats improvising a defense.
Then prepare two questions of your own that show you read the posting. An interview is a conversation about whether this match works. You have more standing in it than you think.
Asked.
Answered.
"Walk me through this project or role." Rehearse a two-minute answer for your strongest line: outcome first, your part, one interesting complication.
Re-learn it before the interview: reread the code, the doc, the deck. If the details are truly gone, cut the line. "I do not remember" about your own resume is a terrible answer.
Name them first, with what you are doing about them. "I have not used Docker in production, so I have been running my projects in it" is a strong answer.