To prepare for a mock interview, choose five or six real stories from your work and practise telling each one out loud in about two minutes. Rehearse the follow-up questions each story invites, use STAR as a checklist rather than a script, and record yourself. Then review the recording for vague claims, missing results and answers that run long, fix one thing, and run the mock again.
Why a mock interview has to be out loud
Most interview preparation is reading: lists of common questions, model answers, tips. It feels productive, and it misses the thing that goes wrong on the day. An answer that sounds complete in your head comes out differently when you say it. It runs long, loses its point halfway, or ends before you mention how it turned out.
A mock interview exists to find those problems while they cost nothing. That only works if you treat it like the real thing: spoken, timed, and with someone (or something) asking the next question. The routine below takes a few hours spread over a week, and each step is something you do out loud.
Step 1: Choose your stories before the questions
Behavioural questions come in many wordings, but they draw on a small set of experiences. Instead of preparing fifty answers, prepare five or six stories you can adapt. Good candidates for your list:
- the piece of work you are proudest of;
- a problem you solved under pressure;
- a mistake you made, and what you did next;
- a disagreement with a colleague or manager;
- something you had to learn quickly;
- a time you changed someone's mind without being in charge.
For each one, write four short lines, not a script: the situation in a sentence, what you specifically did, the result, and what you would do differently. Then check which common questions each story can answer:
Swipe the table sideways to see every column.
| Story | Questions it can answer |
|---|---|
| Proudest work | "Tell me about yourself", "What are you best at?", "Describe a project you led" |
| Problem under pressure | "Tell me about a deadline you nearly missed", "How do you handle stress?" |
| A mistake | "Tell me about a failure", "What is your biggest weakness?" |
| A disagreement | "Tell me about a conflict", "When did you push back on a decision?" |
Do the same for your resume. Every skill you list is a question waiting to be asked, so pick one concrete example for each skill that matters to the role. The role guides for Python developers, data engineers and UX designers show the questions those roles tend to get and what a strong answer demonstrates.
Step 2: Use STAR as a checklist, not a script
STAR stands for Situation, Task, Action, Result. It is a good way to check that an answer is complete, and a poor way to deliver one. Answers built rigidly on it share the same faults:
- Too much situation. Half the answer is context, and the part the interviewer wanted, what you did, gets thirty seconds.
- "We" instead of "I". The team shipped it, so nobody can tell what you contributed.
- No result. The story stops at the action, as if the outcome were obvious.
- Audible structure. "The situation was... my task was..." sounds recited.
Used sensibly, it looks like this: one or two sentences to set the scene, most of the answer on your own actions and why you chose them, a concrete result, and a sentence on what you learned or would change. Here is the difference:
- Recited: "The situation was that our release process was slow. My task was to improve it. The action I took was automating it. The result was that it was faster."
- Natural: "Releases took our team most of a Friday, mostly manual checks. I wrote a script for the three checks that caught real bugs and dropped the rest, after going through six months of release notes. Releases went down to about an hour, and nothing we dropped has caused a problem since."
Not every question is behavioural. "How would you design this?" or "Why did you choose that database?" need reasoning, not a story, so answer those directly.
Step 3: Rehearse the follow-up questions
The first question is rarely what sinks an interview. The second one is. A good interviewer, human or AI, listens to your answer and asks about the part you skated over, and that is the part nobody rehearses.
For each story, write down the follow-ups it invites, then answer them out loud:
- "What exactly was your part in that?"
- "How did you know it worked?"
- "Why that approach and not the obvious alternative?"
- "What went wrong along the way?"
- "What would you do differently now?"
Two rules make this easier. If you quote a number, be ready to say how it was measured. And if a skill is on your resume, be ready to go two questions deep on it; if you cannot, practise saying plainly what you have and have not done. Honest limits survive a follow-up. Inflated ones do not.
If a friend runs your mock, give them one job: keep asking "why?" and "what did you do?" until the answer gets specific. Kindness is not useful here.
Step 4: Time your answers
Aim for about two minutes on a story question and less on a simple one. Longer answers leave less time for the questions that would have shown more, and in a short interview they crowd everything else out. Career1's AI mock interview, for example, lasts about eight minutes in total, so a four-minute answer uses half of it.
Time each story with your phone. If it runs long, the fix is almost always to cut the situation, not the action. It also helps to lead with the headline: say the short answer in your first sentence, then support it. If you are cut off, the interviewer has still heard the point.
Step 5: Record yourself and listen back
Recording is uncomfortable and more useful than any amount of reading. Use your phone's voice recorder, answer three questions, and listen back with a short checklist:
- Did the first sentence answer the question?
- Is it clear what you did, rather than what the team did?
- Is there a concrete result?
- Did you make any claim you could not back up if asked about it?
- How long did it take?
If your phone can transcribe the recording, read the transcript as a stranger would. Vagueness is easier to see written down, and Career1's AI interviewer scores the transcript rather than the audio, so that page is close to what it reads. Notice filler words and trailing endings, but fix the content first. Pick one problem per round and change only that.
Step 6: Run the mock interview
Once your stories are ready, run a full mock under realistic conditions: a quiet room, the device you will use on the day, and no notes beyond a few keywords. There are three common ways to do it, and they are good at different things.
Swipe the table sideways to see every column.
| A friend or mentor | Recording yourself | Career1's AI mock interview | |
|---|---|---|---|
| Asks follow-up questions | If you brief them to | No | Yes |
| Honest about weak answers | Often too kind | Only as honest as you are | Written feedback, no score |
| Available when you are | Needs scheduling | Any time | Once a week, at any hour |
| Knows your field | Sometimes very well | You do | Works from your resume |
Career1's free AI mock interview is a spoken practice interview in your browser. It reads your resume first, so it asks about your own projects, and it follows up when an answer is thin. Practice is private: there is no video, no score, and nothing is shared with companies. Afterwards you get written feedback on what went well, what to work on and what to try next time. You can take one practice interview a week.
Step 7: Change one thing, then run it again
A mock interview is only worth what you change afterwards. Read the feedback, or your own notes from the recording, and pick the one or two issues that came up more than once. Rewrite the four lines for the stories they affected, rehearse those out loud, and run another mock. A week between runs is enough time to actually fix something rather than repeat the same answers.
You are ready when you can tell each story in about two minutes without notes, answer the follow-ups without hesitating, and nothing on your resume would surprise you if someone asked about it.
If you are preparing for Career1 specifically, keep the two interviews apart in your head. Practice is for mistakes. The vetting interview is a separate single attempt, with no retakes, that is recorded, scored and becomes the profile companies can find, which you can hide at any time. For what AI interviewers ask and how answers are scored, read AI interview questions.
Questions people ask
What is a mock interview?
A mock interview is a practice interview that imitates a real one, with a friend, a mentor or an AI playing the interviewer, so you can find weak answers before they count. It is most useful spoken out loud, timed, and with follow-up questions.
Should I use the STAR method for every answer?
No. STAR suits behavioural questions such as "tell me about a time". Use it to check an answer has a situation, your actions and a result, but do not recite the labels. Technical and opinion questions need direct reasoning instead.
How long should an interview answer be?
Aim for about two minutes on a story question and less on a simple one. Say the short answer first, then support it, so the point lands even if you are interrupted.
Is AI interview practice as good as practising with a person?
They are good at different things. A person who knows your field can judge technical depth and delivery; an AI mock interview is available whenever you are, follows up consistently and gives written feedback without being kind about it. Using both is better than either.
Practise it out loud, in private
Career1's AI interviewer reads your resume, asks about your own work by voice and follows up when an answer is thin. A practice interview is private: once a week, no video, no score, and written feedback on what to work on. Career1 is free for job seekers.
The vetting interview is separate: one attempt, no retakes, recorded and scored, and it becomes a profile companies can find. You can hide that profile at any time.