OneNoughtOne
0/361
Loading content...
Read aloud is unavailable in this browser.
The first moments after reading a problem statement are the most critical. What separates expert problem-solvers from novices isn't innate talent or memorization of solutions—it's the systematic set of questions they ask. While beginners often jump straight to coding or freeze in paralysis, experts engage in deliberate inquiry that rapidly narrows the solution space.
This interrogative discipline transforms problem-solving from an art into a science. By asking the right questions in the right order, you can decode any problem's underlying structure, regardless of how the problem is disguised or how unfamiliar it initially appears.
By the end of this page, you will possess a complete interrogative framework—a mental checklist of questions that reveal problem structure, highlight hidden constraints, expose algorithmic patterns, and guide you toward optimal solutions. This framework will become your most powerful diagnostic tool.
In interviews and competitive programming, the instinct to immediately start coding is powerful—and often disastrous. Consider two engineers facing the same problem:
Engineer A reads the problem, recognizes a vague pattern, and starts implementing a solution. Fifteen minutes in, they realize their approach won't handle a critical edge case. They backtrack, try another approach, and run out of time with a half-finished solution.
Engineer B spends the first five minutes asking clarifying questions—about constraints, edge cases, expected behavior. Only after systematically understanding the problem do they begin coding. They finish with time to spare and a correct, optimal solution.
The difference? Engineer B understood that problem-solving is an information-gathering exercise. The code you write is merely the output; the questions you ask determine whether that output is correct.
Expert problem-solvers don't memorize more algorithms—they ask better questions. The ability to rapidly extract the essential structure from a problem statement is a meta-skill that amplifies every other skill you possess. Master this, and algorithm selection becomes almost automatic.
The information asymmetry principle:
When you first read a problem, you have incomplete information. The problem statement contains explicit details, but also implicit assumptions, edge cases not mentioned, and constraints that hint at algorithmic requirements. Your questions bridge this gap.
Every question you ask falls into one of these categories:
The following framework represents the core questions every expert asks, organized by the phase of understanding. Internalize these, and you'll never face a problem without a structured approach.
Before you can solve a problem, you must precisely understand what you're receiving:
Misunderstanding the required output is surprisingly common and always fatal:
Constraints are not just restrictions—they're encrypted hints about the expected solution:
These are the internal questions you ask yourself—the diagnostic queries that map unfamiliar problems to known algorithmic patterns. They form the core of pattern recognition.
"Can I express the optimal solution to this problem in terms of optimal solutions to smaller subproblems?"
If YES → Dynamic Programming or Divide & Conquer candidate. If NO → Consider Greedy, Brute Force with pruning, or specialized algorithms.
Sub-questions for optimal substructure:
"Can I make a locally optimal choice at each step that leads to a globally optimal solution, without reconsidering past decisions?"
If YES → Greedy algorithm candidate. If NO → Greedy will likely fail; consider DP or exhaustive search.
Sub-questions for greedy:
"Do I need to explore all possible configurations or choices to find the answer?"
If YES → Backtracking, BFS/DFS state-space search, or bitmask enumeration candidate. If NO → There's likely a cleverer structural approach.
Sub-questions for decision space:
Beyond algorithmic paradigms, certain problem structures are so common that they deserve their own diagnostic questions.
| Question | If Yes, Consider | Examples |
|---|---|---|
| Does the problem involve connections/relationships between entities? | Model as a graph | Social networks, roads, dependencies |
| Is it about finding shortest/longest paths? | BFS, Dijkstra, Bellman-Ford, Floyd-Warshall | Route planning, min steps |
| Does it involve grouping connected components? | DFS/BFS traversal, Union-Find | Island counting, friend circles |
| Is there a notion of dependencies or ordering? | Topological sort, dependency graphs | Build systems, course scheduling |
| Are we optimizing a tree-like structure over the graph? | MST algorithms (Prim's, Kruskal's) | Network design, clustering |
| Is the graph bipartite? | Two-coloring, matching algorithms | Task assignment, interview scheduling |
| Question | If Yes, Consider | Examples |
|---|---|---|
| Am I looking for a contiguous subarray? | Sliding window, Kadane's algorithm, prefix sums | Max subarray, substring problems |
| Am I looking for elements that satisfy a condition? | Two pointers (if sorted), hash set for O(1) lookup | Two sum, pair finding |
| Do I need aggregate info over ranges? | Prefix sums, segment trees, BIT | Range sum queries |
| Is the problem about ordering/permutations? | Sorting, next permutation, backtracking | Rankings, arrangements |
| Is there a subsequence (not necessarily contiguous)? | Dynamic programming often required | LCS, LIS |
| Am I counting or enumerating subsequences? | Combinatorics, DP, inclusion-exclusion | Number of subsequences with property |
| Question | If Yes, Consider | Examples |
|---|---|---|
| Is the problem about path in a tree? | DFS from root, tree DP | Path sum, diameter |
| Do I need info from subtrees? | Post-order DFS, return values from recursion | Subtree sizes, validate BST |
| Is it about ancestry/descendants? | DFS with entry/exit times, LCA algorithms | Ancestor queries |
| Am I optimizing over nodes? | Tree DP with memoization | Max independent set on tree |
| Is the tree a BST? | Leverage sorted property, inorder traversal | BST search, range queries |
Edge cases are where solutions fail. Systematic edge case questioning prevents these failures before they occur.
The Universal Edge Cases:
These apply to virtually every problem:
Type-Specific Edge Cases:
For Strings:
For Graphs:
For Trees:
For Matrices:
Never assume the example test cases cover edge cases—they almost never do. Examples are designed to illustrate the problem, not to stress-test your solution. Always mentally generate your own edge cases before finalizing your approach.
Before coding, estimate whether your approach can meet the constraints. These questions guide that estimation:
For Time Complexity:
For Space Complexity:
| n Range | Feasible Complexity | Typical Algorithms |
|---|---|---|
| n ≤ 10 | O(n!), O(2^n × n) | All permutations, bitmask DP with extra work |
| n ≤ 20 | O(2^n), O(n² × 2^n) | Bitmask DP, meet-in-the-middle |
| n ≤ 100 | O(n³) | Floyd-Warshall, matrix DP |
| n ≤ 1,000 | O(n²) | Quadratic DP, all pairs |
| n ≤ 100,000 | O(n log n) | Sorting + binary search, segment trees |
| n ≤ 10,000,000 | O(n) | Single-pass algorithms, hash tables |
| n ≤ 10^18 | O(log n) | Binary search, math formulas |
Here is the complete protocol—a step-by-step process you should follow with every problem:
Step 1: Read Carefully (2 minutes)
Step 2: Characterize Input (1 minute)
Step 3: Clarify Output (1 minute)
Step 4: Constraint Decoding (30 seconds)
Step 5: Pattern Matching (2 minutes)
Step 6: Edge Case Generation (1 minute)
Step 7: Complexity Verification (30 seconds)
Only then do you write code.
This protocol takes roughly 8 minutes. In a 45-minute interview, that leaves 37 minutes to code—plenty for any reasonable problem. The alternative—jumping in without understanding—often wastes far more time in dead-end approaches and debugging.
Let's apply this framework to a sample problem:
Problem Statement: Given an array of integers, find the length of the longest increasing subsequence (LIS).
Applying the Inquiry Protocol:
| Question Category | Analysis |
|---|---|
| Input characterization | Array of integers. Constraints typically: n ≤ 10^4 or 10^5. Values may be negative. |
| Output specification | Return a single integer: the LENGTH (not the subsequence itself). |
| Constraint decoding | n ≤ 10^5 requires O(n log n). n ≤ 10^4 allows O(n²). |
| Optimal substructure test | YES: LIS ending at position i depends on LIS ending at earlier positions. → DP candidate. |
| Greedy test | NO (directly). But a greedy + binary search approach works for O(n log n). |
| Edge cases | Empty array → 0. Single element → 1. All same → 1. Strictly decreasing → 1. Already sorted → n. |
| Pattern match | Classic 1D/2D DP. Also: patience sorting / binary search optimization. |
Conclusion from analysis:
If n ≤ 10^4: Simple O(n²) DP works. Define dp[i] = LIS ending at index i. For each i, check all j < i where arr[j] < arr[i].
If n ≤ 10^5: Need O(n log n). Use patience sorting or maintain a separate array and binary search.
This entire analysis took about 3 minutes and completely determined the approach before writing any code.
Practice this framework on every problem you encounter—not just interview problems. After 50-100 problems with deliberate inquiry, the process becomes automatic. You'll find yourself pattern-matching faster and with greater accuracy than ever before.
We've established the foundational inquiry framework that drives expert problem-solving. Let's consolidate the key insights:
What's Next:
Now that you have the question framework, the next page dives deep into constraints as hints—the art of decoding problem constraints to immediately narrow down viable algorithmic approaches. You'll learn the precise mappings between constraint ranges and complexity classes, and how to use unusual constraints as signals for specific techniques.
You now possess the interrogative framework that separates expert problem-solvers from novices. Asking the right questions is more than half the battle. In the following pages, we'll deepen each dimension of this framework, starting with the powerful art of constraint analysis.