Escape the Spreading Fire
Time O(m * n) · Space O(m * n) · Official statement on LeetCode
Solutions
// Time: O(m * n)
// Space: O(m * n)
// bfs
class Solution {
public:
int maximumMinutes(vector<vector<int>>& grid) {
static const vector<pair<int, int>> directions{{0, -1}, {0, 1}, {-1, 0}, {1, 0}};
enum State {GRASS, FIRE, WALL, PERSON};
const int INF = 1e9;
const auto& bfs = [&]() {
unordered_map<int, unordered_map<int, unordered_map<int, int>>> time;
vector<tuple<int, int, int>> q;
for (int r = 0; r < size(grid); ++r) {
for (int c = 0; c < size(grid[0]); ++c) {
if (grid[r][c] == FIRE) {
q.emplace_back(r, c, FIRE);
}
}
}
q.emplace_back(0, 0, PERSON);
for (int d = 0; !empty(q); ++d) {
vector<tuple<int, int, int>> new_q;
for (const auto& [r, c, t] : q) {
for (const auto& [dr, dc] : directions) {
const int nr = r + dr, nc = c + dc;
if (!(0 <= nr && nr < size(grid) && 0 <= nc && nc < size(grid[0]) &&
grid[nr][nc] != WALL &&
((t == FIRE && grid[nr][nc] != FIRE) ||
(t == PERSON && (grid[nr][nc] == GRASS ||
(grid[nr][nc] == FIRE && nr == size(grid) - 1 && nc == size(grid[0]) - 1 && d + 1 == time[FIRE][nr][nc])))))) {
continue;
}
if (grid[nr][nc] != FIRE) {
grid[nr][nc] = t;
}
if ((nr == size(grid) - 1 && nc == size(grid[0]) - 1) ||
(nr == size(grid) - 1 && nc == size(grid[0]) - 2) ||
(nr == size(grid) - 2 && nc == size(grid[0]) - 1)) {
time[t][nr][nc] = d + 1;
}
new_q.emplace_back(nr, nc, t);
}
}
q = move(new_q);
}
return time;
};
auto time = bfs();
if (!time[PERSON][size(grid) - 1][size(grid[0]) - 1]) {
return -1;
}
if (!time[FIRE][size(grid) - 1][size(grid[0]) - 1]) {
return INF;
}
const int diff = time[FIRE][size(grid) - 1][size(grid[0]) - 1] - time[PERSON][size(grid) - 1][size(grid[0]) - 1];
return (time[FIRE][size(grid) - 1][size(grid[0]) - 2] - time[PERSON][size(grid) - 1][size(grid[0]) - 2] == diff + 2 ||
time[FIRE][size(grid) - 2][size(grid[0]) - 1] - time[PERSON][size(grid) - 2][size(grid[0]) - 1] == diff + 2)
? diff
: diff - 1;
}
};
// Time: O(m * n)
// Space: O(m * n)
// bfs
class Solution2 {
public:
int maximumMinutes(vector<vector<int>>& grid) {
static const vector<pair<int, int>> directions{{0, -1}, {0, 1}, {-1, 0}, {1, 0}};
enum State {FIRE = 1, WALL, PERSON};
const int INF = 1e9;
const auto& bfs = [&]() {
unordered_map<int, vector<vector<int>>> time;
time[FIRE] = vector<vector<int>>(size(grid), vector<int>(size(grid[0]), INF));
time[PERSON] = vector<vector<int>>(size(grid), vector<int>(size(grid[0]), INF));
vector<tuple<int, int, int>> q;
for (int r = 0; r < size(grid); ++r) {
for (int c = 0; c < size(grid[0]); ++c) {
if (grid[r][c] == FIRE) {
q.emplace_back(r, c, FIRE);
}
}
}
q.emplace_back(0, 0, PERSON);
for (const auto& [r, c, t] : q) {
time[t][r][c] = 0;
}
for (int d = 0; !empty(q); ++d) {
vector<tuple<int, int, int>> new_q;
for (const auto& [r, c, t] : q) {
for (const auto& [dr, dc] : directions) {
const int nr = r + dr, nc = c + dc;
if (!(0 <= nr && nr < size(grid) && 0 <= nc && nc < size(grid[0]) &&
grid[nr][nc] != WALL && time[t][nr][nc] == INF &&
(t == FIRE ||
d + 1 < time[FIRE][nr][nc] || (d + 1 == time[FIRE][nr][nc] && nr == size(grid) - 1 && nc == size(grid[0]) - 1)))) {
continue;
}
time[t][nr][nc] = d + 1;
new_q.emplace_back(nr, nc, t);
}
}
q = move(new_q);
}
return time;
};
auto time = bfs();
if (time[PERSON][size(grid) - 1][size(grid[0]) - 1] == INF) {
return -1;
}
if (time[FIRE][size(grid) - 1][size(grid[0]) - 1] == INF) {
return INF;
}
const int diff = time[FIRE][size(grid) - 1][size(grid[0]) - 1] - time[PERSON][size(grid) - 1][size(grid[0]) - 1];
return (time[FIRE][size(grid) - 1][size(grid[0]) - 2] - time[PERSON][size(grid) - 1][size(grid[0]) - 2] == diff + 2 ||
time[FIRE][size(grid) - 2][size(grid[0]) - 1] - time[PERSON][size(grid) - 2][size(grid[0]) - 1] == diff + 2)
? diff
: diff - 1;
}
};
Beginner Explanation
What is Escape the Spreading Fire?
Escape the Spreading Fire (LeetCode #2258) is a Hard problem that primarily trains breadth first search.
How to think about it
- Restate the goal in your own words before coding.
- Work a tiny example by hand so the invariant becomes obvious.
- Identify the pattern — this problem aligns with queue bfs.
- Only then translate the idea into code.
Why this problem matters
Hard problems force you to combine patterns and prove complexity carefully — interview gold. Official solution notes mention: BFS.
AlgoForge explanations are original teaching notes. Always open the official problem statement on LeetCode for constraints and examples.
Interview Walkthrough
Interview approach for Escape the Spreading Fire
Opening (30–60 seconds)
- Clarify inputs/outputs and edge cases (empty input, single element, duplicates, overflow).
- State a brute force so the interviewer knows you can solve it naively.
- Propose the optimal direction tied to queue bfs.
Core solution narrative
- Define the state you track (pointers, DP cell, set membership, stack top, etc.).
- Explain the transition when you process the next element.
- Call out time (O(m * n)) and space (O(m * n)) before coding.
- Code cleanly; narrate variable names.
What interviewers listen for
- Correctness on edge cases
- Complexity honesty
- Ability to discuss trade-offs (e.g., hash map space vs. sort + two pointers)
Follow-up questions they may ask
- Can you solve it with less memory?
- What if the input stream is infinite / doesn't fit in RAM?
- How would tests look for adversarial inputs?
Optimized Approach
Optimized solution notes
The reference solutions on AlgoForge target O(m * n) time and O(m * n) space.
Pattern focus: queue bfs
Use the pattern as a checklist:
- queue bfs — confirm the invariant holds after each step
Multiple methods appear in the source solutions — compare them and explain when each is preferable.
Implementation tips
- Prefer readable names over micro-optimizations in interviews.
- Extract helpers only when they clarify (e.g., expand-around-center, DFS visit).
- After AC-level logic, re-scan for off-by-one and null checks.
Complexity Analysis
Complexity
| Measure | Bound |
|---|---|
| Time | O(m * n) |
| Space | O(m * n) |
How to justify this in an interview
- Time: count loops, map/set operations, and recursive branching; state average vs worst case if relevant.
- Space: include hash maps, recursion stack, and output allocation when the problem asks for it.
If your implementation differs from the reference, re-derive big-O from your code — never memorize a complexity you cannot defend.
Common Mistakes
Common mistakes on Escape the Spreading Fire
- Skipping edge cases — empty collections, single-element inputs, max constraints.
- Wrong invariant for queue bfs — updating state too early or too late.
- Mutating input unexpectedly when the problem forbids it.
- Off-by-one in windows, ranges, or binary search bounds.
- Ignoring overflow / precision for integer arithmetic problems.
- Overengineering — jumping to an advanced structure when a simpler approach works.
Alternative Approaches
Alternatives
The source file includes more than one method. Compare:
- Primary optimized path — best complexity for typical interviews.
- Secondary approach — often brute force, sorting-based, or space-optimized variant.
Practice articulating when you would pick each (constraints, readability, follow-ups).
Edge Cases
Edge cases checklist
- Minimum input size
- Maximum input size / time limits
- Duplicates and already-sorted input
- Negative numbers / zeros (if applicable)
- Disconnected structures (graphs/trees)
- Single path vs branching recursion depth
Pattern Recognition
Spotting this pattern
Signal phrases that point to queue bfs:
- Sorted input or ability to sort without changing the answer class
- Need for contiguous subarray / substring → consider sliding window
- Need for O(1) membership → hash set/map
- Optimal substructure + overlapping subproblems → DP
- Connectivity / components → graph DFS/BFS or Union-Find
Primary topics: breadth first search.
Follow-up Interview Questions
Follow-ups
- How does the solution change if the input is a stream?
- Can you solve it in-place?
- What if duplicates must be handled differently?
- How would you parallelize the approach?
- Design tests that would break a buggy implementation.
Practice Recommendations
What to practice next
- Re-solve Escape the Spreading Fire in a second language (cpp, python).
- Drill 3–5 more problems tagged breadth first search.
- Teach the solution out loud in under 5 minutes.
- Add this problem to your revision calendar in 3 days and 14 days.
Visualization
Study checklist
- Read the official problem statement on LeetCode
- Solve on paper / whiteboard first
- Implement the queue bfs approach
- Verify edge cases from the checklist
- State time and space complexity aloud
- Compare with the AlgoForge reference solution
- Schedule a revision session
Revision notes
Escape the Spreading Fire (#2258) — Hard. Pattern: queue bfs. Complexity: O(m * n) time / O(m * n) space. Re-derive the invariant before coding.
FAQs
What is the time complexity of Escape the Spreading Fire?+
The reference solutions aim for O(m * n) time and O(m * n) space. Always re-derive complexity from the code you write in the interview.
What pattern does Escape the Spreading Fire use?+
It primarily maps to queue bfs, within the broader topic of breadth first search.
Is Escape the Spreading Fire good for interviews?+
Yes — as a Hard problem it is a solid practice target. Pair it with related problems in the same pattern family for spaced repetition.
Where can I read the official statement?+
Open the official LeetCode page for constraints and examples: https://leetcode.com/problems/escape-the-spreading-fire/