Case study interview for software engineers: format, example and scoring rubric
Updated 27 October 2026 · 6 min read
Short answer
A case study interview for an engineer presents a real situation from the job (an outage, a migration, an architecture choice) and asks the candidate to propose and justify a solution in about 30 minutes. Score it against a rubric set in advance (problem understanding, fit of the solution, trade-offs, clarity), then check understanding with follow-up questions about the candidate's own answer.
What a case study interview measures
A multiple-choice quiz checks whether a candidate recognises the right answer. A case study checks how they reason when there is no single right answer: how they frame the problem, which options they consider and which trade-offs they accept.
It works best after a short technical quiz and before the live interview, so the interviewer starts from a written answer instead of a blank page. See also coding assessments in the age of AI.
Example: a case study for a mid-level back-end engineer
Context: a bank runs a customer web portal. Since the last marketing campaign, the "my accounts" page takes 8 seconds to load at peak time. A diagram shows the front end, an API, a relational database and a third-party pricing service called on every page view.
Questions: 1) which hypotheses do you check first, and how? 2) propose two short-term fixes and one medium-term fix; 3) what are the risks and costs of each? 4) how will you know the problem is solved?
A strong answer measures before fixing, isolates the third-party call, proposes a cache whose lifetime matches the data, and says what will be monitored afterwards. A weaker answer starts by adding servers.
A 30-minute format
- 5 minutes to read the context and the diagram.
- 20 minutes to answer in writing, point by point, saved as the candidate types.
- 5 minutes to review.
- Then 15 minutes of timed follow-up questions about the answer.
Adjust the level: the same situation can be written for a junior (guided diagnosis) or a senior (architecture, budget and team trade-offs). In Hirlya, the case study is adapted to the candidate's level before it is frozen for them.
Scoring rubric
| Criterion | What good looks like | Weight |
|---|---|---|
| Problem understanding | Restates the problem, states hypotheses, wants to measure | 25% |
| Fit of the solutions | Solutions suited to the context and the target level | 30% |
| Trade-offs and risks | Costs, side effects, what they would not do | 25% |
| Clarity | Structured answer a peer can follow | 20% |
Set the rubric before reading any answer and score each criterion separately. It limits the halo effect and makes candidates comparable across interviewers.
Follow-up questions: is the answer really theirs?
Follow-up questions are about what the candidate wrote: "You suggest a 5-minute cache: what does the customer see if a price changes in between?", "Why start with that hypothesis?". They separate a candidate who understands their answer from one who copied it from an AI assistant.
In Hirlya, three follow-up questions are generated from the candidate's own answer, then pre-assessed by AI with its reasons; a recruiter reviews them and decides.
Questions
How long should a case study interview take?
About 30 minutes for the written answer and 15 minutes of follow-up questions. Beyond an hour it becomes a take-home assignment, which puts off candidates who already have a job.
Is there one right answer?
No. Score the approach against a rubric set in advance: problem understanding, fit of the solutions, trade-offs and clarity.