Choose the best response for 5 real technical interview scenarios — from system design clarification and STAR answers to coding out loud.
Interview speaking essentials
Clarify requirements before designing — always ask about scale and constraints
STAR: Situation → Task → Action → Result — always include metrics
Think out loud — interviewers evaluate your reasoning, not just the answer
End with specific questions — "What does success look like in 90 days?"
0 / 5 completed
1 / 5
An interviewer asks: "Walk me through how you would design a URL shortener like bit.ly." Which opening response uses the STAR / structured design approach best?
Why B is the model answer: clarify requirements first
Senior engineers always clarify scope before designing. This signals maturity and shows you understand that design decisions depend on constraints.
The system design interview formula:
Clarify: "Before I start, let me clarify…" — ask about scale, features, constraints
Estimate: "For 10M URLs/day, we'd need…" — back-of-envelope math
High-level design: "The main components would be…"
Deep dive: "Let me go deeper on the database choice…"
Trade-offs: "The trade-off here is…"
Why the others fail:
A: Jumps to implementation without understanding scope
C: "I know how" — doesn't explain anything. Interviewers want your thought process
D: Listing components robotically without context or reasoning
Useful clarification phrases:
"Before I start, let me clarify the requirements…"
"Are we optimising for [X] or [Y]?"
"What's the expected scale — DAU, QPS?"
"Do we need to support [feature]?"
2 / 5
An interviewer asks: "Tell me about a time you handled a production incident." You're using the STAR method. Which response structures it most effectively?
Why C is the model answer: full STAR with metrics
The STAR method is the gold standard for behavioural interview answers:
Situation: "payment service timing out for 8% of transactions" — specific context
Task: "on-call, 30-minute SLA" — your responsibility
Action: "identified missing index → full-table scan" — concrete diagnosis and fix
What makes a great STAR answer in tech interviews:
Specific numbers and metrics (8%, 4s→80ms, 22 minutes)
Your individual contribution (not "we" throughout)
Technical depth appropriate to the role
A clear positive outcome (or lesson learned)
Why the others fail:
A: Too vague — no specifics
B: Has some structure but lacks metrics and specifics
D: Self-praise without evidence — "relies on me" is a red flag to interviewers
3 / 5
An interviewer asks: "What's the difference between a process and a thread?" You need to explain a technical concept clearly. Which answer is best?
Why B is best: structured explanation with analogy and real-world example
Technical concept explanations in interviews should have three layers:
Definition: "A process is an independent execution unit with its own memory space"
Analogy or contrast: "think of it as a running program" — grounds abstract concepts
Concrete example: "A browser process might have..." — shows practical understanding
The "Explain Like I'm 5 then go deep" technique:
Start with a clear, simple one-sentence definition
Add a relatable analogy
Then add technical depth
Offer to go deeper: "Would you like me to go into scheduling, or context switching?"
Why the others are incomplete:
A: "smaller thing" — too vague, shows limited vocabulary
C: Correct but robotic — no example, no structure
D: Correct single sentence, but incomplete — interviewers want depth + clarity
4 / 5
You're asked a coding question and you're not immediately sure of the optimal solution. What's the best way to start?
Why C is the model answer: think out loud and self-correct
Interviewers evaluate your thought process, not just the final answer. The best candidates:
Articulate their starting point: "My first instinct is…"
Acknowledge trade-offs: "That works but isn't optimal"
Reason through improvements: "If I use a hash map…"
State complexity: O(n²) → O(n) — shows CS knowledge
Useful "thinking out loud" phrases:
"My first instinct is… but let me think about whether that's optimal."
"The naive approach would be [X]. Can I do better?"
"If I use [data structure], I could reduce this from O(n²) to O(n)."
"Let me think about edge cases first: what if the input is empty?"
"I'll start with a working solution, then optimise."
Why silence or asking for hints hurts you: Interviewers can't assess your reasoning if you're silent. Asking for hints signals you can't break down problems independently.
5 / 5
At the end of your interview, the interviewer says "Do you have any questions for us?" Which is the most effective question?
Why C is the best question strategy: role-specific, forward-looking
Questions at the end of an interview are a two-way assessment. Good questions signal:
You're thinking about how to succeed (not just "do I get the job")
You're genuinely curious about the work
You've done your research (you ask about challenges, not basics)
High-quality interview questions:
"What does success look like in the first 90 days?"
"What's the biggest technical challenge the team is facing right now?"
"How does the team handle technical debt / onboarding / code reviews?"
"What does the engineering career path look like here?"
"How are architectural decisions made? Is it top-down or collaborative?"
Questions to avoid:
"No questions" — signals lack of curiosity or preparation
Salary questions at this stage — premature and can be off-putting
"Tell me about the company" — shows you didn't research; ask specific questions instead