Practising DSA under real timed, interview conditions
The problem with untimed grinding
Plenty of people solve three hundred problems and still struggle in a live round. The usual explanation is nerves. The more useful one is that their practice and the interview are different activities. In practice they can pause, look at the discussion tab after twenty minutes of struggle, run the sample cases a dozen times, and try five approaches because nobody is counting. In the interview they get one clock, one attempt at the real test cases, and an audience.
Untimed practice is not worthless. It is how you learn a new pattern for the first time. But it measures something other than what is tested, and it lets you believe you are ready on evidence that does not transfer.
What a clock actually trains
- Triage. With 25 minutes you learn to spend the first five on understanding and a plan, not the first twenty on a wrong idea.
- Commitment. You pick an approach and test it, instead of hovering between three.
- Recovery. When the first idea fails at minute twelve, you have to pivot calmly. That is only learned by being there.
- Honest self-assessment. A solve in 22 minutes and a solve in 24 with two bugs are different results, and the clock records it.
Hidden tests change how you think
Showing all the test cases up front teaches you to write code that passes those cases. A real interviewer has cases you have not seen: the empty list, the all-equal array, the maximum size, the off-by-one at the boundary. When the tests are hidden, you are forced to generate your own, which is a skill the interview rewards and the sample cases never build.
So the working rule is: before you run anything, write down your own edge cases and walk the code through them by hand. Then run it. If a hidden case fails, that is information about a habit, not just a bug.
How to build honest timed practice yourself
- Choose a problem you have not seen. Seen problems measure memory.
- Set a 25-minute timer. Close the discussion tab, the solutions, and any assistant. No autocomplete that writes whole lines for you.
- Plan on paper for five minutes: restatement, edge cases, brute force, the improvement.
- Code, test against your own cases, and stop when the timer ends, finished or not.
- Only then read a solution. Close it. Re-implement from scratch the same day, and again two days later.
- Log the problem, the pattern, the minutes, and whether you passed the cases you had not seen.
Be strict about what counts as a pass. A solution that works on your three examples is not a pass. A solution that works on the cases you wrote yourself, including the awkward ones, is. A solution that also survives the hidden cases is. If you only have access to the first kind of feedback, treat a pass as provisional and go looking for the case that breaks it before you move on.
The re-implementation step is the one people skip, and it is where most of the gain is. Reading a solution gives you the feeling of understanding. Rewriting it from a blank file tells you whether you have it.
On hints, and on being honest with yourself
Hints are fine if you count them. A solve with no hints is a different result from a solve with the third hint, and treating them the same is how people end up overconfident. A reasonable scheme is to unlock nothing for the first several minutes, then allow a nudge toward the right idea before the answer itself. Unaided works this way: three hints per problem, unlocking at 8, 15 and 20 minutes of the 25-minute clock, and none of them is the solution. The solve is recorded as unaided, hinted, or after the solution, and the difference shows in your progress.
This is the thesis behind the product: it is interview preparation that will not let you fake it. The clock only counts while you are working, pastes and tab switches are detected and recorded for you, and hidden tests decide whether you passed. Nothing about that is punishing. It is just accurate, and accurate is what you need two weeks before a real loop.
Which problems to time first
Start with patterns where a clean idea exists and the bugs are in the details. One surge allowed is a sliding window with a twist; Earliest time for k jobs asks you to binary search on the answer; Tag balance is a stack problem with edge cases; Team size is a tree recursion that rewards naming what each call returns. Each has three hints you can read after a timed attempt to see how close you were.
What to do next
If you only change one thing this week, put a timer on your next five problems and write down which ones you would have failed in an interview. That list is more useful than a hundred more solves. For a structured schedule, read the 15-day preparation plan. To have the clock, hidden tests and an adaptive plan done for you, begin here, see pricing, or try one problem free.