Problem Solving Framework

1. Introduction

What is the Problem Solving Framework?

The Problem Solving Framework is a structured, repeatable step-by-step process used by senior engineers to tackle unfamiliar or complex programming problems. Instead of guessing code or typing immediately, it guides you from reading a prompt to delivering a clean, verified solution.

Why is it Important?

When faced with a tough problem in an interview or on the job, panic often leads to typing code blindly, missing hidden edge cases, and running out of time. A framework acts as your blueprint—it removes guesswork, keeps your thinking organized, and demonstrates strong engineering maturity to interviewers.

Where is it Used?

Coding Interviews: At FAANG and top tech companies, interviewers evaluate how you solve problems, not just whether your code compiles.

Production Engineering: Designing new microservices, debugging production outages, and writing software architecture specifications.

---

2. Mental Model

Imagine a Chef in a Restaurant Kitchen.

When a customer orders a dish, a master chef doesn't start throwing random ingredients into a hot pan! 1. They read the order carefully (Are there allergies? Is it gluten-free?). 2. They check the ingredients on hand. 3. They plan the recipe steps in their head. 4. Only then do they turn on the stove and start cooking.

In software, jumping straight to code is like throwing raw food into a fire without a recipe—it usually burns! The Problem Solving Framework is your master recipe.

---

3. Concept: The 8-Step Framework

Here is the exact step-by-step framework to approach any coding problem:

Step 1: Understand the Problem

Read the problem twice. Rephrase the goal in your own words. Identify what data comes in (inputs) and what result must go out (outputs).

Step 2: Explore Concrete Examples

Work through small, manual examples on paper.

Start with a simple typical case.

Test a small case (1 or 2 elements).

Test edge cases (empty input, negative numbers, duplicates).

Step 3: Break Down the Goal

Identify the constraints. Ask clarifying questions:

Can the input array be empty?

Are integers positive, negative, or zero?

Are there duplicates? Is the array sorted?

Step 4: Start with a Brute Force Solution

Always state the simplest solution first, even if it is slow (like using nested loops). This proves you can solve the problem and gives you a baseline to improve upon.

Step 5: Optimize the Strategy

Ask: "Where is the bottleneck in my brute force solution?"

Can I use a HashMap to speed up lookups from O(N) to O(1)?

Can sorting the input unlock a Two Pointers or Binary Search approach?

Can I avoid redundant work with Sliding Window?

Step 6: Write Pseudocode / Outline the Steps

Write plain English steps before touching syntax. This structures your logic without worrying about language syntax errors.

Step 7: Implement Clean Code

Translate your pseudocode into code. Use clear variable names (leftPointer, currentSum), modular structure, and guard clauses for invalid inputs.

Step 8: Walkthrough & Test Edge Cases

Dry-run your code with an example using line-by-line tracing. Check:

Empty inputs (null, [], "")

Single element inputs

Off-by-one boundary conditions (i <= n vs i < n)

---

4. Visuals

Framework Comparison: Unstructured vs Structured

---

5. Real-World Examples

Google Search: When you type a query, search engineers don't search billions of web pages linearly. They clarify filters, use indexed data structures (Tries & Inverted Indexes), and optimize for sub-millisecond responses.

Uber Routing: Finding the shortest route between a driver and rider uses graph algorithms (Dijkstra/A). Engineers first establish edge conditions (one-way streets, traffic delays) before writing the pathfinding logic.

---

6. Interview Perspective

How Interviewers Ask This Topic

Interviewers deliberately give underspecified or ambiguous problem statements (e.g., "Find two numbers that add up to a target"). They are waiting to see if you ask questions before coding!

Common Mistakes

Warning: 1. Silent Coding: Typing for 10 minutes without speaking. Interviewers cannot grade your thought process if you stay silent.

> 2. Ignoring Constraints: Not checking if numbers can be negative, leading to broken assumptions.

> 3. Giving Up on Brute Force: Refusing to state a simple O(N²) solution because you think it's "too easy," ending up with 0 working code.

Important Interviewer Tips

Talk Out Loud: Think of the interview as a collaborative pair-programming session with a senior colleague.

Validate First: Always ask "Does this approach sound good to you before I start coding?"*

---

7. Summary

Never code immediately: Spend the first 5 minutes understanding and planning.

Clarify inputs, outputs, and constraints before designing a solution.

State a brute force solution first to guarantee a working baseline.

Optimize bottleneck areas using data structures (HashMaps, Heaps, Pointers).

Dry-run your code with edge cases before declaring completion.

---

8. Quiz

Question 1: What is the very first step you should take when given a coding problem?

Answer: Read the problem carefully, rephrase the goal in your own words, and ask clarifying questions about inputs, outputs, and constraints. Never start coding immediately.

Question 2: Why is it valuable to mention a brute force solution during an interview?

Answer: It demonstrates that you can solve the problem, establishes a working baseline, and gives you a clear target for optimization.

Question 3: What should you do if you get stuck while trying to optimize a solution?

Answer: Work through small manual examples on paper, look at where redundant work is happening, and ask yourself what data structure (e.g., HashMap, Set, Stack) could eliminate that redundant work.

Question 4: What are "edge cases" and why are they important?

Answer: Edge cases are extreme or unusual input scenarios (e.g., empty arrays, single elements, negative numbers, duplicates). Testing them ensures your code is production-ready and resilient.

Question 5: What is "dry-running" code?

Answer: Manually stepping through your code line by line with a sample input, tracking variable values on paper to catch bugs before executing or submitting.