Blog
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 "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.
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.
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.
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.
Striver, Love Babbar and Apna College disagree on the order and overlap on 75 problems. Here is what happens when you merge all three into one 370-problem sheet and let the target role decide the order.
A frontend loop asks less DSA than a backend loop and a different slice of it: 6 core topics, 84 problems. Here they are in the order to practise them in JavaScript, plus the language details that cost people offers.
