Editorial review: 9 October 2026
Problem-solving starts with an observable gap
Problem-solving skills help you describe an unexpected result, investigate plausible explanations, compare responses and check what happened after a decision. At work, this may mean explaining why a report omitted an entry or why a handover failed. The useful evidence is what you observed and tested, rather than a claim that you are naturally analytical.
This guide uses a complete fictional reading-list exercise. All records, traces, decisions and results below are supplied teaching material, not a customer case or an incident at a named employer. The example shows why an apparently convincing explanation can still need another check.
NASA's decision-analysis guidance discusses intended outcomes, alternatives, uncertainty, documented assumptions and the authority responsible for a decision. Its context is systems engineering. The principle of making your reasoning and limits explicit is useful here; the exercise below is our original workplace-learning example, not a NASA procedure or an employment assessment. Read NASA's decision-analysis guidance.
Define the expected result before proposing a fix
A fictional training team maintains a public reading-list preview. Its agreed exercise rule is simple: include each record whose status is “ready,” preserve input order, and display its identifier and title. Records marked “draft” should be absent. The owner has not authorised a change to these rules.
The new input, version 2, contains:
- R1: “Listening practice” — ready.
- R2: “Question design” — ready.
- R3: “Feedback notes” — draft.
- R4: “Reading review” — ready.
The expected preview is therefore R1, R2 and R4, with their corresponding titles in that order. The observed preview contains only R1 and R2. That is the gap: R4 is missing even though the supplied version 2 marks it ready. Nothing in the observation establishes who caused the problem or whether anyone acted carelessly.
A useful problem statement is: “For the supplied version 2, the preview omits ready record R4; expected identifiers are R1, R2, R4, while observed identifiers are R1, R2.” It identifies the input, expectation and result. “The team is inefficient” would introduce an unsupported judgement and leave the actual task unclear.
Keep competing explanations open
Two explanations fit the initial observation:
- The preview read the older version 1, which contained only R1, R2 and R3. Filtering its draft record would legitimately produce R1 and R2.
- The preview read version 2 but a display limit kept only the first two ready records. That would also produce R1 and R2.
Seeing two displayed entries cannot distinguish these explanations. Rechecking that version 2 exists does not prove the preview used it. Asking “why” several times without collecting new evidence could simply build a story around whichever explanation you preferred first.
The next useful request is for a trace showing both the input version used for that run and the result immediately after filtering, before display. That request separates input selection from transformation. It is more informative than asking a colleague whether the preview generally works.
In a real task, collect such evidence through the authorised owner or approved diagnostic process. This practice example contains no private records and does not require changing a production system or accessing information outside your role.
Use the supplied trace to narrow the explanation
The exercise now supplies this trace for the exact observed run:
- Input version read: version 2.
- Input identifiers: R1, R2, R3, R4.
- Identifiers after the ready-status filter: R1, R2, R4.
- Display setting: maximum two entries.
- Identifiers emitted to the preview: R1, R2.
This trace rules out reading version 1 as the explanation for this run. It also locates the omission after filtering: R4 survived the filter but was absent from the emitted preview. The two-entry limit explains the supplied output without requiring a claim about the status rule being wrong.
Keep the conclusion proportionate: “The supplied run applied a two-entry display limit after correctly filtering version 2.” This is stronger than the original guess because it uses discriminating evidence. It still does not establish why the limit was configured or whether every other run follows the same path.
If the trace did not include the display setting, you would know only where the omission occurred. A later-stage omission could have several causes. Do not fill missing evidence with confidence or treat a colleague's intention as an observed fact.
Compare actions against the agreed objective
The objective is to show every ready record in input order for this exercise. Consider three responses:
- Remove the display limit in the exercise preview. This directly addresses the observed omission while retaining the status rule and input order. It needs an owner decision because it changes a setting.
- Mark R4 differently. This changes valid source data to work around a display issue. It does not address the supplied cause and could misrepresent readiness.
- Keep the limit and explain that this is a sample. This could be reasonable for a different requirement, but it does not satisfy the currently agreed “every ready record” objective. The owner would have to change that requirement explicitly.
A decision does not become rigorous merely because a table gives each option a numerical score. Here, the mandatory condition is clear enough to assess directly. Avoid adding invented cost estimates, risk percentages or weights that make a subjective preference appear measured.
The proposed action is to remove the two-entry limit in the exercise preview and rerun the same input. The owner, rather than the person writing the analysis, has authority to approve that change.
Separate proposal, approval and checked result
The exercise supplies a subsequent owner decision: “For this practice preview, remove the maximum-two setting. Keep the ready-status filter and original order. Check version 2 again.” This is an explicit approval within the example. No real change has been made by this article.
The supplied rerun result is:
- R1 — Listening practice.
- R2 — Question design.
- R4 — Reading review.
Check each condition rather than only counting entries. All three displayed records are ready in version 2; draft R3 is absent; identifiers and titles match; and the order follows R1, R2, R4 from the input. The result satisfies the stated rule for this finite case.
The appropriate outcome statement is: “After the approved exercise-setting change, the supplied version 2 rerun matched all three expected ready records and excluded R3.” It does not prove that every future reading list will be correct, that a production deployment succeeded or that the team saved time.
Change the input and reconsider the explanation
Now version 3 is the intended input for a separate exercise run. It adds R5 “Discussion practice” with ready status after R4. The limit remains removed. The expected identifiers are R1, R2, R4, R5, but the observed preview contains R1, R2, R4.
It would be tempting to repeat the previous diagnosis: “Another display limit.” The new supplied trace instead states:
- Input version read: version 2.
- Identifiers after filtering: R1, R2, R4.
- Display limit: none.
- Emitted identifiers: R1, R2, R4.
This time, the output matches the older input the preview actually used. The evidence supports stale input selection, not the previous two-entry limit. The next proposal is to ask the owner to select version 3 and rerun. No approval or rerun for that proposal is supplied, so its status remains pending.
This branch is the main lesson of the exercise: a similar symptom can have a different explanation. Keep your investigation tied to the exact run and records rather than carrying a successful diagnosis into every new case.
Practise the underlying skills
Observation: write the expected and actual results separately. Identify the source and version of each. Remove words such as “always,” “broken” and “careless” unless evidence supports them.
Analysis: name at least two plausible explanations when the evidence genuinely permits them. Ask what observation would distinguish them. Gathering more copies of the same ambiguous result does not necessarily reduce uncertainty.
Decision-making: compare proposed actions with the stated objective and constraints. Identify who can approve a change and what information that person needs. A recommendation and an approval are different events.
Communication: state what is established, what remains unknown and what you request next. In the version 3 branch, a useful handover says that version 2 was read and asks for an authorised version-selection check. It does not claim the proposed rerun has succeeded.
Follow-through: check the complete relevant result after an approved action. For this exercise, that includes titles, status inclusion, exclusion and order. A count alone could conceal a wrong entry replacing the missing one.
Explain problem-solving in a résumé or interview
Use a real example you are permitted to discuss. Describe your assigned task, evidence, contribution, decision boundary and verified result. If you only proposed a fix, say so. If another person approved or implemented it, preserve that distinction.
The reading-list exercise can be discussed as practice, but it must not become an employment achievement. A truthful practice summary is: “Compared two explanations for a fictional preview omission and used supplied trace evidence to distinguish input selection from a display limit.” Do not claim to have repaired an employer's platform.
For help presenting genuine evidence concisely, use the résumé writing guide. For preparation, the virtual interview guide can help you organise an answer without inventing business impact.
Frequently asked questions
Is asking five whys enough to find a root cause?
Repeated questions may suggest explanations, but each answer needs evidence. In this exercise, the initial output supports two explanations until a trace distinguishes them. A long chain of assumptions would not settle that uncertainty.
Does the 80/20 rule tell me which problem to fix?
It is not a measured distribution for your situation. Inspect actual counts, consequences and constraints before prioritising. This exercise has one defined omission, so importing an assumed percentage would add no evidence.
How do I practise without work experience?
Use small fictional or public, permitted tasks with explicit inputs and expected outputs. Record your initial hypothesis, the check that changed it and the final limit. Label practice as practice when presenting it.
Does strong problem-solving guarantee a higher salary?
No salary outcome follows from this example. Demonstrable reasoning can help explain your contribution, but compensation and hiring depend on the actual role and employer's decisions.