5 exercises — structuring stories with Situation, Task, Action, Result for tech interview questions.
0 / 15 completed
1 / 15
In a STAR answer, how long should the Situation step ideally be?
The Situation step should consume roughly 10% of your answer — typically 1–2 sentences. Its only job is to orient the listener: when, where, what was at stake. Spending too long on context feels like stalling. The interviewer is waiting for what you did (Action) and what changed because of it (Result). Allocating your time: Situation 10% → Task 10% → Action 60–70% → Result 20%.
2 / 15
Which sentence is the best STAR story opener?
An effective STAR opener immediately signals: role (leading the backend chapter), context (Acme, Q3 2023), and the problem/stake (45-minute deployment windows). The word "While" is a strong opener — it places you inside the situation immediately. Options A and C are vague and informal. Option D wastes time on meta-commentary before you've said anything. Start in the scene, not before it.
3 / 15
In the Action step, which pronoun should you use when describing what you personally did?
The entire point of the Action step is to demonstrate your contribution. Use "I": "I identified the bottleneck", "I proposed the solution", "I led the migration". If you say "we" throughout, the interviewer cannot assess what you specifically did versus what your team did. You can acknowledge team effort briefly — "I coordinated with two other engineers" — but the agency must be yours. Interviewers train themselves to ask follow-up prompts like "What was your specific role?" to extract this.
4 / 15
Which Result statement is the most compelling in a STAR answer?
Strong Results have three elements: (1) specific action reference (parallelising, caching), (2) quantified before/after (45 → 8 min, 6×), (3) business impact (unblocked 3 teams). Numbers are powerful — they make abstract improvements concrete and memorable. Option A is vague ("people were happy"). Option B lacks numbers. Option D is technically true but tells the interviewer nothing specific. Rule: if you don't have numbers, name a concrete business outcome.
5 / 15
Choose the best phrase to bridge from Action to Result: "I rewrote the database queries to use indexed columns _____ query times fell from 800ms to 90ms."
"as a result of which" is a formal, precise connective that links cause directly to effect — ideal for STAR answers because it signals a logical consequence rather than just a sequence of events. Other strong alternatives: "which reduced query times to 90ms", "resulting in a 90ms response time", "cutting query times from 800ms to 90ms". Avoid "and then" (too informal, implies sequence not causation) and "so therefore" (redundant — use one or the other).
6 / 15
Review Context: You've just received a code review comment from Sarah on the following PR description:
// Fix: Handle null user ID gracefully
// Prevents NullPointerException when user data is missing.
The best code review comment focuses on clarity and impact. Sarah's response effectively describes the issue (NullPointerException) and the solution (null check). A strong comment avoids vague statements and clearly outlines the corrective action taken. Options A, C, and D are all insufficient because they miss this core element of a good feedback message.
7 / 15
Standup Update: During the daily standup, Mark says, 'I spent yesterday working on the new authentication flow.' Which of the following best completes his update, adhering to STAR principles?
Hint: Focus on what you *did* and the immediate impact.
A STAR update needs to provide context and demonstrate impact. Mark's initial statement only describes *what* he did; it doesn't show the *Situation*, *Action*, or *Result*. Option 1 expands on his action with specific details about the functionality implemented and acknowledges a minor challenge (integration issues). Options A, C, and D are all too broad or miss key elements of the STAR framework.
8 / 15
Slack Message: Liam sends this message to the team:
@everyone I'm blocked on getting feedback from QA.
A useful Slack message should communicate a blocker's impact. Liam's message clearly states that he's blocked and implies it will delay progress. While further context might be needed in a follow-up, the initial message fulfills the purpose of alerting the team to a potential issue. Options A, C, and D are all inadequate because they fail to articulate the problem's consequence or propose solutions.
9 / 15
Code Review Response: You receive this comment from David on a pull request:
// Consider adding more tests for this functionality.
A good code review comment goes beyond simply stating a problem; it offers constructive feedback. David's suggestion to add more tests demonstrates this by indicating *why* the comment was made – to improve the functionality's robustness and testability. Options A, C, and D are weak because they lack specifics or don't offer guidance for action.
10 / 15
API Response: You receive the following API response:
When describing an API error response, it's crucial to convey *what* went wrong and suggest possible solutions. The response includes a status code (400), a descriptive message ('Invalid request parameters'), and implicitly suggests the user needs to review their input. Options A, C, and D are insufficient as they lack this critical information or fail to frame the error within a user-centric context.
11 / 15
Review Context: You've just received a code review comment from Sarah on the following PR description:
// Fix: Handle null user ID gracefully
// Prevents NullPointerException when user data is missing.
The best code review comment focuses on clarity and impact. Sarah's response effectively describes the issue (NullPointerException) and the solution (null check). A strong comment avoids vague statements and clearly outlines the corrective action taken. Options A, C, and D are all insufficient because they miss this core element of a good feedback message.
12 / 15
Standup Update: During the daily standup, Mark says, 'I spent yesterday working on the new authentication flow.' Which of the following best completes his update, adhering to STAR principles?
Hint: Focus on what you *did* and the immediate impact.
A STAR update needs to provide context and demonstrate impact. Mark's initial statement only describes *what* he did; it doesn't show the *Situation*, *Action*, or *Result*. Option 1 expands on his action with specific details about the functionality implemented and acknowledges a minor challenge (integration issues). Options A, C, and D are all too broad or miss key elements of the STAR framework.
13 / 15
Slack Message: Liam sends this message to the team:
@everyone I'm blocked on getting feedback from QA.
A useful Slack message should communicate a blocker's impact. Liam's message clearly states that he's blocked and implies it will delay progress. While further context might be needed in a follow-up, the initial message fulfills the purpose of alerting the team to a potential issue. Options A, C, and D are all inadequate because they fail to articulate the problem's consequence or propose solutions.
14 / 15
Code Review Response: You receive this comment from David on a pull request:
// Consider adding more tests for this functionality.
A good code review comment goes beyond simply stating a problem; it offers constructive feedback. David's suggestion to add more tests demonstrates this by indicating *why* the comment was made – to improve the functionality's robustness and testability. Options A, C, and D are weak because they lack specifics or don't offer guidance for action.
15 / 15
API Response: You receive the following API response:
When describing an API error response, it's crucial to convey *what* went wrong and suggest possible solutions. The response includes a status code (400), a descriptive message ('Invalid request parameters'), and implicitly suggests the user needs to review their input. Options A, C, and D are insufficient as they lack this critical information or fail to frame the error within a user-centric context.
What does "Behavioural Questions with STAR — Interview Exercise" cover?
Practice the STAR technique for behavioural interview questions. 5 exercises covering Situation, Task, Action, and Result with IT examples.
How many questions are in this interview set?
This set has 15 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.