A Practical Problem-Solving Framework for Work and Interviews

Most failed solutions solved the wrong problem, or solved the right one under assumptions nobody checked. A simple, repeatable structure stops you jumping to the first idea that comes to mind, and it works whether you are debugging a report or sitting in an interview.

What a problem-solving framework is, and why it matters

A framework is a checklist for your thinking. It does not guarantee the right answer; it makes you less likely to skip an important step when you are stressed or under time pressure. Managers value people who can take something vague, like 'customers are unhappy with delivery', and turn it into a clear problem with options and a recommendation. Interviewers look for exactly the same process.

The six steps

Step one deserves the most patience. A good problem statement is specific and measurable: 'Support response time for billing tickets rose from about 4 hours to about 12 hours over the last three weeks' is a problem. 'Support is slow' is a feeling.

Worked example 1: a work problem

Scenario: you are a junior analyst. Your manager says, 'The weekly sales dashboard numbers don't match what finance reports. Can you sort it out?' Here is the framework applied, written the way you could post it in a ticket.

1. DEFINE
Problem: Weekly revenue on the sales dashboard is about 3% higher than finance's figure for the last 4 weeks. Before that, they matched.
Known: The gap started the week of 2 September. Finance reports use invoiced revenue.
Unknown: Which definition the dashboard uses; whether anything changed on 2 September.

2. CONSTRAINTS
- Need an answer before Friday's leadership meeting.
- Can't change finance's report; can change the dashboard.
- Dashboard query is owned by the data team; I have read access.

3. BREAK DOWN
Possible causes (hypotheses):
a) Dashboard counts bookings, finance counts invoices (definition mismatch)
b) A new product or region added in the dashboard but not in finance
c) Refunds or credit notes excluded in the dashboard
d) Duplicate rows from a join change
Check order: cheapest checks first: (a), then (c), then (d).

4. OPTIONS (once the cause is found)
A) Change the dashboard definition to match finance.
B) Keep both and label them clearly: Bookings vs Invoiced.
C) Add a reconciliation row showing the difference.

5. DECIDE
Recommend B plus C: leadership uses bookings for pipeline, finance needs invoiced numbers, and a visible reconciliation prevents the question coming back.

6. CHECK
Compare the next two weekly reports; the reconciliation row should show a difference that I can explain. Review on 20 September.

Notice what the structure gave you: the check order for hypotheses, an honest list of unknowns, and a recommendation with a reason, instead of 'I'll look into it'.

Worked example 2: a coding-interview-style problem

The same steps apply to a coding problem, but you say them out loud. Problem: given a list of integers and a target, return the indices of two numbers that add up to the target. Here is a candidate's reasoning, written as speech.

Define / clarify:
"Can there be duplicates? Is there always exactly one valid pair? Can I use the same element twice? Can the numbers be negative? How large can the list be?"
Interviewer: "One valid pair, no reuse, negatives possible, up to about 100,000 numbers."

Example:
"For [2, 7, 11, 15] and target 9, the answer is indices 0 and 1."

Brute force:
"The simplest approach checks every pair: two nested loops. That's O(n squared) time and O(1) space. With 100,000 numbers that's about 5 billion pair checks in the worst case, which is too slow."

Break down / options:
"For each number x, I need target minus x. Instead of searching for it each time, I can remember numbers I've already seen in a hash map from value to index. Then each lookup is O(1) on average."

Decide:
"I'll use the hash map: O(n) time, O(n) space. The trade-off is extra memory for speed. That seems right for this input size."

Check:
"Let me trace [3, 3] with target 6: first 3 is stored, second 3 finds the first 3, returns [0, 1]. And with negatives, [-1, 4] and target 3 works the same way."

def two_sum(nums, target):
    seen = {}  # value -> index
    for i, x in enumerate(nums):
        need = target - x
        if need in seen:
            return [seen[need], i]
        seen[x] = i
    return []

The code is the shortest part. Interviewers are mostly evaluating the definition, the brute-force baseline, the trade-off and the check. For a longer treatment of narrating your reasoning, see How to Think Out Loud in Problem-Solving Interviews.

Common mistakes

• Jumping to a solution before the problem is defined. The first idea feels productive but is often a fix for a symptom.
• Treating the problem statement as fixed. Real problems are often reframed after a few questions.
• Generating only one option, which means you are not deciding, just justifying.
• Ignoring constraints such as deadline, permissions and who has to approve.
• Never defining how you will check success, so nobody knows if the fix worked.
• Doing all the work silently, then presenting a conclusion nobody can follow. Write your steps down.

How this shows up in interviews and on the job

Behavioral interviews often include 'Tell me about a time you solved a difficult problem.' The framework doubles as a story outline: what the problem actually was, the constraints, the options you weighed, why you chose one, and how you knew it worked. Use the STAR method to keep it tight. In technical interviews, the interviewer usually cares about your process as much as your final answer; for practice material see Coding Interview Prep for Self-Taught Developers. On the job, a short write-up like the one above is often the difference between 'I looked into it' and being trusted with bigger problems.

How to practice

Take any small problem from the last week, such as a bug, a confusing report or a late deliverable, and write the six steps for it, even after the fact. For coding practice, pick one easy problem a day and say the six steps out loud before writing any code.