Count All Possible Routes
Time O(nlogn + n * f) · Space O(n * f) · Official statement on LeetCode
Solutions
// Time: O(nlogn + n * f)
// Space: O(n * f)
class Solution {
public:
int countRoutes(vector<int>& locations, int start, int finish, int fuel) {
static const int MOD = 1e9 + 7;
int s = locations[start];
int f = locations[finish];
sort(begin(locations), end(locations));
start = distance(cbegin(locations), lower_bound(cbegin(locations), cend(locations), s));
finish = distance(cbegin(locations), lower_bound(cbegin(locations), cend(locations), f));
vector<vector<int>> left(locations.size(), vector<int>(fuel + 1)); // left[i][f], last move is toward left to location i by f fuel
vector<vector<int>> right(locations.size(), vector<int>(fuel + 1)); // right[i][f], last move is toward right to location i by f fuel
for (int f = 1; f <= fuel; ++f) {
for (int j = 0; j < locations.size() - 1; ++j) {
int d = locations[j + 1] - locations[j];
if (f > d) {
// left[j][f] = right[j+1][f-d(j, j+1)] + 2*right[j+2][f-d(j, j+2)] + ... + 2^(k-1)*right[j+k][f-d(j, j+k)]
// => left[j+1][f] = (ight[j+2][f-d(j+1, j+2)] + 2*right[j+3][f-d(j+1, j+3)] + ... + 2^(k-2)*right[j+1+k-1][f-d(j+1, j+1+k-1)]
// => left[j+1][f-d(j, j+1)] = right[j+2][f-d(j, j+2)] + 2*right[j+3][f-d(j, j+3)] + ... + 2^(k-2)*right[j+k][f-d(j, j+k)]
// => left[j][f] = right[j+1][f-d(j, j+1)] + 2*left[j+1][f-d(j, j+1)]
left[j][f] = (right[j + 1][f - d] + 2 * left[j + 1][f - d] % MOD) % MOD;
} else if (f == d) {
left[j][f] = int(j + 1 == start);
}
}
for (int j = 1; j < locations.size(); ++j) {
int d = locations[j] - locations[j - 1];
if (f > d) {
// right[j][f] = left[j-1][f-d(j, j-1)] + 2*left[j-2][f-d(j, j-2)] + ... + 2^(k-1)*left[j-k][f-d(j, j-k)]
// => right[j-1][f] = left[j-2][f-d(j-1, j-2)] + 2*left[j-3][f-d(j-1, j-3)] + ... + 2^(k-2)*left[j-1-k+1][f-d(j-1, j-1-k+1)]
// => right[j-1][f-d(j, j-1)] = left[j-2][f-d(j, j-2)] + 2*left[j-3][f-d(j, j-3)] + ... + 2^(k-2)*left[j-k][f-d(j, j-k)]
// => right[j][f] = left[j-1][f-d(j, j-1)] + 2*right[j-1][f-d(j, j-1)]
right[j][f] = (left[j - 1][f - d] + 2 * right[j - 1][f - d] % MOD) % MOD;
} else if (f == d) {
right[j][f] = int(j - 1 == start);
}
}
}
int result = int(start == finish);
for (int f = 1; f <= fuel; ++f) {
result = ((result + left[finish][f]) % MOD + right[finish][f]) % MOD;
}
return result;
}
};
// Time: O(n^2 * f)
// Space: O(n * f)
class Solution2 {
public:
int countRoutes(vector<int>& locations, int start, int finish, int fuel) {
static const int MOD = 1e9 + 7;
vector<vector<int>> dp(locations.size(), vector<int>(fuel + 1));
dp[start][0] = 1;
for (int f = 1; f <= fuel; ++f) {
for (int i = 0; i < locations.size(); ++i) {
for (int j = 0; j < locations.size(); ++j) {
if (i == j) {
continue;
}
int d = abs(locations[i] - locations[j]);
if (f - d < 0) {
continue;
}
dp[i][f] = (static_cast<int64_t>(dp[i][f]) + dp[j][f - d]) % MOD;
}
}
}
return accumulate(cbegin(dp[finish]), cend(dp[finish]), 0LL,
[&](const int64_t a, const int b) {
return (a + b) % MOD;
});
}
};
Beginner Explanation
What is Count All Possible Routes?
Count All Possible Routes (LeetCode #1575) is a Hard problem that primarily trains dynamic programming.
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 dynamic programming.
- 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: Math.
AlgoForge explanations are original teaching notes. Always open the official problem statement on LeetCode for constraints and examples.
Interview Walkthrough
Interview approach for Count All Possible Routes
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 dynamic programming.
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(nlogn + n * f)) and space (O(n * f)) 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(nlogn + n * f) time and O(n * f) space.
Pattern focus: dynamic programming
Use the pattern as a checklist:
- dynamic programming — 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(nlogn + n * f) |
| Space | O(n * f) |
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 Count All Possible Routes
- Skipping edge cases — empty collections, single-element inputs, max constraints.
- Wrong invariant for dynamic programming — 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 dynamic programming:
- 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: dynamic programming.
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 Count All Possible Routes in a second language (cpp, python).
- Drill 3–5 more problems tagged dynamic programming.
- 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 dynamic programming 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
Count All Possible Routes (#1575) — Hard. Pattern: dynamic programming. Complexity: O(nlogn + n * f) time / O(n * f) space. Re-derive the invariant before coding.
FAQs
What is the time complexity of Count All Possible Routes?+
The reference solutions aim for O(nlogn + n * f) time and O(n * f) space. Always re-derive complexity from the code you write in the interview.
What pattern does Count All Possible Routes use?+
It primarily maps to dynamic programming, within the broader topic of dynamic programming.
Is Count All Possible Routes 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/count-all-possible-routes/