The Rusty Engineer's Coding Interview Comeback Plan

You've been a software engineer for years. You ship real systems. You review other people's code and know exactly what's wrong with it. And now you need to interview, and you're staring at a LeetCode Medium like you've never seen a graph before in your life.

This is the rusty engineer paradox. You built distributed systems. You've debugged production incidents at 2am. You once explained eventual consistency to your VP over Zoom. And yet. Reverse a linked list. Under time pressure. While talking.

The gap is real, specific, and there's a concrete path out of it.

Here's the coding interview comeback plan: what to do in order, how long each stage takes, and the signals that tell you you're actually ready.

Two Different Things Are Rusty. Only One of Them Matters.

Before you do anything, understand this. When engineers say "I'm rusty," they usually mean they can't implement Dijkstra's from scratch on demand. But there are two separate skills hiding in that complaint.

Recognition is knowing "this problem wants shortest path on a weighted graph, so that's Dijkstra." This fades slowly. It lives in long-term semantic memory, the same place where your understanding of how TCP/IP works lives. Senior engineers almost never lose this completely.

Recall under observation is producing correct, compilable code in 35 minutes while narrating your thought process to a stranger. This degrades fast, because it's a performance skill. It requires short-term working memory, syntax fluency, and the cognitive overhead of talking while thinking. It's like asking someone who hasn't played piano in three years to perform Chopin live. They probably remember the piece. They are going to fumble it badly.

A 2020 study found that technical interview performance drops by more than half in a public setting compared to a private one. Not because candidates didn't know the material. Because the stress of being watched consumed working memory that was supposed to be solving the problem.

So if you've been a senior engineer for years and you blank on a LeetCode Medium, it's probably not that you forgot the algorithm. It's that your live-performance layer has atrophied. The roadmap is built around that distinction.

Start Here: The Two-Hour Diagnostic (Your Ego Is Not Prepared)

Before planning your timeline, take a diagnostic. Open a blank editor, no hints, no submissions, just a timer. Solve these five problems cold, 20 minutes each:

1. Two Sum (HashMap lookup)
2. Reverse Linked List (pointer manipulation)
3. Binary Search on a sorted array
4. Number of Islands (BFS or DFS on a grid)
5. Climbing Stairs (1D DP)

This will be more humbling than expected. That's the point. The time pressure and the blank page reveal exactly which layer is rusty, and the answer is almost always: more rusty than you thought.

Score yourself honestly: 0-1 within time means heavy rust, plan for 10-14 weeks. 2-3 means medium rust, plan 6-10 weeks. 4-5 means light rust, plan 3-5 weeks.

The time estimates assume 1-2 hours per day on weekdays, more on weekends. Adjust for your actual schedule.

Phase 1: Rebuild the Vocabulary (Weeks 1-2)

The goal here isn't to solve hard problems. It's to rebuild the syntax layer so your hands can execute what your brain already knows.

Pick your language. Write code every day. Don't copy solutions. Producing information from memory beats reading it for retention. Watching editorial videos builds recognition. Typing from scratch builds recall. These are not the same thing, and the distinction matters more than most guides admit.

Solve the top 20 Easy problems from LeetCode's Grind 75 list, one or two per day. After reading each problem, close all resources and write the code yourself. If you're stuck after 15 minutes, write down where you're stuck, then look at a hint. Not the full solution.

Yes, Easy problems will feel embarrassing. That embarrassment is a symptom of the recognition-recall gap. The algorithm isn't gone. Your fingers just don't know it yet. By end of Week 2, you should be solving Easy problems in under 15 minutes without hesitation. The friction disappears faster than you think, and that's your green light to move on.

Phase 2: Rebuild the Patterns (Weeks 3-6)

This is the bulk of the work. There are 12 patterns that cover the vast majority of what you'll see in interviews:

1. Two Pointers
2. Sliding Window
3. Binary Search (and Binary Search on the Answer)
4. Linked List manipulation (fast/slow pointer, reverse)
5. Tree DFS
6. Tree BFS / Level-order
7. Graph BFS (shortest path, connected components)
8. Graph DFS (cycles, path existence)
9. Topological Sort
10. Heaps / Priority Queue
11. Dynamic Programming (1D and 2D)
12. Backtracking

The sequence matters. Spend three to four days per pattern. Start with patterns that have strong physical intuition (Two Pointers, Sliding Window) before moving to recursive patterns (Tree DFS, Graph DFS), and finish with DP and Backtracking, which require the most working memory.

One trap worth naming: interleaved practice (mixing patterns randomly) produces better long-term retention than blocked practice. But that's true for people who already have the pattern somewhere in memory. For rusty engineers rebuilding from scratch, start blocked. Do all your Two Pointer problems together until the shape is recognizable. Switch to interleaved in Phase 3.

For each pattern: do 5-8 Mediums, without tags if possible. After each problem, write a two-sentence summary of the pattern signal ("when I see X in the constraints, I think Y because Z"). This log becomes your most valuable review doc before the actual interview.

Phase 2 is done when you can look at an unseen Medium, identify the likely pattern within 3 minutes, and have a working solution within 25 minutes. Do this 5 times in a row on problems you've never seen. That's the milestone. Not a problem count.

