You've learned about constraints, trade-offs, and algorithm selection. Now we bring it all together into a systematic process for approaching any problem.

The difference between struggling with a problem and solving it efficiently often isn't algorithm knowledge—it's how thoroughly you read the problem statement.

Experienced engineers spend more time understanding the problem than writing code. Beginners do the opposite—and pay for it in debugging time.

This page teaches you to read problem statements like an engineer: extracting every piece of useful information, identifying hidden hints, and building a complete mental model before touching the keyboard.

Follow this systematic approach for every problem:

Phase 1: First Read — The Big Picture

Read the entire problem statement once without stopping. Don't worry about details yet. Goals:

• Understand what you're computing (input → output)
• Get a general sense of the problem domain
• Notice the overall structure

Phase 2: Second Read — Extract Key Information

Read again, this time annotating or noting:

1. Input format and constraints — What's given, how big
2. Output format and requirements — What to produce, precision
3. Examples — Work through each one
4. Edge cases mentioned — Special handling required
5. Guarantees and assumptions — What you can rely on

Phase 3: Analysis — Connect to Algorithms

With information extracted:

1. Calculate complexity ceiling from constraints
2. Identify problem pattern (search, optimization, counting, etc.)
3. Match to algorithm classes
4. Verify approach against examples

Phase 4: Planning — Before Coding

Outline your solution:

1. High-level approach
2. Key data structures
3. Edge cases to handle
4. Test strategy

Constraints are not just limits—they're information-dense hints about the expected solution.

Explicit Information:

Constraints:
1 ≤ n ≤ 10^5
1 ≤ a[i] ≤ 10^9
Time limit: 1 second
Memory limit: 256 MB

Direct implications:

