Problem solving and critical thinking

In short

Problem solving is the disciplined process of defining a gap between what is happening and what should happen, finding its real cause, generating options and choosing and implementing the best one; critical thinking is the habit of examining the evidence, assumptions and reasoning behind any claim before accepting it. Indian placement processes test both directly — aptitude and reasoning rounds, data-interpretation sets, guesstimates and case questions, group discussions, and the "tell me about a difficult problem you solved" behavioural round at TCS, Infosys, Wipro, Accenture, Deloitte, ZS, EXL, Flipkart and the IIM-style consulting hirers. Universities examine the same material under AICTE's Universal Human Values, Soft Skills / Professional Communication and Design Thinking courses, and quality-engineering papers examine the seven QC tools, PDCA and DMAIC formally. On the job it is the core of production troubleshooting, bug triage, process improvement, audit and analytics work. The skill is not raw cleverness; it is a repeatable structure plus honest scepticism about one's own first answer.

Explained

What a problem is, and the types

• A problem is a gap between the *current state* and the *desired state* where the route to closing it is not obvious. No gap, no problem; obvious route, that is a task, not a problem.
• Well-defined (closed) problems have a known goal, known rules and a verifiable answer — a Sudoku, a circuit calculation, a coding question. Solved by algorithms (guaranteed if followed) or heuristics (rules of thumb, fast, not guaranteed).
• Ill-defined (open) problems have vague goals and no single right answer — "reduce attrition", "why are sales falling in Pune". Solved by structuring, not by formula.
• Convergent problems narrow to one answer; divergent problems need many ideas first. Most real work alternates: diverge to generate, converge to decide.
• Classification by cause: deviation (something that worked has stopped — look for what changed), chronic (it never worked well — needs redesign), target-setting (nothing is broken; the standard is being raised).
• Symptom vs cause vs root cause: the fever, the infection, the contaminated water. Fixing a symptom gives recurrence; the test of a root cause is that removing it prevents recurrence.

Critical thinking: claims, evidence, assumptions, fallacies

• Critical thinking works on arguments: a *conclusion* supported by *premises*. Evaluate three things — are the premises true, are they relevant, and do they actually support the conclusion?
• Deductive reasoning goes from general to specific; if the premises are true and the form valid, the conclusion is certain. Inductive reasoning generalises from cases — never certain, only probable. Abductive reasoning picks the most likely explanation for an observation (how doctors and debuggers think).
• Valid vs true: an argument can be perfectly valid and still reach a false conclusion if a premise is wrong. Exam trap: in reasoning questions you must accept the given premises *even if factually absurd*, and judge only whether the conclusion follows.
• Assumption — an unstated premise the argument needs. Finding it is the whole skill in CAT/placement "critical reasoning" sets: negate the candidate assumption; if the argument collapses, it was a required assumption.
• Inference — what must be true if the passage is true (not what is likely, not what the author would agree with).
• Common fallacies examined: *post hoc / correlation mistaken for causation*; *hasty generalisation* (small or biased sample); *ad hominem*; *straw man*; *appeal to authority or tradition*; *false dilemma* (only two options offered); *circular reasoning*; *slippery slope*; *sunk-cost reasoning* ("we have already spent ₹8 lakh, so continue").
• Common cognitive biases: *confirmation bias* (seeking only supporting data), *anchoring* (first number dominates), *availability* (recent/vivid cases feel frequent), *survivorship bias* (studying only the successes), *overconfidence*, *groupthink*, *framing effect*, *attribution error*.
• Debiasing moves that interviewers like to hear: write the hypothesis down first, actively look for disconfirming data, ask "what would change my mind", get an outside view / base rate, use a devil's advocate, run a pre-mortem ("it is six months later and this failed — why?").

The structured problem-solving process