If you find yourself grinding problems without this milestone appearing, the approach might need adjusting more than the volume.

Phase 3: Perform Under Pressure (Weeks 7-8)

Now you deliberately make it harder. The goal is to train the skill that's the real bottleneck: performing while being watched.

Switch to interleaved practice. No more pattern-tagged problems. Open random Mediums from your target company's tagged list on LeetCode (filter by last 6 months), set a 30-minute timer, and solve with no assistance.

Narrate out loud. This feels completely ridiculous. You are alone in your apartment talking to nobody about hash maps. Do it anyway. Say "I'm reading the constraints, I see the array is sorted, that suggests binary search or two pointers" as you go. Your neighbors will be confused. You will feel unhinged. This is the correct direction.

The skill of thinking and speaking simultaneously is its own trained behavior, not a natural byproduct of knowing the material. It has to be practiced in the same conditions as the real interview. The engineers who skip this phase are the ones who solve every mock prep problem at home and then go completely silent in the actual interview. Don't be that person.

Track your cold-solve rate: the percentage of Mediums you solve within time with no hints. When it hits 65-70%, you're ready for mock interviews.

If you're targeting mid-to-senior roles, run a system design track in parallel during this phase. One problem per week, 45 minutes, no references. At SpaceComplexity, the system design rounds are voice-based and scored on the same rubric your real interviewer uses, which is worth doing at least twice before applying.

Phase 4: Close the Gap (Weeks 8-10)

Mock interviews have a first-impression value. The first time a mock interviewer sees you, they react the same way a real interviewer will: fresh, unbiased, noting everything. You only get that once per person. Don't waste it when your cold-solve rate is 30%.

Start mocks at 65%+ cold-solve rate. Do two mocks per week for the last two weeks before you apply. One algorithmic, one system design. After each one, write down the single thing that would have most improved your score. One thing, not a list. Fix it before the next session. If you write a list of five things, you'll fix none of them and feel vaguely bad about all five. One thing.

The goal is to close the gap between your private performance and your public performance. Candidates who practiced in simulated public conditions, even just narrating to a camera, showed meaningfully less performance drop in real interviews. You're training the nervous system, not just the brain.

How to Know You're Actually Ready

Four concrete signals, not vibes:

Signal 1: Pattern ID in under 3 minutes. On unfamiliar Mediums. Not always, but most of the time. Still reading for 10 minutes before finding a direction means more Phase 2 work.

Signal 2: You can narrate without going silent. Test this: solve a problem you haven't touched in a week and record yourself. If you go silent for more than 30 seconds, that's a flag. The interviewer is writing "candidate went quiet" at that exact moment.

Signal 3: Mock feedback is execution-level, not structural. "Good approach, minor edge case missed" is fixable. "Unclear thinking, jumped to code before clarifying" means the live performance layer still needs work.

Signal 4: Mediums feel boring. Not a joke. Boredom here means the material no longer generates anxiety, which means it's moving into automatic processing. That's exactly where you need it on interview day. If a problem about sliding windows makes you feel nothing, you're ready.

A Note on Timeline Honesty

Most engineers underestimate their rust by about one phase. They think they need three weeks and actually need seven. The diagnostic feels easy because they've seen these problems before. The cold-solve rate tells the truth.

If you're working full time, add 30-50% to every estimate. The cognitive load of a day job is real. Thirty minutes of focused evening practice is worth more than two hours on a Saturday morning when you're depleted. There's a longer breakdown of how to structure DSA study alongside a full-time job if the schedule question is the hard part.

The engineers who struggle most are those who skip Phase 1 because it feels too easy, and Phase 3 because it's uncomfortable. Phase 1 is boring on purpose. Boring means the vocabulary layer is rebuilding without taxing your working memory. Phase 3 is uncomfortable because performance skills only get trained by actual performance. There's no shortcut that doesn't involve talking to yourself in an empty room and feeling like a complete idiot.

That phase works, though.

Coding Interview Comeback Plan: Quick Recap

• Diagnose first. Five problems, 20 minutes each, no hints. Your score maps to your timeline. Your ego will not enjoy this.
• Phase 1 (1-2 weeks): Vocabulary recovery. Easy problems, generation mode only, no watching solutions.
• Phase 2 (3-6 weeks): Pattern rebuilding. Blocked practice per pattern, milestone = 5 unseen Mediums with pattern ID under 3 minutes.
• Phase 3 (1-2 weeks): Synthesis. Interleaved, timed, narrated out loud to your confused houseplants. Target 65%+ cold-solve rate.
• Phase 4 (1-2 weeks): Mock interviews. Only start when cold-solve rate is solid. One fix per session.
• Ready when: Pattern ID under 3 minutes, can narrate without silence, mocks return execution feedback not structural feedback.

The rust is real. So is the recovery. The engineers who come back strongest are the ones who respect Phase 1 and don't skip Phase 3. The ones who skip Phase 3 are easy to spot: they solve problems fine at home and then inexplicably freeze the moment there's another person in the Zoom.

Further Reading

• Forgetting Curve - Wikipedia
• Spaced Repetition - Wikipedia
• Desirable Difficulties - Wikipedia
• Grind 75 study plan
• Tech Interview Handbook - Coding Interview Study Plan