To prepare for a technical interview when you are rusty, find out the format first, then spend your time on a short list of fundamentals for your role, practice solving problems out loud under a timer, and rehearse explaining your past work. Short, regular sessions over a few weeks are the usual advice, but how long you need depends on where you are starting and what the role asks.
Being out of practice is common after a long stretch in one job, a career break or a change of specialty. Rust is mostly about recall and speed, not lost ability. The aim is to bring the basics back to the surface and get comfortable thinking aloud, which is a separate skill from solving a problem alone.
Find out the format
Do not guess. Ask the recruiter or coordinator how many rounds there are and how long each is, whether there is live problem solving, a take-home task, a design discussion or a review of past projects, which tools or languages are allowed, whether you will use your own computer, a shared editor or a whiteboard, and whether there are topics to review. Recruiters often share this willingly, and preparing for the real format saves time: someone facing a project discussion should spend less time on puzzles.
The same logic applies outside software. In data analysis, engineering, accounting or IT support, swap in the relevant skills: spreadsheet modeling, circuit basics, reconciliation, troubleshooting steps.
Build an honest skills map
List what the posting emphasizes and rate yourself on each: solid, shaky or cold.
| Skill | Rating | Plan |
|---|---|---|
| Queries with joins and aggregation | Shaky | 20 minutes daily |
| Basic statistics | Cold | Review notes, 3 sessions |
| Communicating findings | Solid | Rehearse one example |
| A tool named in the posting | Cold | One small project |
This example is for a data analyst role. Spend most of your time on shaky skills the job clearly requires, since they tend to improve fastest. For cold skills, decide whether they are essential or whether you can honestly say you are new to them. Solid skills need only light review.
Build a plan that fits your life
Most coaching advice favors short, regular sessions over marathons, because recall improves with spacing. A sample three-week plan for someone with a regular job:
| Week | Focus | Time per day |
|---|---|---|
| 1 | Fundamentals, easy problems | 45 to 60 minutes |
| 2 | Medium problems, timed; start talking aloud | About 60 minutes |
| 3 | Mock interviews, weak spots, project stories | About 60 minutes plus 2 mock sessions |
With one week, compress it: two days of fundamentals, three of timed practice, a mock session and a rest day. With six weeks you can add depth, but do not stretch it so long you burn out. Preparing with limited time covers triage when the calendar is tight. Keep a simple log of what you practiced and what tripped you up; patterns such as missing edge cases or running out of time show up quickly.
Rebuild fundamentals first
Rust shows most in the basics. In programming, that typically means common data structures, basic algorithms, tracing code and the syntax of your chosen language. In other fields, it means the core concepts the job uses daily. A routine that works:
- Review notes or one textbook chapter for 20 to 30 minutes.
- Do two or three easy problems on that topic.
- Explain the concept aloud as if teaching a friend.
- Return to it two days later to check retention.
Starting easy rebuilds confidence and speed. Jumping straight to hard problems often ends in failure and the false conclusion that you are worse than you are.
Practice thinking out loud
In a live technical interview, the interviewer usually evaluates your process as well as your answer, and silent work gives them little to assess. A repeatable routine:
- Restate the problem in your own words.
- Ask clarifying questions about inputs, limits and edge cases.
- Describe a simple approach first, even if it is not optimal.
- Write or sketch the solution, narrating your reasoning.
- Test it with a small example and an edge case.
- Discuss improvements and trade-offs.
Narration feels odd at first. Practice alone by speaking aloud or recording yourself, and better still do mock interviews with a friend or colleague and trade sessions with a peer. Practicing in front of someone matters for a documented reason: a 2020 randomized study of 48 computer science students, presented at an ACM software engineering conference by researchers at North Carolina State University and Microsoft, found that participants solving a problem on a whiteboard while watched by an interviewer did much worse than those solving it in private, and reported higher stress. It was a small student study, so treat it as a sign that being observed is its own skill to rehearse, not as a measure of any individual.
If you get stuck, say so and describe what you have tried. Interviewers often give hints, and how you use them can matter. Recovering from a bad start applies here: pause, restate and take a simpler path.
Prepare to discuss past work
Many technical interviews include a deep dive into projects you have done, where experienced but rusty candidates have real material. For two or three projects, prepare the problem and why it mattered, your role and decisions, the technical choices and alternatives you considered, what went wrong and what you would change, and the result in plain terms. Be ready for “Why did you choose X over Y?” and “What would you do differently?” Admitting a trade-off or a mistake usually reads better than claiming a perfect decision. Do not claim work that others did.
A long gap or a change of field
Be upfront and brief: “I’ve been away from hands-on coding for two years, so I’ve spent the last month refreshing the fundamentals and building a small project.” A small finished project, even a modest one, shows current ability and gives you something concrete to discuss. Some interviewers will probe the gap; answer directly and say how you are closing it.
The final week and the day
In the last week, do shorter daily sets focused on speed and clarity, run one or two full mock interviews at the real length, review your log and set up your equipment: working internet, editor or whiteboard, water and a quiet space. The day before, do light review only; cramming new material tends to raise anxiety. What to do the night before an interview offers a calm checklist. On the day, warm up with one easy problem. Technical interviews usually end with your questions, and asking how the team reviews work or what the first months look like is a good start; see questions to ask at the end of an interview.
Common mistakes
- Jumping to hard problems too soon.
- Studying silently instead of speaking.
- Ignoring the real format.
- Cramming for hours instead of short, frequent sessions.
- Hiding gaps instead of acknowledging them briefly.
- Skipping rest, which makes careless mistakes more likely.
To track your practice sessions, use the technical prep tracker.
Where this comes from
This article draws on the 2020 study on stress and technical interview performance mentioned above (a randomized comparison of public and private whiteboard settings, by researchers at North Carolina State University and Microsoft), and on general interview and study-skills guidance such as spaced practice and mock interviews. The three-week plan is a sensible template, not a tested program, and no source can say how long any individual needs. Formats and expectations differ widely between employers, so rely on what your recruiter tells you.