• Array size up to 100,000 elements
• Values up to 1 billion (can't use as array indices; 32-bit int fits)
• Need O(n log n) or O(n) algorithm
• About 64 million integers fit in memory

Implicit Information:

Look for what constraints don't exclude:

• "1 ≤ n" → Array is non-empty (no need to handle empty case)
• "1 ≤ a[i]" → All positive (no zeros, no negatives)
• "a[i] ≤ 10^9" → Standard int/long handles it
• No "distinct" constraint → Duplicates possible, handle them

Reading Between the Lines:

Constraint Relationships:

When multiple constraints interact:

• "n, m ≤ 1000" → O(n × m) = 10^6 is fine
• "n ≤ 10^5, Q ≤ 10^5" → Need O(log n) per query or O(1) with preprocessing
• "Sum of n ≤ 10^6" → Multiple test cases but total work bounded

Sample inputs and outputs are more than just test cases—they're concrete demonstrations of the problem's requirements.

How to Analyze Examples:

Step 1: Verify your understanding

For each example:

• Can you trace from input to output manually?
• Does the output make sense given the problem description?
• If you can't reproduce the output, you've misunderstood something.

Step 2: Look for patterns

Across multiple examples:

• What's different between them?
• Do earlier examples show simple cases, later ones edge cases?
• Is there a progression in complexity?

Step 3: Identify edge cases

Examples often include:

• Minimum valid input (n = 1)
• Maximum appears early/late
• Empty or boundary conditions
• Cases where different rules apply

Example Analysis Walkthrough:

Problem: "Find the longest increasing subsequence."

Example 1:
Input: [10, 9, 2, 5, 3, 7, 101, 18]
Output: 4
Explanation: The LIS is [2, 3, 7, 101]

Analysis:

• Output is length, not the actual subsequence
• Multiple valid LIS might exist ([2, 5, 7, 101] also works)
• Sequence doesn't need to be contiguous
• "Increasing" means strictly increasing (3 < 7, not 3 ≤ 7)

Example 2:
Input: [0, 1, 0, 3, 2, 3]
Output: 4
Explanation: The LIS is [0, 1, 2, 3]

Analysis:

• Zeros are valid elements
• Selected elements are [0, 1, 2, 3] at indices [0, 1, 4, 5]
• Not [0, 1, 3, 3] because we can't use an element twice

Example 3:
Input: [7, 7, 7, 7, 7, 7, 7]
Output: 1

Analysis:

• All equal → LIS length is 1
• Confirms "strictly increasing" (7 is not less than 7)
• Edge case: single elements are valid subsequences

Many problems fall into recognizable patterns. Identifying the pattern quickly points you toward the right algorithm class.

Pattern 1: Search Problems

Keywords: "Find", "exists", "check if", "is there"

Characteristics:

• Looking for a specific element or condition
• Answer is often yes/no or the item itself

Common approaches:

• Linear search
• Binary search (if sorted or answer is monotonic)
• Hash table lookup

Example: "Find if any two numbers sum to target" → Two Sum pattern

Pattern 2: Optimization Problems

Keywords: "Maximum", "minimum", "largest", "smallest", "optimal"

Characteristics:

• Looking for best value among possibilities
• Often involves trade-offs

Common approaches:

• Dynamic programming (overlapping subproblems)
• Greedy (local optimal leads to global optimal)
• Binary search on answer (monotonic relationship)

Example: "Find minimum path cost" → Shortest path or DP

Pattern 3: Counting Problems

Keywords: "How many", "count", "number of ways"

Characteristics:

• Counting occurrences or combinations
• Often large answers requiring modular arithmetic

Common approaches:

• Combinatorics formulas
• DP for counting
• Inclusion-exclusion

Example: "How many ways to climb stairs" → Counting DP (Fibonacci-like)

Pattern 4: Construction Problems

Keywords: "Construct", "build", "create", "output the sequence"

Characteristics:

• Must produce an actual object, not just metrics
• Often multiple valid answers

Common approaches:

• Greedy construction
• Backtracking
• Incremental building

Example: "Construct a valid parentheses string" → Greedy or backtracking

Pattern 5: Decision Problems

Keywords: "Is it possible", "can we", "yes or no"

Characteristics:

• Binary output
• Feasibility checking

Common approaches:

• Try all possibilities (if small)
• Binary search on answer + feasibility check
• Greedy check

Example: "Can we partition into equal subsets" → Subset sum DP

Some important information is implicit or hidden in problem statements. Learn to spot it.

Hidden in Phrasing:

Hidden in Structure:

"Given a sorted array"

• Binary search is immediately available
• Don't waste time sorting again
• Two-pointer techniques apply

"Perform at most k operations"

• Binary search on answer often works: "Can we achieve X in at most k steps?"
• The answer is monotonic in k

"Transform A to B"

• Often symmetric: transforming A→B same as B→A
• Count differences might lead to answer

"n ≤ 20" for a complex problem

• Almost certainly bitmask DP or brute force
• Don't search for polynomial solutions

Hidden in Constraints:

Sum of n across test cases ≤ X

• O(n) or O(n log n) per case is fine overall
• Some cases might be large, some small
• Don't reset large data structures unnecessarily

Questions to Ask (in interviews):

When information isn't explicit:

1. Input clarifications:

   • Can the array be empty?
   • Are there duplicates?
   • Positive, negative, or both?
   • Are values bounded?

2. Output clarifications:

   • Return the value or the elements?
   • What if no solution exists?
   • Is there always exactly one solution?

3. Edge case handling:

   • What about n = 0 or n = 1?
   • Negative numbers? Zeros?
   • Maximum constraints?

4. Performance expectations:

   • What's the expected input size?
   • What's acceptable latency?

Asking these shows engineering maturity. Interviewers expect and appreciate clarifying questions.

Let's walk through a complete problem analysis using our framework.

Problem Statement:

Maximum Subarray Sum with at Most K Elements

Given an array of n integers and a positive integer k, find the maximum sum of any contiguous subarray containing at most k elements.

Input:

• First line: Two integers n and k (1 ≤ k ≤ n ≤ 10⁵)
• Second line: n integers a₁, a₂, ..., aₙ (-10⁹ ≤ aᵢ ≤ 10⁹)

Output: A single integer: the maximum sum.

Examples:

Input: 5 3
       1 -2 3 4 -5
Output: 7
Explanation: Subarray [3, 4] has sum 7 and length 2 ≤ 3

Input: 4 2
       -1 -2 -3 -4
Output: -1
Explanation: Best is single element [-1] with length 1 ≤ 2

Time limit: 1 second Memory limit: 256 MB

Phase 1: First Read — Big Picture

• Find max sum of subarray with restricted length
• It's an optimization problem (find maximum)
• Variant of classic max subarray

Phase 2: Second Read — Extract Information

Constraints:

• n ≤ 10⁵ → Need O(n log n) or O(n)
• k ≤ n → k can be as large as full array
• Values range: -10⁹ to 10⁹ → Use long long for sum (can overflow int)
• Time: 1 second → ~10⁸ operations budget
• Memory: 256 MB → ~64M integers

Input/Output:

• Input: array and k
• Output: single integer (max sum)
• Guaranteed: always at least one valid subarray (k ≥ 1, n ≥ 1)

From Examples:

• Example 1: All positive best → standard subarray works
• Example 2: All negative → must include at least one element; pick least negative

Hidden information:

• "Contiguous" → subarray, not subsequence
• "At most k" → can use fewer than k elements
• Negative numbers allowed → can't just take all

Phase 3: Analysis — Connect to Algorithms

Complexity ceiling:

• n ≤ 10⁵, need O(n log n) or better
• O(n²) brute force (all subarrays): 10¹⁰ → too slow ❌
• O(n × k) for each position check k windows: varies, can be slow
• O(n) or O(n log n): must be achievable

Pattern matching:

• Max subarray with length constraint → sliding window variant
• "At most k" suggests sliding window of variable size up to k

Approach ideas:

1. Sliding window with deque for max prefix sum

   • Use prefix sums
   • For each position i, find max(prefixSum[i] - prefixSum[j]) where i-k ≤ j < i
   • This is "max prefix sum in a sliding window" → monotonic deque
   • Time: O(n)

2. Simpler: just sliding window of size k, track max

   • Compute sum of windows up to size k
   • But we need ALL sizes 1 to k, not just k
   • Would be O(n × k) in naive form

Approach 1 (deque) is O(n)—let's verify.

Phase 4: Planning — Before Coding

High-level approach:

1. Compute prefix sums: prefix[i] = a[0] + ... + a[i-1]
2. Sum of subarray [l, r] = prefix[r+1] - prefix[l]
3. For each r, find min prefix[l] where r - k ≤ l ≤ r
4. Use monotonic deque to track min in sliding window
5. Answer = max over all (prefix[r+1] - min_prefix_in_window)

Edge cases:

• k = 1: each element is its own subarray
• k = n: classical max subarray (Kadane's would also work)
• All negative: must pick single least-negative element

Test strategy:

• Trace through both examples
• Test k = 1, k = n
• Test all positive, all negative, mixed

Now we're ready to implement—with full understanding of what we're building and why.

Learn from these common pitfalls:

Mistake 1: Skimming Too Fast

Problem: Missing key constraints or requirements.

Example: Problem says "return indices" but you return values. Problem says "1-indexed" but you output 0-indexed.

Fix: Read the output requirements carefully. Read them again before submitting.

Mistake 2: Not Working Through Examples

Problem: You think you understand but can't reproduce the sample output.

Example: Your understanding gives output 5, sample shows 4.

Fix: Trace through every example manually. If you can't match the output, you've misunderstood—stop and re-read.

Mistake 3: Ignoring Constraints

Problem: Implementing O(n²) when n = 10⁵.

Example: Writing nested loops without checking if it fits time limit.

Fix: Calculate n² immediately when you see n. Make it a habit.

Mistake 4: Assuming Information

Problem: "I assumed the array was sorted" / "I assumed positive numbers only."

Example: Using binary search on unsorted input.

Fix: Mark every assumption explicitly. Verify each against the problem statement.

Mistake 5: Solving a Different Problem

Problem: You solve something similar but not exactly the problem asked.

Example: Problem asks for "longest" but you compute "number of" longest.

Fix: After planning, re-read the problem and verify your approach answers the actual question.

Mistake 6: Missing Edge Cases in Examples

Problem: The examples often include edge cases that you ignore.

Example: One example shows n=1, but you don't test your code handles single elements.

Fix: Pay special attention to "trivial" examples—they're testing edge cases deliberately.

Reading a problem statement like an engineer means extracting maximum information before writing any code. This disciplined approach prevents wasted effort and leads to better solutions.

Module Conclusion:

This completes Module 7: Problem Constraints & Algorithmic Trade-offs. You now have a complete framework for approaching problems:

1. Understand constraints — Input size, time limits, memory limits
2. Let constraints guide selection — Match complexity to algorithm class
3. Navigate trade-offs — Time vs. space, complexity vs. simplicity
4. Choose wisely — Sometimes "slower" is better
5. Read like an engineer — Extract every piece of useful information

These skills transform problem-solving from guesswork into systematic engineering. Apply them consistently, and you'll approach every problem with confidence.