1. Define the problem in writing, with a number, a place and a time: not "quality is bad" but "solder rejects on line 2 rose from 1.2% to 4.6% between 10 and 20 October". Use 5W1H (what, where, when, who, which, how much) and state what the problem is *not* — that bounds the search.
2. Contain / firefight if needed. Stop the bleeding (quarantine stock, roll back the deployment) — but record that this is containment, not a fix.
3. Break the problem down into mutually exclusive, collectively exhaustive (MECE) parts using an issue tree or logic tree: profit = revenue − cost; revenue = volume × price; volume = footfall × conversion. Each split must not overlap and must leave nothing out.
4. Prioritise where to look — Pareto (80/20) on the data, or an impact-vs-effort grid. Do not analyse all branches; kill branches with a quick estimate.
5. Form hypotheses about the cause and decide what data would confirm or refute each (hypothesis-driven working, standard in consulting and in good debugging).
6. Analyse to root cause using 5 Whys, fishbone, fault tree, or controlled experiments; verify by turning the suspected cause on and off.
7. Generate options — at least three, including "do nothing" as a baseline. Brainstorming rules: quantity first, no criticism during generation, build on others' ideas; brainwriting (written, silent) gets more ideas from quiet team members and avoids anchoring.
8. Evaluate and decide against stated criteria (cost, time, risk, feasibility, side-effects) — decision matrix, cost–benefit, payback.
9. Implement with a plan: action, owner, deadline (a one-page A3 report or 8D sheet holds all of this).
10. Check and standardise — measure the same metric after the change; if it worked, update the SOP, the checklist, the test suite, the training; if not, return to step 5. Without this step the organisation re-solves the same problem every year.

The analysis tools you must be able to draw and use

• 5 Whys — ask "why" repeatedly down a causal chain. Strength: fast, no tools. Limits: one chain only, stops wherever the asker runs out of knowledge, and can wander into blame. Rule: each "why" must be a verifiable cause of the line above, and never end at "the operator was careless".
• Fishbone (Ishikawa / cause-and-effect) diagram — effect on the spine, causes grouped under 6M: Man, Machine, Material, Method, Measurement, Mother Nature (environment); in services, the 4P version (Policies, Procedures, People, Plant/Technology). It *organises* possible causes; it does not prove any of them — you still need data.
• Pareto chart — bar chart of defect counts sorted descending with a cumulative line; identifies the "vital few" categories carrying most of the loss.
• Why-why vs what-if: why-why finds causes of a failure that happened; FMEA (Failure Mode and Effects Analysis) looks forward at failures that could happen, scoring Severity × Occurrence × Detection = RPN and acting on the highest.
• Seven basic QC tools (examinable as a set): check sheet, histogram, Pareto chart, cause-and-effect diagram, scatter diagram, control chart, stratification (flow chart/run chart in some lists).
• Improvement cycles: PDCA / Deming cycle (Plan–Do–Check–Act) for continuous improvement; DMAIC (Define–Measure–Analyse–Improve–Control) for Six Sigma projects on existing processes; DMADV for new designs; 8D for customer complaints in the auto industry; A3 for one-page Toyota-style problem reports; Kepner-Tregoe for formal problem analysis and decision analysis.
• Design thinking (AICTE courses, product roles): Empathise → Define → Ideate → Prototype → Test — iterative, user-evidence-led, good for ill-defined problems. TRIZ resolves engineering contradictions using inventive principles.
• Lateral thinking devices — challenge the assumption, reverse the problem ("how could we make attrition worse?"), random entry, Six Thinking Hats (white = facts, red = feelings, black = risks, yellow = benefits, green = ideas, blue = process).
• Systems thinking — look for feedback loops, delays and unintended consequences; a local fix often moves the problem elsewhere (reducing inspection headcount cuts cost and raises warranty claims two quarters later).

Quantitative judgement: estimation, data interpretation, decisions

