Prepare STAR method answers for an interview

Paste the job ad and attach your resume. Get the behavioural questions you are most likely to be asked, each with a STAR answer drawn from your own experience.

How to use it

1. Give the ad and your resume Paste the full job ad and attach your resume. Add any stories you already know you want to tell.
2. Read the likely questions They are ranked by how likely they are, based on the ad. Cross out any that do not fit the role.
3. Say the answers out loud Each answer should take about two minutes. Ask in the chat for a shorter version of any that run long.
4. Practise follow-ups Ask the chat to play the interviewer and dig into one answer with follow-up questions.

The prompt

You are an interview coach. Prepare me for a behavioural interview using the STAR method (Situation, Task, Action, Result).

Role and company: [ROLE_AND_COMPANY]

Job ad: [JOB_AD_TEXT]

Stories from my experience I could use (rough notes): [MY_STORIES_NOTES]

Interview format, if known: [INTERVIEW_FORMAT]

Use my attached resume as the source of my experience.

Return:

- The six behavioural questions I am most likely to be asked, based on the requirements in the ad, each with the requirement it tests.
- For each question, a STAR answer of 180–250 words in the first person, built only from my resume and notes. Mark the Situation, Task, Action and Result. Make the Action the longest part and end the Result with a number or concrete outcome where I have one.
- For each answer, one follow-up question an interviewer might ask and a one-line note on how to handle it.
- A table mapping my stories to the questions, so I can see if I am leaning on one story too often.

Never invent experience, employers or numbers. If I have no story for a likely question, say so and suggest what kind of example would work.

Example result

Likely questions

1. Tell me about a time you found an error others had missed

Situation: During my internship at Redgum Analytics in 2025, the team sent a weekly sales report to a retail client. Task: I was asked to add a new chart, which meant reading the existing SQL behind the report. Action: While tracing the joins, I noticed that orders with two delivery addresses appeared twice, because the query joined orders to addresses without filtering for the primary one. I checked my theory by counting distinct order IDs against the report total for three weeks — the report was consistently 4–6% too high. I wrote up the issue with the query, the evidence and a one-line fix, and walked my supervisor through it before anything was sent to the client. Result: The fix went into the next report, and the client's revenue figures were corrected for the previous quarter. My supervisor added a distinct-count check to the team's report template.

Follow-up: "How did you tell your supervisor?" — Say you brought evidence and a proposed fix, not just the problem.

2. Describe explaining a technical finding to a non-technical person

Situation: In my university capstone, I analysed three years of city bike-share trips for the council's transport officer. Task: I needed to explain why one pricing zone looked unprofitable. Action: Instead of showing regression output, I made one chart: trips per day before and after a 2023 fare change, by zone. I explained it as "people in this zone started walking instead". Result: The officer took the chart to her manager, and the council reviewed that zone's fare.

Follow-up: "What would you do differently?" — Mention checking the finding with the operator's own data.

Story map

No story yet for a direct conflict question; a group project where you disagreed on method would work.