You Solved the Consensus 75. What Next?
A practical guide for post-75 problem solvers: how to select the next 100 problems, when to start timed mocks, and why spaced repetition beats new questions.
On this page
Stop adding new problems to your queue. The marginal utility of solving problem number 76 is significantly lower than the utility of re-solving problem number 12 under time pressure. Your current bottleneck is not pattern recognition; it is execution speed and edge-case handling under stress.
The Role-Specific Pivot
The "Consensus 75" covers the foundational algorithms: sliding windows, two pointers, basic DP, and standard tree traversals. These are necessary but not sufficient for specialized roles. You must now filter your next 100 problems based on the specific technical stack of your target company.
If you are targeting a backend role at a high-scale infrastructure company, generic array problems are less valuable than problems involving concurrency, database indexing, or complex state management. Look for problems that require implementing a custom data structure, such as a Trie for autocomplete or a Segment Tree for range queries. These appear frequently in system-design-adjacent coding rounds.
If you are targeting a frontend or full-stack role, the algorithmic depth required is often lower, but the focus shifts to DOM manipulation, event loop understanding, and asynchronous data handling. In this case, spending 40 hours on advanced graph algorithms is a poor return on investment. Instead, focus on medium-difficulty problems that involve state synchronization or complex API response parsing.
For general software engineering roles, the next tier of difficulty involves multi-dimensional dynamic programming and advanced graph traversals (BFS/DFS with backtracking). A concrete example is the "Word Ladder" problem. It looks simple, but it requires a bidirectional BFS approach to pass within the time limit. If you solved it using a standard BFS and timed out, that is the gap you need to close. Do not move on to "Number of Islands" until you can derive the bidirectional optimization on a whiteboard without looking at the solution.
The Spaced Repetition Imperative
Most candidates make the mistake of treating the 75 problems as a checklist. They solve it, mark it done, and never look at it again. This is a critical error. Memory decay is exponential. If you solved a sliding window problem three weeks ago, you likely cannot reproduce the exact logic, variable initialization, and boundary conditions from memory today.
At this stage, revisiting solved problems is more important than solving new ones. Why? Because in an interview, you do not get to search for the solution. You get 20 to 40 minutes to recall the pattern, write the code, and debug it. If your recall is fuzzy, you will spend the first 10 minutes trying to remember if the window size is i - j + 1 or i - j. That hesitation kills your confidence and your time.
Implement a simple spaced repetition schedule. Take the 75 problems you have already solved. Re-solve 10 of them every day for the next week. Do not look at the code you wrote previously. Write it from scratch. If you get stuck, note exactly where your memory failed. Was it the base case? The pointer movement? The data structure choice? This diagnostic process is far more valuable than grinding through 50 new, easy problems that you will forget in a month.
When to Start Timed Mocks
Do not start timed mocks until you have completed the spaced repetition cycle for your core 75 problems. Mocks are for simulating pressure, not for learning new concepts. If you use a mock interview to learn a new algorithm, you are wasting the simulation. You will be too focused on the logic to practice the communication and time management aspects.
Start timed practice when you can solve any of the core 75 problems in under 15 minutes without looking at hints. This is the threshold where you are ready to test your speed. Begin with 45-minute sessions. Pick three random problems from your solved list. Solve them strictly within the time limit. If you fail, analyze whether it was a logic error or a speed error. Logic errors require more spaced repetition. Speed errors require more timed practice.
The Final 100 Problems
Once you have stabilized your recall on the core 75, select the next 100 problems based on the gaps identified in your timed sessions. If you consistently struggle with recursion, pick 30 recursion-heavy problems. If you fail at DP, pick 30 DP problems. Do not mix them randomly. Focus your effort on your weakest link.
The goal is not to have solved 175 problems. The goal is to have a reliable, fast, and accurate execution pipeline for the patterns that actually appear in interviews. Depth beats breadth at this stage.
Pick one problem from your original 75 that you solved two months ago. Set a timer for 15 minutes. Solve it from scratch. If you cannot, that is your next priority, not a new problem from a different sheet.
Keep going with practice problems and the online compiler.
Frequently asked questions
Why should I revisit problems I have already solved?
Memory decay occurs over time and revisiting problems ensures you can recall patterns and write code without hesitation during an actual interview.
How should I choose the next 100 problems to solve?
You should filter your next problems based on the specific technical stack of your target company and the gaps identified during your timed practice sessions.
When is the right time to start doing timed mock interviews?
You should begin timed mocks only after you have completed the spaced repetition cycle and can solve core problems in under fifteen minutes without hints.
What is the primary goal of the post 75 problem solving phase?
The goal is to build a reliable and fast execution pipeline for patterns that appear in interviews rather than just increasing the total count of problems solved.
Practice what you just read
Keep reading
Your First 30 DSA Problems: What Order to Solve Them In
Stop solving random problems. Master these 30 DSA questions in a specific order to build the logic patterns required for your coding interviews.
Common Edge Cases in DSA Problems and How to Catch Them
Master coding interviews on DSA Tracker by learning how to catch hidden edge cases like empty inputs, duplicates, and integer overflow before they break your.