Free interview prep tools
Interview preparation fails in a predictable way. People read about the STAR method, agree with it, and then never say a full answer out loud until the interview itself. Reading is not rehearsal, and the gap between the two is where most of the nerves come from.
Start from the questions your specific role actually gets rather than a generic list. What a backend engineer is asked shares very little with what a product manager is asked once you're past the first five minutes. Knowing what's coming turns preparation into repetition: say the answer, notice where it wandered, tighten it, say it again.
Five well-chosen stories cover most behavioural rounds. A hard technical problem, a conflict you handled, a failure you owned, a time you led without authority, and a delivery under real constraint. Each one re-angles to answer several different questions, which holds up far better than memorising twenty answers that collapse the moment the wording shifts.
The tools
Where STAR answers usually go wrong
The most common failure isn't ignorance of the framework, it's mis-weighting it. People spend ninety seconds setting up the situation and fifteen on what they actually did. Invert that. One sentence of situation, one of task, then the bulk of your time on the specific decisions you made, the trade-offs you weighed, and the thing you personally built or changed. Finish on a result that carries a number.
Watch your pronouns while you practise. If you hear yourself saying "we" repeatedly, that's the signal to re-anchor on "I", because the interviewer is assessing you rather than your former team. This is difficult to catch in your head and obvious the moment you hear a recording, which is the entire argument for practising out loud.
Technical and coding rounds reward narration
Interviewers cannot assess reasoning they can't hear. State your assumptions before you start, name the brute-force approach and say why it isn't good enough, describe the better approach before you write any of it, and say the complexity out loud when you finish. A candidate who reasons clearly while stuck routinely outscores one who silently arrives at a correct answer, because the day-to-day job looks much more like the former.
Treat silence as the thing to avoid rather than a wrong turn. If you're stuck, say what you've ruled out and why. That converts dead air into evidence of how you think.
How much practice actually helps
Ten minutes a day for a week beats a single long session the night before, for the same reason spaced repetition beats cramming anywhere else. The goal isn't to memorise answers, it's to make retrieval automatic enough that you can hold a conversation rather than recite. Rehearsed-but-understood sounds conversational. Memorised sounds like a recording, and interviewers increasingly probe with "tell me that a different way" specifically to tell the two apart.
Related guides
- ›Interview questions by role and company
- ›Predicted questions for a specific job description
- ›Career direction quiz
Common questions
How many interview questions should I prepare?
Prepare five strong stories rather than a list of questions. A hard problem, a conflict, a failure you owned, a time you led without authority, and a delivery under constraint will cover most behavioural rounds, because each one can be re-angled to answer several different questions.
Is practising out loud really different from writing answers down?
Yes, and the difference is large. Interviewing is a motor skill. Written answers tend to evaporate under pressure because you never rehearsed the act of saying them, which is why people know the STAR method and still hear themselves ramble.
How long should a behavioural answer be?
Roughly 90 seconds to two minutes. Much shorter and you haven't given enough specifics to be credible; much longer and the interviewer loses the thread and stops taking notes.
Do I need an account or payment to use these tools?
No. Everything runs in your browser with a built-in engine and no signup. Adding your own AI provider key is optional and sharpens the feedback, but nothing is gated behind it.
Other tool sets: Resume tools · Cover letters · Salary and offers · Job search · Recruiter outreach · Free utilities
Building your story inventory: five narratives that cover everything
The most efficient interview prep is built on stories, not facts. Most behavioral questions are rephrasings of the same five underlying questions: Can you handle hard technical problems? Can you resolve conflict? Can you own failure? Can you lead without authority? Can you deliver under constraint? If you have a story for each, you can answer almost any question by re-angling one of them. The hard-technical-problem story is straightforward: pick a genuinely difficult technical challenge you solved, name the challenge clearly, explain why it was hard, walk through your approach, and finish with the result. That story answers 'Describe a time you solved a complex problem', 'Tell me about a technical project you're proud of', and several other variations.
The conflict story is subtly different. You need a time you disagreed with someone you reported to or worked alongside, and you handled it professionally. This isn't a story about being right; it's a story about resolving disagreement. 'My manager wanted us to ship the feature with known bugs. I pushed back, we discussed the trade-offs, and we decided together to delay ship by a week to fix them'. That's conflict resolution. What you don't want is 'I was right and they were wrong'. That reads as inflexible. The leadership-without-authority story is when you didn't have the title but drove a decision or project anyway. Code review process, documentation, a new tool adoption, mentoring someone. Those are all leadership without authority. The constraint story is delivery under real pressure: short timeline, limited resources, ambiguous requirements. The failure story is the hardest because it requires owning the mistake. 'I shipped a bug that broke production. I fixed it, then I implemented better testing so it wouldn't happen again'.
Once you have five stories, the prep is to practice saying them out loud until they're natural. Read them silently and you'll memorize the words. Say them out loud and you'll catch the places where you ramble, where you use too many 'um's, where your pronouns shift from 'I' to 'we'. Recording yourself is faster feedback than you'll get otherwise. Narrate the story, play it back, notice what's weird, tighten it, record again. By the time you've done this five times per story, you have material that's real, practiced, and flexible. When you hit an interview question, you're not searching your memory for what happened; you're retrieving a story you've told fifty times.
What makes technical explanations fail in interviews
Technical rounds test both your depth and your ability to think through a problem under some pressure. The explanations that fail do so in predictable ways. The most common is starting too high-level and never getting specific. 'I architected a scalable system' tells the interviewer nothing. 'I designed a cache layer using Redis to sit between our application servers and the database, reducing query latency from 200ms to 50ms and cutting database load by sixty percent' shows you understand the problem (slow queries), the solution (caching), the tool you chose (Redis), and the metrics that matter (latency and load). Those specifics are what's being tested.
The second failure mode is losing track of the constraint. An interviewer asks 'Design a system for X' and you start designing without asking clarifying questions. How many users? How much data? What's the acceptable latency? Is availability or consistency more important? These questions signal that you think systematically. Answering without them signals you're guessing. The strong move is to state assumptions clearly. 'I'm assuming ten million daily active users, writes are rare, and we can accept eventual consistency' tells the interviewer you've thought about the problem dimensions. If your assumptions are wrong, she can correct you, and you still get credit for the method.
The third failure is narrating only the happy path. 'We'd shard the database and scale horizontally' is incomplete. What breaks sharding? How do you handle a hot shard? What happens when you rebalance? Interviewers are listening for whether you've thought about failure modes and operational reality, not just theoretical scaling. Adding even one line about a real constraint makes your answer much stronger. 'Sharding works well until a particular customer's shard becomes overloaded; we'd monitor shard size and rebalance before it's a problem' shows you've thought about what actually breaks and have a plan for it.
Dry runs, feedback loops, and the compounding returns of practice
Most interview prep fails because people prepare alone. They read about STAR, they think about stories, they feel ready. Then the interview happens and the preparation doesn't transfer. The difference between reading and rehearsal is enormous. Recording a story and playing it back is feedback that reading never gives. You discover you say 'like' forty times or you bury the point in the middle or you use passive voice constantly. None of those issues show up when you're just thinking through the story. They appear the moment you say it out loud.
The second failure is not practicing with pressure. Doing a mock interview with a timer is different from thinking through answers. The timer creates urgency, and urgency is where your nerves actually live. A mock interview that goes wrong—where you blank, where you ramble, where you panic—is worth ten clean rehearsals because you learn how you actually behave under conditions close to the real thing. You discover that you need longer to think and that saying 'Let me think for a second' is fine. You discover that you're stronger on some questions and need more material on others. This is the feedback that shapes preparation.
The compounding is that each cycle of practice and feedback makes the next iteration tighter. You do a mock interview and realize you take too long to explain context. You tighten the story. You do another and notice you're stronger on technical questions than behavioral. You build more behavioral material. You do another and the whole thing feels smoother. By the tenth practice interview, you're not learning new things every time; you're refining delivery. That refinement is what produces calm in the real interview. You've done this fifty times, so the real one is just one more.
Frequently asked questions
Should I memorize my stories word-for-word or keep them flexible?
Flexible with a consistent structure. Know the key points, practice the opening and closing tight, but let the middle adapt. This way you sound natural and you can re-angle to answer the question being asked.
How long should each story be?
Two to three minutes when spoken naturally. If your story takes five minutes to tell, it's too detailed. Trim context and jump to the decision and outcome.
What if I haven't failed at work? Can I use a non-work example?
Ideally, yes use work examples. But a genuine personal failure is better than a fake work one. If you've never failed at work (which is unlikely), use a real failure story from earlier in your career, even if it's from an internship.
How do I handle technical questions where I don't know the exact answer?
Describe the approach and your reasoning. 'I haven't used that exact tool, but I'd approach it like this because of X constraint' is often strong enough. Interviews test thinking, not encyclopedic knowledge.
I get nervous and talk too fast in interviews. What helps?
Practice out loud enough times that the material is automatic, so you're not searching your memory mid-sentence. Pause between thoughts. Say 'Let me think for a moment' when you need time. Both slow you down and buy you clarity.