• Guesstimates / Fermi estimation — decompose an unknown quantity into knowable factors, state every assumption aloud, keep round numbers, then sanity-check against something known. Marks go to the structure and the stated assumptions, not to the final number.
• Top-down (start from a population and apply rates) vs bottom-up (start from a unit and scale up); doing both and comparing is the strongest answer.
• Data interpretation discipline: read axes and units, check whether percentages share a base, distinguish absolute change from percentage change, percentage *of* from percentage *points*, mean from median (income and salary data are skewed — use median), and ratio from rate.
• Correlation is not causation. Alternatives to a causal story: reverse causation, a confounding third variable, selection effect, or coincidence. Causal evidence needs a controlled experiment, an A/B test, or at least a before-after with a comparison group.
• Decision tools: weighted decision matrix; cost–benefit with payback and NPV; expected value for risky choices; break-even analysis; opportunity cost (the next best forgone option) and sunk cost (already spent — irrelevant to the decision).
• Beware the small sample. A 4-out-of-5 success rate says very little; ask for the denominator and the time window before believing any rate.

Soft side: communicating and doing it in a team

• Present the answer top-down: conclusion first, then the three supporting reasons, then the detail (the "answer-first" or pyramid structure Indian consulting and analytics interviewers expect).
• Separate facts, inferences and opinions explicitly when reporting — mixing them is the commonest credibility failure in reviews and audits.
• Say what you do not know and how you would find out. "I would check the server logs for the same timestamp" scores better than an invented certainty.
• In group discussions, the structured contribution wins: define the terms, split the issue into two or three heads, give data, invite a quiet member, then summarise. Volume and interruption lose marks.
• In behavioural interviews, answer in STAR form — Situation, Task, Action, Result — with the result quantified, and add what you would do differently.
• Blameless analysis: in engineering post-mortems the question is "what in the system allowed this?" not "who did it?" — people hide information when blame is the output, and hidden information prevents root-cause analysis.
• Escalate with a recommendation attached, not just a problem: the gap, the cause so far, two options with costs, and what you propose.

Key points

• Problem - a gap between current and desired state with no obvious route; state it with a number, place and time.
• Root cause - the cause whose removal prevents recurrence; symptoms return, root causes do not.
• MECE - breakdown that is mutually exclusive and collectively exhaustive; the test of a good issue tree.
• Hypothesis-driven - guess the cause early, then collect the data that would *disprove* it.
• 5 Whys - chain of causal "why" questions; stop at a fixable system cause, never at "operator careless".
• Fishbone 6M - Man, Machine, Material, Method, Measurement, Mother Nature; organises causes, proves none.
• Pareto 80/20 - roughly 80% of the loss comes from about 20% of the causes; fix the vital few first.
• PDCA - Plan, Do, Check, Act; DMAIC - Define, Measure, Analyse, Improve, Control (Six Sigma).
• FMEA / RPN - forward-looking risk tool; RPN = Severity × Occurrence × Detection, act on the highest.
• Deduction / induction / abduction - certain if valid / probable generalisation / best available explanation.
• Valid vs true - a conclusion can follow correctly from a false premise; in reasoning sets, accept the premises as given.
• Assumption test - negate it; if the argument collapses, it was a necessary assumption.
• Fallacies - post hoc, hasty generalisation, false dilemma, straw man, ad hominem, circular, slippery slope, sunk cost.
• Biases - confirmation, anchoring, availability, survivorship, overconfidence, groupthink, framing.
• Correlation ≠ causation - consider reverse causation, confounders, selection effects before claiming a cause.
• Sunk cost is irrelevant; opportunity cost is the real cost of any choice.
• Guesstimate - decompose, state assumptions, round numbers, cross-check top-down against bottom-up.
• STAR - Situation, Task, Action, Result; the required shape for "describe a problem you solved".
• Standardise the fix - update the SOP, checklist or test; otherwise the same problem returns next year.

Formulas and examples

Example 1 — Pareto analysis on a month's defects. A Pune auto-components line logs 500 rejects:

Three of the six categories (50% of categories) carry 84% of the rejects. Fixing oversize and burr alone addresses 335/500 = 67% of the loss — so the team works on those two and ignores rust for now.

Example 2 — 5 Whys to a system cause. Problem: "the daily sales report reached management at 11:30 a.m. on 12 of 20 working days against a 9:00 a.m. commitment."

