How to Prepare for a Coding Interview During the Holiday Break

The last two weeks of December have a strange shape. Standups get cancelled, replies slow to a trickle, and the pressure that usually pushes you through the week lifts for a moment. If you have interviews lined up for January, that quiet stretch is the best preparation window you will get all year. Spend it scrolling job boards and feeling vaguely guilty, and you will start the new year exactly where you are now.

The goal is not to grind for ten hours a day. It is to build a short routine you can actually keep, and to walk into your first interview having already solved problems out loud, timed yourself, and made your mistakes in private.

Decide What You Are Preparing For First

Before opening a single problem, write down three things: the roles you are targeting, the level you are applying at, and the language you will interview in. A junior front-end loop and a senior backend loop look nothing alike, and preparing for both at once usually means preparing for neither.

Then put a rough plan in a file with dates next to it. Something like: December 23 to 25, arrays, strings and hash maps; December 27 to 29, trees and graphs; January 2 to 4, dynamic programming and timed mocks; January 5, behavioral stories. A plan with dates is easy to adjust. A plan in your head quietly becomes a plan you never follow.

Solve Fewer Problems, Properly

Forty to sixty problems, each solved, reviewed and re-solved, will teach you more than two hundred problems skimmed with the solution open in another tab. Group them by pattern rather than by company, because interviews reuse patterns far more often than they reuse exact questions.

A reasonable short list to work through:

• Two pointers and sliding windows on arrays and strings
• Hash map counting, grouping and prefix sums
• Binary search, including binary search on the answer
• Breadth-first and depth-first search on trees, grids and graphs
• Heaps for top-k and merge problems
• Intervals and sorting-based scheduling
• Backtracking and recursion on subsets and permutations
• One- and two-dimensional dynamic programming

For each problem, work in this order: attempt it cold for twenty-five minutes, read the best solution, close the tab, then re-implement it from scratch two days later. That second attempt, done without hints, is where the pattern actually sticks. Keep one notes file with a single line per mistake — "forgot to handle empty input", "used a list where a set belonged" — and reread it before every mock.

Practise Talking While You Code

Most candidates lose points on communication, not on the algorithm. Interviewers need to follow your thinking, and they offer hints far more readily once you have shown them where you are. Train the habit out loud:

1. Restate the problem in your own words and confirm the output format.
2. Ask about input size, ranges, duplicates and empty inputs.
3. Describe a brute-force approach and its cost, then improve it.
4. Write the code while narrating the decisions that matter.
5. Trace a small example by hand, then state time and space complexity.

Record yourself on your phone doing one problem this way. It feels uncomfortable. It also exposes filler phrases, long silences and the moment you stop explaining right when things get hard — all fixable within a week.

Run Real Mocks, Not Pretend Ones

A mock interview is only useful if it is uncomfortable. Set a timer for thirty-five minutes, open a blank editor with no autocomplete, and do not run the code until you have finished writing it. Then review.

On Your Own

Pick a problem you have not seen, solve it under a timer with screen recording running, and watch the playback the next morning. Note where you lost time.

With Another Person

If you can find a friend, a former colleague or a study partner, run alternating mocks over a call. One person gives the problem and asks follow-ups; the other solves and explains. Rotate, then give each other two specific pieces of feedback. One session a week through the break is enough to make the real thing feel familiar.

Treat every mock as data, not as a verdict. The point is to find the failure mode while it is still cheap.

Do Not Skip the Non-Coding Rounds

Half the loop is usually behavioral, and it rewards preparation more than talent. Write six stories from your work history: a conflict you resolved, a project that failed, a time you disagreed with a decision, a moment you took ownership, something ambiguous you clarified, and work you were proud of. Structure each as situation, action, result, and keep them to about ninety seconds when spoken. Rehearse them aloud once. If you are interviewing at senior level, also be ready to walk through the design of a system you have actually built: the requirements, the data model, the bottlenecks, and what you would change now.

Keep the Schedule Human

Three to four focused hours a day is a serious amount of preparation. More than that tends to produce dim returns and a bad mood. Take one full rest day each week, sleep properly, and leave the evenings for the people you are on holiday with. If you notice persistent headaches, trouble sleeping or rising anxiety, treat that as a signal to slow down rather than push through, and speak to a doctor or another qualified professional if it continues.

Your First Week Back

Keep a small daily habit once the holidays end: thirty minutes of problems and one timed mock each week. Apply in batches of five or six rather than one at a time, so interviews land close together and your preparation stays warm. Reread your mistakes file the night before each loop, and arrive ready to think out loud.

The break will pass whether you use it or not. A couple of quiet weeks of deliberate practice is often the difference between walking into January nervous and walking in prepared.

Photo: Daniil Komov / Pexels