STAR answers that sound like you

STAR answers that sound like you

Photo by Elle Hughes on Pexels.

Most frontend interview advice still sounds like grind LeetCode. Behavioural rounds get a PDF of STAR and a hope that you will remember it when someone asks about conflict.

STAR is useful. Situation, Task, Action, Result is a scaffold so you do not ramble. It is not a personality. The answers that land sound like the person who did the work. The answers that fail sound like a blog post you rehearsed in the mirror until the verbs died.

I mark behavioural the same way I mark a screen. I am listening for a real problem, a decision you owned, and a result you can defend. I am not listening for the word “synergy,” and I am not giving extra points because you named the acronym.

If you can already code and you still lose the loop after the technical, this is often the hole.

What STAR is for (and what it is not)

STAR is four beats:

• Situation — enough context that a stranger knows the world. Product, users, constraint. Not a biography.
• Task — what you were on the hook for. Not the team’s OKR slide.
• Action — the decisions you made. Tools are supporting detail. Judgement is the point.
• Result — what changed. Shipping is a result. Learning is a result if you say what you would do next. “We moved forward” is not a result.

It is not a script you fill with fake numbers. I do not want you inventing a 37% conversion lift you cannot explain. If you do not have a metric, say what you observed: fewer support tickets about the form, the page stopped janking on low-end phones, design stopped pinging you about the modal. Specific and honest beats precise and made up.

The four ways STAR starts sounding fake

1. Situation eats the clock.
You spend two minutes on the company history, the org chart, and the sprint name. I still do not know what was hard. Cut Situation to two or three sentences. If I need more, I will ask.

2. Task is “we.”
“We needed to improve performance.” I cannot hire a we. What were you responsible for? If you were the only frontend on it, say that. If you owned the table virtualisation and someone else owned the API, say that. Credit is allowed. Fog is not.

3. Action is a tool list.
“I used React, Redux, and Jira.” That is a CV line, not a story. Action is: I profiled, I found the list was mounting thousands of rows, I proposed windowing, I argued against prefetching the world, I wrote the fallback for keyboard users, I watched it fail in QA and changed the estimate. Verbs you can point at.

4. Result is a vibe.
“It went well and the stakeholder was happy.” I cannot put that in a debrief. What did you ship? What broke? What would you still change? A modest, true result with a scar is stronger than a cinematic win.

Mine stories from work you already did

You do not need a hero project. You need six to eight stories you can tell in two minutes each, mapped to questions that always come up.

Sit down with a notebook — actually sit down, this is not a vibe — and list:

• A production bug you diagnosed.
• A time the design was right for the mock and wrong for the keyboard.
• A time you said no, or said “not this week.”
• A time you were wrong, and what you changed in the process.
• A time you inherited a mess (legacy CSS, a form nobody owned, a dashboard that fetched on every render).
• A time you had to explain a trade-off to someone who does not write CSS.

For each, write four ugly bullets. Not prose. If you cannot fill Action without saying “we,” pick a smaller story. A one-day incident you led is better than a six-month programme you attended.

Frontend-specific stories interviewers actually want:

• Performance: the list was huge, search was typing into a filter, the main thread was busy. What did you measure, what did you cut, what did you not do?
• Accessibility: the modal trapped focus, or it did not. Labels were placeholders. You caught it in review or you caught it from a user. Either is a story.
• Async: the happy path worked, error states lied, retries stampeded. You changed the interface, not just the catch.
• Scope: they asked for a real-time collab editor. You shipped presence and a lock first. You can explain why.

A bad answer and a better one (same job)

Prompt: Tell me about a time you disagreed with a product or design decision.

Fake STAR:
“In my previous role, stakeholders wanted a new dashboard. I am a strong communicator, so I set up a meeting and we aligned. I used Figma and React. As a result, we delivered on time and learned a lot as a team.”

I have learned nothing. Anyone could say it. It could be a course.