1. Why late? The data file arrives at 10:45 a.m. 2. Why? The warehouse system exports only after the night shift closes entries. 3. Why so late? Night-shift entries are typed from paper slips the next morning. 4. Why paper? The handheld scanners do not work in the cold-store aisle. 5. Why? Scanners were never specified for low temperature at purchase.

Root cause = a specification gap at procurement, not a lazy clerk. Fix: cold-rated scanners (₹1.2 lakh) plus a procurement checklist line for operating environment. Note the containment (an interim 7 a.m. data entry slot) is not the fix.

Example 3 — weighted decision matrix. Choosing a fix for a crashing payroll module. Criteria and weights: cost 0.3, time-to-fix 0.3, risk 0.25, long-term maintainability 0.15. Scores out of 10:

A: 0.3(9) + 0.3(9) + 0.25(4) + 0.15(3) = 2.7 + 2.7 + 1.0 + 0.45 = 6.85. B: 0.9 + 0.6 + 1.75 + 1.5 = 4.75. C: 1.5 + 2.1 + 2.0 + 1.2 = 6.8. A wins on this weighting, but A and C are within 0.05 — moving just 0.05 of weight from cost to risk flips the result (A 6.6, C 6.95), so the honest answer is "A for now, C planned", and the sensitivity must be stated.

Example 4 — expected value and sunk cost. A firm has already spent ₹8 lakh on a product. Completing it costs ₹5 lakh more and gives a 60% chance of ₹20 lakh revenue and 40% chance of ₹2 lakh.

• EV of revenue = 0.6 × 20 + 0.4 × 2 = 12 + 0.8 = ₹12.8 lakh; net of the ₹5 lakh still to spend = +₹7.8 lakh.
• The ₹8 lakh already spent is a sunk cost and does not enter the decision: continue, because ₹7.8 lakh > ₹0 from stopping. (If the remaining cost were ₹14 lakh, EV net = −₹1.2 lakh and stopping would be right, however much was already sunk.)

Example 5 — guesstimate with a cross-check. Estimate the number of 2-wheeler servicing jobs per day in a city of 40 lakh people.

• Top-down: assume 1 two-wheeler per 4 people → 10 lakh vehicles. Average 3 services a year (2 paid + 1 free/repair) → 30 lakh jobs/year ÷ 300 working days ≈ 10,000 jobs/day.
• Bottom-up cross-check: assume 700 workshops (authorised + local) × 14 jobs/day ≈ 9,800/day — the two agree within 2%, so the order of magnitude is sound.
• Sensitivity: if ownership is 1 in 6 rather than 1 in 4, the figure drops to about 6,700/day — stating this range is worth more than a single confident number.

Example 6 — percentage trap. Conversion rose from 4% to 5%. That is a 1 percentage-point rise but a 25% relative rise ((5−4)/4 × 100). Saying "conversion went up 1%" is wrong; both numbers must be labelled.

Where it is used

• IT services and product engineering (TCS, Infosys, Wipro, Zoho, Flipkart): incident triage, root-cause analysis documents after outages, blameless post-mortems, bug bisection, and five-why entries in RCA templates sent to clients.
• Manufacturing and automotive (Maruti, Tata Motors, Bajaj, Bosch, Hindustan Unilever): 8D reports for customer complaints, QC circles, kaizen and PDCA boards on the shop floor, FMEA before launch, Six Sigma Green Belt projects.
• Consulting, analytics and BFSI (Deloitte, EY, ZS, EXL, HDFC, ICICI): case interviews, issue trees, hypothesis-led analysis, fraud and dispute investigation, credit-decision reasoning.
• Operations, supply chain and e-commerce: delivery-delay root causes, inventory shortfalls, warehouse layout changes verified by before-after metrics.
• Public sector and audit (CAG audits, UPSC/state service decision-making papers, PSU management trainee roles): situation-judgement and ethics cases built on exactly this reasoning structure.
• Healthcare, power and process plants: incident investigation and fault-tree analysis under safety regulations; NABH and ISO 9001 audits require documented corrective and preventive action (CAPA) with root cause recorded.

