Here's the advice you'll find everywhere: "Do mock interviews with a friend." Great. Except you might not have a friend who's also preparing for interviews. Or your friends are, but they're in a different timezone. Or you're a career changer and you don't know anyone in tech yet.
The truth is, most people preparing for coding interviews are doing it alone. And nobody talks about how to actually make solo practice effective — because "grind LeetCode" is easier advice to give than "build a deliberate practice routine by yourself."
Solo practice can absolutely work. But it requires more structure than "do problems until you feel ready." Here's the system.
Why solo practice fails (and how to fix it)
Most people's solo practice looks like this: open LeetCode, pick a problem, stare at it, look at the solution after 15 minutes, think "oh that makes sense," move to the next one. Repeat for three weeks.
This doesn't work for the same reason watching cooking videos doesn't make you a better cook. You're consuming solutions, not building the skill of producing them under pressure.
| Passive practice (doesn't work) | Active practice (works) |
|---|---|
| Read problem, get stuck, read solution | Set a 25-minute timer. Attempt the problem fully before checking any hints. |
| Solve silently in your head | Solve out loud — explain every decision as if someone is watching. |
| Skip problems you cannot solve | Spend 10 minutes analyzing why you got stuck. What pattern did you miss? Write it down. |
| Do 5 problems in a row | Do 2 problems, then review both. What went well? What would you do differently? |
| Never revisit solved problems | Re-solve problems you struggled with 3 days later, without looking at your old solution. |
The difference between passive and active practice is the difference between "I've done 200 problems" and "I can solve a new medium in 25 minutes while explaining my reasoning." Interviewers don't care about the first number.
The solo mock interview protocol
The biggest gap in solo practice is simulating interview pressure. You can partially close this gap with a specific protocol. It's not as good as a real mock, but it's far better than solving problems in your pajamas with no timer.
Do this protocol 3 to 4 times per week. It takes about an hour per session including review. After two weeks, you'll notice a dramatic improvement in your ability to think and talk simultaneously — which is the actual skill being tested.
In a real interview, silence is a black box. The interviewer cannot see your thought process, so if you go quiet for two minutes, they have zero signal. Speaking your reasoning continuously gives them something to evaluate — and something to help you with if you go off track. Practicing this alone is awkward, but it is the single highest-leverage thing you can do.
Building a practice schedule that sticks
The biggest risk with solo practice isn't doing the wrong thing — it's quitting after a week because you have no accountability and no structure. Here's a schedule that's sustainable for 3 to 4 weeks.
Monday, Wednesday, Friday: Full mock sessions (60 minutes each)
Use the protocol above. One unseen problem, timed, solved out loud, with self-evaluation afterward.
Tuesday, Thursday: Pattern study (30 to 45 minutes each)
Focus on one pattern per session. Not grinding random problems — deliberately studying one technique:
For each pattern, do 3 to 4 problems. After each, write one sentence: "This was a [pattern name] problem because [reason]." The act of labeling patterns builds recognition speed, which is what you actually need under time pressure.
Saturday or Sunday: Review session (30 minutes)
Go through your notes from the week. Re-attempt one problem you struggled with — without looking at your old solution. If you can solve it smoothly now, the pattern has stuck. If you still struggle, that's your priority for next week.
How to evaluate yourself without a partner
The hardest part of solo practice is honest self-assessment. Here's a rubric you can use after each mock session:
| Dimension | What good looks like |
|---|---|
| Problem understanding | You restated the problem, asked yourself clarifying questions, and identified inputs/outputs before writing code. |
| Approach selection | You named your approach and explained why you chose it before coding. You considered at least one alternative. |
| Communication | You spoke continuously while solving. Minimal silence (under 30 seconds). You narrated decisions and tradeoffs. |
| Code quality | Your code is readable with reasonable variable names. Logic is clean. You did not write spaghetti while rushing. |
| Edge cases | You mentioned at least 2 to 3 edge cases (empty input, single element, duplicates, etc.) before or during coding. |
| Time management | You reached a working or near-working solution within 35 minutes. You did not spend 20 minutes on the wrong approach. |
Score each dimension 1 to 3. Track your scores over time. You'll see clear trends — most candidates have one or two dimensions that are consistently weak, and those are where focused practice pays off the most.
When solo practice isn't enough
Solo practice has a ceiling, and it's important to be honest about where that ceiling is.
What solo practice builds well:
- Pattern recognition speed
- Algorithm and data structure fluency
- The habit of thinking out loud
- Time management under pressure
- Comfort with ambiguity in problem statements
What solo practice can't fully replicate:
- The anxiety of someone watching you code in real time
- Adapting to an interviewer's hints and follow-up questions
- The conversational flow of a real interview
- Getting objective feedback on how you come across
At some point — ideally at least a week before your first real interview — you need to do at least 2 to 3 practice sessions with another person present. This could be a friend, a study partner from an online community, or an AI-powered mock interview tool. The presence of an observer changes your performance in ways you can't predict until you experience it.
If you don't know anyone preparing for interviews, check communities like Pramp (free peer mock interviews), Interviewing.io (anonymous practice with engineers), or Discord servers for interview prep. Even one session with a stranger is valuable because it introduces the social pressure component that solo practice misses.
The compound effect of showing up
Here's the thing about solo practice: the first week feels pointless. You're talking to an empty room, timing yourself on problems that feel too hard, and your self-evaluations are brutal.
The second week, something starts to shift. The patterns start clicking. The talking-out-loud thing becomes less awkward. You start recognizing problem types within the first 30 seconds of reading them.
By week three, you're solving mediums in under 30 minutes while narrating the whole thing. Not because you've memorized solutions, but because the fundamentals have become automatic and you can focus on reasoning instead of syntax.
That's the compound effect. It doesn't feel like progress day-to-day. But compared to where you were two weeks ago, it's a different person solving the problem.
The only requirement is showing up consistently. Three good sessions a week beats ten sessions in a weekend followed by a week of nothing. Build the habit. Trust the process. The interviews will feel dramatically different.
Rubduck gives you the benefits of a mock interview partner without needing to find one. An AI interviewer listens to your reasoning in real time and gives you feedback on communication, not just correctness. Try a free practice session here.