Interview prep · the core of it
How to prepare for interview questions
This is the part everyone means when they say “prep,” and most people do it two ways that don't work: they study generic question lists they won't actually be asked, and they rehearse the answers silently in their head. Both feel productive. Both leave you exposed in the room. Here's the version that works, predict the real questions, build reusable stories, and practise out loud.
The short version
- Predict the questions for this role and level rather than a generic internet list.
- Build five or six reusable, structured stories instead of memorising scripted answers.
- Practise out loud and get feedback against the bar, knowing an answer isn't saying it.
The two ways people prep wrong
The first mistake is studying the wrong questions. A list of “top 50 interview questions” is generic by design, so you spend hours on prompts that don't match your role, your level, or this company's loop, and you miss the ones you'll actually face. The second mistake is rehearsing in your head. You read a question, think “yeah, I'd talk about the migration project,” and move on, having never said a single sentence out loud. Then in the room, the words don't come out the way they did in your head, and you ramble or freeze. Fixing both is most of the battle.
Predict the questions you'll actually get
You can't know the exact wording, but you can predict the shape with real accuracy, because interviews follow the loop. Start from the job description, it tells you what they're prioritising right now, and map it onto the typical rounds for your role and level. Our 2026 Tech Interview Report and each role guide set out that shape, and what each round is testing, for 30 roles.
Then decide where to spend the time. The questions worth the most are the ones aimed at the gap between your CV and the posting. If the role wants deep distributed-systems experience and yours is thin, that's the round they'll dig into, so prepare it first. Knowing which questions are coming, and which ones are aimed at you, beats grinding through a generic list. It's the same idea as working out you're a fit and where your gaps are before you apply.
Here's a simple way to sort it. Go down the requirements line by line and put each one in a bucket: confident, need to brush up, don't know yet. For the ones you're confident on, line up a real project so you can show you've done it instead of just saying so. Then put most of your prep time into the other two buckets. That's where the interview will find you.
Build reusable stories instead of scripts
Don't memorise answers. Memorised answers sound memorised, and they fall apart the moment a question is worded differently than you practised. Build material instead: five or six real stories from your career covering impact, conflict, a failure you learned from, leadership, and your best technical work. Give each one a structure, and the STAR method is the standard one, so you can bend any of them to whatever they actually ask. With a good set of stories you're never answering cold. You're picking the one that fits and adapting it as you go.
What over-preparing looks like from the candidate's side
You don't have to take my word for any of this. A post on r/interviews titled “don't prepare too much” picked up a few hundred upvotes from people describing the same thing. The author had been writing out every question they might get, with notes on how to answer each one, and then found themselves reciting in the room instead of talking.
What's interesting is the comments. Almost nobody argues for preparing less. They keep describing one specific failure:
“When I over prepare I create a mental script. Then if a question isn't presented to me how I expected, I start trying to crowbar my prepared answer in and struggle.”
r/interviews
“What helped me was preparing stories instead of scripts. I keep a few STAR examples in my head and then let the wording change based on the interviewer.”
r/interviews
“AI was helping a ton with my prep. The problem was I was essentially rehearsing a set of canned responses. When I got hit by a question I wasn't expecting, it threw me off.”
r/interviews
One person prepared fifteen STAR scenarios, got asked none of them, and still said the practice was worth it, because it taught them how to shape an answer rather than which answer to give. Someone else went the other way and reported five interviews and three offers off the back of studying hard.
That spread tells you the amount was never really the variable. The format was. Scripts break because an interview is a conversation, and a conversation isn't going to follow your script for an hour. Stories bend, because you built them out of things that actually happened to you.
“So isn't that exactly what predicted questions are?”
It's a fair question, and worth answering straight, since predicting questions is something we sell. A predicted question is useful for two things: it shows you which round is aimed at the gap between your CV and the posting, and it gives you something specific to say out loud. It is not a list to write answers against and learn by heart. Use it that way and you'll get exactly the result the people above are describing. The value is in the rehearsing and the feedback, not in the list.
Practise out loud, knowing isn't saying
This is the step that costs the most offers, because it feels optional. Knowing an answer and being able to say it under pressure are two different skills, and the interview only grades the second one. The fix is simple and uncomfortable: say your answers out loud, and record them. You'll hear where you wander, trail off, or never quite land the point. Going quiet or rambling is one of the top reasons strong candidates get rejected , and it's a practice problem, not a knowledge one.
Get feedback from someone who knows the level
Practising out loud on your own helps. Being graded helps more. The catch is that a friend can tell you that you sounded nervous, but usually can't tell you whether your answer is good enough for a Staff Engineer rather than a Senior one. That difference is the whole game, as what gets you the offer explains. You want feedback from someone who knows the level you're being measured against, not just whether you sounded confident.
The fast way: predicted questions you can practise on
The goal is to walk in ready for whatever they ask, and this is the quick route there. Paste a real job description and Calibrd works out the questions for that company and level, round by round. Each round gets its own card with what it's testing, how to prepare, and the questions you're likely to get, plus angles drawn from your own CV for the behavioural and motivation ones. Then you rehearse each one. Type or speak your answer (recording is transcribed free, in 99+ languages), and one click gives you feedback on it, keeping your own wording and tightening the structure to what the level expects. You leave with the right questions, your real answer, and feedback that knows the level.
So what do you actually do
- Work out the questions from the job description and your role's usual rounds. Skip the generic list.
- Prepare the rounds aimed at your gaps first. Those are the ones they'll dig into.
- Build five or six stories you can reuse, instead of memorising scripted answers.
- Say every answer out loud and record it. That closes the gap between knowing and saying.
- Get feedback that knows your level, not just “you sounded fine.”
Know exactly what they'll ask
Walk in ready for every question they ask
Go in ready for the questions instead of guessing at them. Paste a real job description for any tech role and Calibrd shows you what that company and level will ask, where your CV is thin, and what the role should pay. Then rehearse each answer out loud with honest feedback, and run a full voice mock interview: a live round that presses where a real interviewer would, then gives you an honest debrief. PDF emailed. Free to install.
Free to start · No credit card · Your CV stays on your device