The questions they ask, and a timer to practise

A good answer covers: Two minutes: where you studied, the one or two things you built or did that fit this role, and why you applied here. Not your life story.

A good answer covers: Name something specific about the company or the role; connect it to what you want to learn and give.

A good answer covers: One strength the role needs, one short story that shows it, the result.

A good answer covers: A real one that is not central to the job, and what you are already doing about it.

A good answer covers: Your part in it, a problem you hit, how you solved it, what it did for people.

A good answer covers: A concrete method: a course, docs, building a small thing, asking someone. Give the last example.

A good answer covers: What was wrong, what you did (not what others did wrong), how it ended.

A good answer covers: A direction that includes this company, with the skills you want by then.

A good answer covers: Evidence: a project, an internship, a community role, a habit of finishing things.

A good answer covers: Always yes: the team's work in the first three months, how they measure a good first year, what they wish new hires knew.

A good answer covers: The problem, the pieces, the data flow, the trade-offs you chose and what you would change now.

A good answer covers: Constraints first: time, team, scale, cost, what can change later. Say what you would prototype.

A good answer covers: Memory space, scheduling, cost of creation, when you use each. One example from your work.

A good answer covers: Logs, metrics, reproducing with the same data, narrowing by bisecting; what you add so it is easier next time.

A good answer covers: Names, small functions, tests as examples, comments on why not what, reviews.

A good answer covers: DNS, TLS, the server, routing, the query, serialisation, caching along the way.

A good answer covers: Behaviour and edge cases over implementation; the cost of a test versus the cost of the bug.

A good answer covers: How you made the case with evidence, how you handled being overruled, what happened.

A good answer covers: Measure first; then the usual suspects: queries, payload size, caching, rendering, the network.

A good answer covers: Something specific, why it interested you, and what you did with it.

A good answer covers: Every change built and tested automatically, then shipped in small safe steps; what breaks when a team skips it.

A good answer covers: Stop the damage (roll back or scale), tell people, then find the cause; the post-mortem comes after sleep.

A good answer covers: Shared kernel versus a full OS; start-up time, isolation, density; when each is the right choice.

A good answer covers: Scheduling, self-healing, scaling, service discovery, rolling updates, declared desired state.

A good answer covers: A secrets manager or sealed secrets, environment injection, scanning the repository, rotation.

A good answer covers: Versioned, reviewable infrastructure (Terraform, Pulumi); the risk of drift or a destructive plan applied without review.

A good answer covers: Latency, errors, traffic, saturation; alert on symptoms users feel, not on every metric.

A good answer covers: Right-size, turn off idle things, reserved or spot capacity, storage tiers, find the one service eating most of it.

A good answer covers: Two environments or a small slice of traffic first, watched, then widened or rolled back.

A good answer covers: What it was, how you found it, how you fixed it without breaking the service, what you automated after.

A good answer covers: The business question, the data and its problems, the method, the chart that made it clear, what changed because of it.

A good answer covers: Find out why it is missing first; then drop, fill or flag, and say so in the result.

A good answer covers: Plain words, no formula: how surprising the result would be if nothing were going on.

A good answer covers: GROUP BY, SUM, ORDER BY, LIMIT; ask about returns and currency before you write it.

A good answer covers: When a rule or a simple average works, when there is too little data, when a wrong answer costs too much to explain.

A good answer covers: Hold-out data, cross-validation, watching the gap between training and test performance.

A good answer covers: Truncated axes, cherry-picked ranges, pie charts; what you changed and what it showed.

A good answer covers: Define the metric before launch, a comparison group, enough time and users, and what would count as failure.

A good answer covers: SQL, Python or R, a notebook, a BI tool; what each is good for and where it breaks down.

A good answer covers: Two things moving together without one causing the other; how you tested which was true.

A good answer covers: Valid and invalid paths, edge cases, security basics, accessibility, what happens on slow networks and small screens.

A good answer covers: The scenario is what to check; the case is the exact steps, data and expected result.

A good answer covers: Repeated, stable, high-value checks first; leave exploratory and one-off testing to people.

A good answer covers: Title, steps, expected versus actual, environment, logs or a screen recording, how often it happens.

A good answer covers: Report it with its impact clearly, propose options (fix, work around, delay), let the decision be made with facts.

A good answer covers: Checking that old behaviour still works after a change; before a release, after a refactor, after a dependency update.

A good answer covers: Postman or a script: status codes, schema, edge inputs, auth, rate limits, idempotency.

A good answer covers: Many unit tests, fewer integration, fewest end-to-end; where it fits and where it does not.

A good answer covers: Define the load and the target, measure under it, find the first bottleneck; tools you have used.

A good answer covers: Own it, say what the gap was, and the check or habit you added.

A good answer covers: Users' problems, the company's goal, the effort; a framework you actually used and what it left out.

A good answer covers: What you expected, what the numbers said, what you did with it.

A good answer covers: The user, the goal, acceptance criteria, examples, what is out of scope.

A good answer covers: Understand the goal behind the ask, bring data or a cheap test, agree on what success means.

A good answer covers: Find out why, cut scope before cutting quality, tell people early, re-plan with the team.

A good answer covers: One or two metrics tied to the goal, a baseline, and what would make you change course.

A good answer covers: Interviews with open questions, watching them use it, support tickets; how often and what you did with it.

A good answer covers: The context, the decision, who you told, what it cost later.

A good answer covers: A short written update, one meeting that matters, a visible plan; what you stopped doing.

A good answer covers: A specific thing, why users would feel the difference, how you would test the change.

A good answer covers: Research the range for the role and city, give a range not a number, and ask about the full package.

A good answer covers: Forward-looking and honest, no blame: what you want next that this role has.

A good answer covers: Know your notice period; a clear date beats an eager guess.

A good answer covers: Answer truthfully; a constraint discussed now saves a problem later.

A good answer covers: What you did in it, briefly, and what you learnt; no apology.

A good answer covers: Honest and brief: yes, to similar roles; this one interests you because of a specific reason.

A good answer covers: A real example and the habits that help: planning, asking early, breaks.

A good answer covers: Their products, customers, recent news, and one thing you find interesting about how they work.

A good answer covers: Clear goals, honest feedback, room to do the work; what you give back.

A good answer covers: Think about it before the interview: role, pay, location, growth; be clear and polite.

A good answer covers: Situation, what you did, what happened, what you changed. The change is the answer.

A good answer covers: Their view fairly, your view, the conversation you had, the outcome for the work.

A good answer covers: Noticing a gap, proposing a plan, bringing others along, the result.

A good answer covers: How you decided what came first, what you said no or not-yet to, who you told.

A good answer covers: What it was, how you reacted in the moment, what you did about it in the weeks after.

A good answer covers: A specific extra effort that helped someone, not just working late.

A good answer covers: What you knew, what you assumed, how you limited the risk, what you learnt.

A good answer covers: The gap, your method, the deadline, the result, and what stuck.

A good answer covers: Owning it quickly, fixing it, telling the people affected, preventing a repeat.

A good answer covers: Something true about you: the people, the craft, the user at the end.