Yours:
“Situation: we had a settings page where every control was a custom dropdown. Design wanted them all, for visual consistency. Task: I owned the page and the a11y review. Action: I built one as specified, tabbed through it, and it took seven keystrokes to change a boolean. I recorded that, showed it next to a native checkbox, and proposed native controls for binary settings and a custom list only where we needed search. Result: we shipped mixed controls. Design kept the custom one where it earned the complexity. Support stopped getting ‘I can’t turn this off with a keyboard’ tickets. I still owe us a written rule in the design system so we do not have the argument twice.”

Same job. One is a template. One is a person I can put in front of a team.

Notice there is no fake percentage. Notice Action is long and Situation is short. That ratio is the whole trick.

How I mark it in the room

I am not marking whether you smiled. I am marking:

• Did you restate the question so I know you heard it?
• Is there a constraint (time, users, a11y, performance, a person you had to convince)?
• Did you own a decision, including the ugly parts?
• Can you talk about what you would do next without rewriting history?
• Did you finish in two minutes, or did I have to interrupt?

If you freeze, I will prompt: “What did you do?” If you still cannot leave the we, I assume you were in the room and not on the hook. That may be unfair. It is still what happens.

Senior loops add one more thing: trade-offs. Mid-level can tell me they fixed the bug. Senior should tell me what they declined to fix, and why that was the right call for that week.

This matches the same marks on the Shortlist Scorecard: name the interface, talk trade-offs, explain a project as decisions. Behavioural is the same exam in English.

Practise it like a skill, not a pep talk

You would not walk into a React screen having only thought about hooks. Do not walk into behavioural having only thought about stories.

A useful drill:

1. Pick one prompt. Conflict, failure, performance, “tell me about a project,” “when did you miss a deadline.”
2. Two minutes on a timer. STAR out loud. Phone voice memo is fine.
3. Listen back once. Circle the we’s, the tool lists, the missing result.
4. Do it again the same day. Do not collect twenty stories you have never spoken.

On CodePrepped, Pro Trainer has a behavioural mode built for this: STAR-style prompts with clear marks, not a vibe check. Mock Interview is the voice version, capped on the Pro plan — see pricing. Keywords will not save a behavioural round, but it will stop you waving at words like “debounce” when the story needs them. Arena still matters: a lot of STAR answers are just technical judgement with the names of people left in.

Keep a living list, not a script document

Write the four bullets. Do not memorise a 400-word essay. Interviews interrupt you. A script falls over when they ask a follow-up you did not rehearse. Bullets survive.

Update the list when you ship something. A story from last month beats a polished story from a bootcamp two years ago. Recency is a signal here the same way it is on GitHub.

What to do this week

1. Write six ugly STAR bullets — not prose — for the prompts above. One sitting.
2. Say two of them out loud on a timer. Cut Situation. Lengthen Action. Put a real result on the end, even if the result is “I would not do it that way again.”
3. Do one Trainer behavioural prompt if you have Pro, or one voice memo if you do not.
4. Map one story to a live posting. If they repeat “accessibility” or “performance,” that story goes first.

Then stop polishing. The goal is to sound like you on a Tuesday, not like a keynote.

If the rest of prep is still scattered across tabs, put the daily loop on CodePrepped. Technical and behavioural are the same week. Treat them that way.

How long should a STAR answer be?

About two minutes spoken. Situation is two or three sentences, Task is one, Action is the body, Result is a few sentences including what you would still change. If you need a slide deck to finish, you picked too big a story. Shrink it until it fits in a conversation.

What if I do not have leadership stories yet?

You do not need a title. You need a decision. Owning a form, a modal, a performance pass, or a keyboard-access comment in review is enough. Pick a small incident you actually drove. Interviewers can tell a lived story from one borrowed from a blog.

Can I use the same STAR story twice?

Yes, if you tilt it. A production bug can be a failure story, a communication story, or a performance story depending on the question. Do not replay the identical two minutes. Change which decision you emphasise. Keep two or three extra stories so you are not stretching one incident across a four-round loop.