Problem-Solving Framework
A structured approach to problem-solving demonstrates clear thinking and systematic analysis. This framework applies to coding, system design, machine learning, and product interviews.
Framework Overview
Step 1: Understand the Problem (2-3 minutes)
Confirm understanding before solving. Repeat the problem back to verify comprehension.
| Recommended | Not Recommended |
|---|---|
| Paraphrase the problem | Begin coding immediately |
| Identify inputs and outputs | Assume understanding without verification |
| Ask about edge cases | Focus on implementation details first |
Example:
Interviewer: "Design a URL shortener."
Response: "The system takes long URLs and creates short aliases. When users visit the short URL, they are redirected to the original. Should I focus on API design, storage layer, or the full system?"
Step 2: Clarify Requirements (3-5 minutes)
Clarifying questions demonstrate experience and prevent incorrect assumptions.
Questions by Interview Type
Coding Interviews:
| Question | Purpose |
|---|---|
| "What is the expected input size?" | Determines algorithm complexity requirements |
| "Are there memory constraints?" | Affects data structure selection |
| "Can the input be modified?" | In-place vs. new allocation |
| "How should invalid input be handled?" | Error handling expectations |
System Design Interviews:
| Question | Purpose |
|---|---|
| "What is the expected scale?" | Determines architecture complexity |
| "What are the latency requirements?" | Sync vs. async, caching needs |
| "Is consistency or availability more important?" | CAP theorem trade-offs |
| "Who are the users?" | Feature prioritization |
ML Interviews:
| Question | Purpose |
|---|---|
| "What data is available?" | Feature engineering options |
| "What is the latency budget for inference?" | Model complexity constraints |
| "How do we measure success?" | Metric selection |
| "How often does the model need retraining?" | Online vs. batch learning |
Product Interviews:
| Question | Purpose |
|---|---|
| "Who is the target user?" | Prioritization framework |
| "What problem are we solving?" | Scoping |
| "What are the business goals?" | Success metrics |
| "What are the constraints?" | Technical and resource limitations |
Step 3: Discuss Approach (5-10 minutes)
Describe the planned approach and rationale before implementation. This allows for course correction before significant time investment.
Approach Template
- State the high-level approach
- Explain the reasoning
- Acknowledge trade-offs
- Confirm before proceeding
Example (Coding):
"I will use a hash map to track frequencies, providing O(1) lookups. The trade-off is O(n) space, which is acceptable given the input size. Does this approach seem reasonable?"
Example (System Design):
"For the high-level architecture, I propose a distributed system with load balancing, a caching layer for frequent reads, and sharded databases for writes. I will sketch this out, then we can focus on the component of most interest."
Comparing Multiple Approaches
| Approach | Time | Space | Trade-off |
|---|---|---|---|
| Brute force | O(n^2) | O(1) | Simple, slow |
| Hash map | O(n) | O(n) | Fast, uses memory |
| Sorting + two pointers | O(n log n) | O(1) | Balanced |
Start with a working solution, then optimize.
Step 4: Execute (15-25 minutes)
Implement the solution while communicating throughout the process.
Execution Guidelines
| Recommended | Not Recommended |
|---|---|
| Verbalize thinking | Code silently |
| Write clean, readable code | Sacrifice readability for speed |
| Handle edge cases | Assume only happy path |
| Test incrementally | Wait until completion to test |
Handling Obstacles
Acceptable statements when encountering difficulty:
- "I am stuck on this edge case. Let me think through it aloud..."
- "A more efficient approach exists, but I will start with brute force and optimize."
- "Could you provide a hint about the data structure?"
Step 5: Verify and Iterate (5 minutes)
Walk through the solution with test cases. This demonstrates thoroughness and catches errors.
Verification Checklist
| Check | Method |
|---|---|
| Correctness | Walk through with a simple example |
| Edge cases | Empty input, single element, duplicates, large numbers |
| Complexity | State time and space complexity |
| Improvements | Note potential optimizations |
Example:
"Tracing through with input [2, 7, 11, 15], target 9:
First iteration: 2, looking for 7, add 2 to map. Second iteration: 7, looking for 2, found. Return [0, 1].
Edge cases: empty array returns empty, no solution returns empty.
Time complexity is O(n), space complexity is O(n) for the hash map.
Optimization: if the array were sorted, two pointers would reduce space to O(1)."
Common Mistakes
1. Not Asking Questions
Assuming requirements leads to solving the wrong problem. Clarify first.
2. Silent Problem-Solving
Silent thinking cannot be evaluated or guided. Verbalize the thought process.
3. Premature Optimization
Starting with a complex solution risks never completing it. A working O(n^2) solution is better than an incomplete O(n) solution.
4. Skipping Verification
Self-verification catches bugs before the interviewer does.
5. Ignoring Hints
Hints are guidance. Incorporate them into the approach.
Time Management
Coding Interview (45 minutes)
| Phase | Time | Focus |
|---|---|---|
| Understand and Clarify | 5 min | Questions, constraints |
| Approach | 5 min | Algorithm, trade-offs |
| Implement | 25 min | Clean, working code |
| Verify | 10 min | Test, edge cases, complexity |
System Design Interview (45 minutes)
| Phase | Time | Focus |
|---|---|---|
| Requirements | 5 min | Functional and non-functional |
| High-level design | 10 min | Components, data flow |
| Deep dive | 20 min | Focus areas of interest |
| Trade-offs and wrap-up | 10 min | Scaling, failures, alternatives |
ML System Design Interview (45 minutes)
| Phase | Time | Focus |
|---|---|---|
| Problem understanding | 5 min | Business context, constraints |
| Metrics | 5 min | Offline and online metrics |
| System architecture | 10 min | Pipeline, components |
| Model and features | 15 min | Feature engineering, model selection |
| Serving and monitoring | 10 min | Deployment, iteration |
Summary
| Principle | Description |
|---|---|
| Structure over speed | A methodical approach demonstrates stronger problem-solving than rushing |
| Clarify requirements | Asking questions shows experience and prevents mistakes |
| Communicate continuously | Silent problem-solving cannot be evaluated |
| Start simple | Get a working solution before optimizing |
| Verify work | Testing is part of the solution |
| Handle obstacles gracefully | Everyone encounters difficulty; recovery approach matters |