A problem-solving interview scenario asks you to reason about a supplied situation. The useful response identifies the goal, clarifies missing rules, compares feasible choices and explains what remains uncertain. Naming a framework without doing that work leaves the interviewer unable to inspect your reasoning.
This guide completes an original fictional allocation case, including clarifying questions, numerical options and follow-up answers. It is an independently created practice exercise, not a question confirmed at any employer or a project performed for a client. You should not present its result as an accomplishment from your own employment.
Distinguish a scenario from an experience question
A hypothetical question asks what you would do under specified conditions. A past-experience question asks what you actually did. Keep the verb tense and evidence different: “I would propose” does not mean “I implemented.”
Microsoft's interview guidance encourages candidates facing a problem or scenario to ask clarifying questions, state assumptions and explain their approach. It also asks for specific experience examples where relevant. This is that employer's published preparation guidance, not proof that every interview uses the same format or that this practice case predicts a hiring decision.
For an experience question, use a genuine example and explain your contribution. For a scenario, work with the supplied contract and label any assumption you introduce. An attractive numerical answer can still be wrong if it violates a rule you did not clarify.
Keep preparing
Continue with Sarkari Resume Templates₹299 — coaching के एक महीने से काफ़ी सस्ता / far cheaper than a month of coachingRead the original case prompt
A fictional workshop organiser has 100 minutes before a dispatch deadline. One worker can prepare any combination of three request types. The practice task is to maximise the number of completed requests, while completing at least five of each type.
| Request type | Time for one completed request |
|---|---|
| A | 2 minutes |
| B | 4 minutes |
| C | 5 minutes |
The prompt supplies a maximum of twenty requests of each type. Each request must be completed in full; partial work has no value for the objective. There is no setup time, switching cost, break, rework or quality hold in this initial model. All materials are available. The worker handles requests sequentially.
These are invented constraints. There is no real dispatch operation, customer agreement or authority to choose what an actual organisation should prioritise. The specified goal is request count, not revenue, fairness, clinical urgency or customer importance.
Ask questions that affect the decision
Before calculating, confirm what “completed” means, whether the five-per-type minimum is mandatory and whether the twenty-per-type limit is a demand ceiling. Ask whether the task times include all required work and whether switching between types consumes time.
For this exercise, the answers confirm the stated contract. The interviewer does not supply a financial value per request or an extra worker. Do not quietly add either one. You can say: “I will optimise completed count under those rules; a different priority measure could lead to another plan.”
That sentence establishes the boundary of your answer. It shows which decision you are solving rather than pretending the number of requests is always the right business objective.
Reserve the mandatory work first
Five A requests take ten minutes, five B take twenty and five C take twenty-five. The mandatory set therefore uses 55 minutes and completes fifteen requests. It leaves 45 minutes for additional work.
A requests are the least time-consuming of the optional choices. There is room for fifteen more A requests before reaching the twenty-A ceiling. Those fifteen use thirty minutes, leaving fifteen minutes after completing twenty A, five B and five C.
With fifteen minutes remaining, three additional B requests take twelve minutes. Three minutes remain, which cannot complete another B or C, while the A ceiling is already reached. This gives twenty A, eight B and five C, or 33 requests, using 97 minutes.
The remaining three minutes are unused under the stipulated model. They are not enough for another permitted complete request. Do not count a half-finished C as a thirty-fourth completion.
Check that the proposed count is optimal
A feasible result is not automatically the best result. Here, a simple lower-bound calculation can show why 34 completed requests are impossible under the contract.
To reach 34, there would have to be nineteen optional requests beyond the mandatory fifteen. At most fifteen optional requests can be A because of its ceiling. Even the fastest possible remaining four optional requests would be B. Their combined time would be 15 × 2 + 4 × 4 = 46 minutes.
Only 45 optional minutes are available. Replacing any B with the slower C cannot make that minimum shorter. Thus 34 is impossible, while the 33-request proposal is feasible. The optimal count is therefore 33 for this exact contract.
This proves a result in a small invented model. It does not validate real task-time estimates or show that maximising count would serve actual customers fairly. Those are separate questions.
Show the plan and its limitations together
| Decision item | Original model result |
|---|---|
| Mandatory workload | 15 requests; 55 minutes |
| Optional time | 45 minutes |
| Proposed mix | 20 A, 8 B, 5 C |
| Total workload | 33 requests; 97 minutes |
| Unused time | 3 minutes |
| Optimality check | 34 requests require at least 101 total minutes |
The last row adds 55 mandatory minutes to the fastest possible 46 optional minutes. The result is 101, one minute beyond the deadline. Keep that reasoning available for a follow-up instead of memorising only the chosen mix.
An original short interview answer could read:
I would first confirm that completed request count is the objective and that the minimums and demand ceilings are mandatory. The minimum mix uses 55 minutes. Of the remaining 45 minutes, fifteen extra A requests use thirty, and three extra B requests use twelve. That produces twenty A, eight B and five C in 97 minutes, or 33 completed requests. A thirty-fourth request would require at least 101 total minutes because the A ceiling prevents using only two-minute work. This is a proposal under the supplied assumptions; I have not executed an operation or confirmed the estimates.
Respond when the interviewer changes a constraint
Suppose the interviewer adds a single ten-minute setup requirement for the whole session. It is a separate scenario, not a discovery about the original operation. Processing time drops from 100 to ninety minutes.
The mandatory set still takes 55, leaving 35 optional minutes. Fifteen additional A requests take thirty; one additional B takes four. The resulting mix is twenty A, six B and five C: 31 requests, with 89 processing minutes, plus the ten-minute setup, or 99 total minutes.
Thirty-two requests would require seventeen optional requests. The fastest permitted mix for those is fifteen A and two B, taking 38 optional minutes. Together with the mandatory 55 and setup ten, that would require 103 minutes. The new maximum is therefore 31 under the changed contract.
Explain which input changed, recompute the result and retain the original answer as the baseline. Defending the original 33 after a material constraint changes would demonstrate attachment to an answer rather than reasoning.
Answer useful follow-up questions
“Why not do the highest-value requests first?” The exercise provides no values. I can ask for them and build a new objective, but count optimality does not establish financial optimality.
“What if C requests are urgent?” Urgency would be an additional priority rule. I would ask which requests are mandatory before dispatch and recompute rather than infer urgency from a label.
“Would you actually implement this schedule?” I would first validate the time estimates, materials, completion criteria and decision authority. The practice calculation does not provide permission to alter a real workload.
“What if you do not know the answer immediately?” I would state what I have established, show the remaining uncertainty and ask a question that could resolve it. Inventing a customer result would not fill a reasoning gap.
Practise with evidence you can explain
Save the prompt, clarified contract, proposed mix, feasibility calculation, optimality argument and changed-constraint result. They form a complete practice artifact. If you time your own rehearsal, record the actual time rather than claiming a universal target for a good answer.
For a genuine experience answer, replace the fictional exercise with your own work and its evidence. Include shared contributions, unresolved results and what you learned. The STAR answer guide practises repairing overclaims in a past-experience answer; the operations guide demonstrates finite-window scheduling.
The skill this case exercises is traceable reasoning: another person can see the constraints, reproduce the arithmetic and identify what would change the decision. It does not establish a salary advantage, a guaranteed interview result or experience managing an actual dispatch team.