Interview questions

• Q: What is the difference between a symptom and a root cause? A: A symptom is the visible effect; the root cause is the underlying condition whose removal stops the problem recurring. Treating symptoms gives repeat failures.
• Q: Walk me through how you would approach a problem you have never seen before. A: Define the gap with numbers and bounds, break it into MECE parts, prioritise with data, form hypotheses, test them against evidence, choose among at least three options on stated criteria, implement with owners and dates, then verify and standardise.
• Q: What are the limitations of the 5 Whys? A: It follows a single causal chain, so it misses multiple or interacting causes; it stops where the questioner's knowledge stops; and it drifts to blaming people instead of the system.
• Q: Why is correlation not causation? Give an example. A: Two variables can move together because of reverse causation, a confounder or selection. Ice-cream sales and drowning both rise in summer — heat is the confounder, not a causal link.
• Q: What is confirmation bias and how do you guard against it? A: Seeking only evidence that supports your belief. Guard by writing the hypothesis down, deliberately listing data that would disprove it, and asking a colleague to argue the opposite.
• Q: What does MECE mean and why does it matter? A: Mutually exclusive, collectively exhaustive — the branches of a breakdown must not overlap and must cover everything, so no cause is double-counted or missed.
• Q: A project has consumed ₹8 lakh and is half done. Does that affect whether to continue? A: No. Only the remaining cost against the expected future benefit matters; the ₹8 lakh is sunk. Letting it influence the decision is the sunk-cost fallacy.
• Q: Difference between PDCA and DMAIC? A: Both are improvement cycles; PDCA is a light, continuous loop for any improvement, while DMAIC is a structured, data- and statistics-heavy Six Sigma method for a defined project on an existing process.
• Q: How many two-wheelers are serviced in your city daily? A: Decompose: population → ownership rate → vehicles → services per year → working days, state every assumption, then cross-check with workshops × jobs per day; give a range, not one number.
• Q: How do you decide between two options that score almost the same? A: Test sensitivity — change the criterion weights slightly and see if the ranking flips; then pick on the criterion that matters most strategically, or choose the reversible option and plan a review date.
• Q: Tell me about a problem you solved. A: Answer in STAR — the situation and metric, your specific task, the actions you took including the analysis method, and the quantified result, plus one thing you would do differently.
• Q: What would you do if the data contradicted your manager's firm belief? A: Present the data neutrally with its method and limitations, show the specific analysis that led to the conclusion, offer a small test to settle it, and let evidence rather than argument decide.
• Q: Is brainstorming always the best way to generate ideas? A: No. Group brainstorming suffers from anchoring and loud voices; silent brainwriting first, then group discussion, usually produces more and more varied ideas.

Common mistakes

• Jumping to a solution before defining the problem — most wasted project effort starts here; a problem without a number, place and time cannot be verified as solved.
• Confusing containment with the fix and closing the issue after the firefight, so it recurs next month.
• Stopping the 5 Whys at a person ("operator was careless") instead of the system condition that allowed the error.
• Mistaking a tool for an answer — drawing a fishbone or a tree and never collecting data to narrow it.
• Quoting a rate without the denominator or the time window — "90% success" over 10 cases is not evidence.
• Mixing percentage and percentage points, or comparing means on skewed data where the median is the honest measure.
• Treating an argument as wrong because its conclusion is unpalatable — in reasoning questions, accept the given premises and judge only whether the conclusion follows.
• Not verifying after implementation, and not updating the SOP, checklist or test case — so the fix depends on the memory of the person who made it.
• Generating only one option and defending it, instead of comparing at least three including "do nothing".

Related topics

• Teamwork and collaboration · Time management and prioritisation · Data interpretation and quantitative aptitude · Logical reasoning for placements · Group discussion and interview skills · Quality management and Six Sigma.