Last October I got a message on a Wednesday evening about a phone screen Friday morning. 37 hours, not quite 48. The company was one I actually wanted to work at. Here’s what I did and what I think matters most when time is short.
Most advice about technical phone screens assumes you have a month. This is not that.
What a technical phone screen actually looks like
Most phone screens run 30 to 45 minutes. You’ll get one or two coding problems, usually on a shared editor like HackerRank, CoderPad, or just a Google Doc (the Google Doc ones are still surprisingly common). The problems are almost always drawn from a fairly predictable set of patterns: arrays, strings, hash maps, trees, sometimes graphs at the harder end.
There’s usually five to ten minutes at the end for your questions. Don’t skip this part. Coming in with nothing signals low interest and low preparation.
You’re not expected to get everything perfect. You are expected to think out loud, catch your own bugs, ask clarifying questions before coding, and not panic when you’re stuck.
What to study when you only have two days
Do not try to cover everything. That’s the mistake that leads to unfocused practice where you touched 47 topics and actually absorbed none of them.
Here’s what actually comes up in phone screens at most companies:
- Arrays and strings: sliding window, two pointers, in-place modification
- Hash maps: frequency counting, lookup optimization, duplicate detection
- Linked lists: reversal, cycle detection, merge
- Binary search: the pattern, not just the textbook version
- Trees: BFS, DFS, basic recursive traversal
- Stacks and queues: bracket matching, monotonic stack basics
That’s it. If you can solve a medium-difficulty problem in each of these categories, you’re ready for most phone screens. Not all phone screens, but most.
For actual problems, the NeetCode 150 list (neetcode.io) is solid. The 2024 Stack Overflow Developer Survey found that 63% of developers use LeetCode-style practice for interview prep, so most interviewers have been through the same problems you’re practicing. They know the patterns too, which means they’re watching for understanding, not memorization.
A rough schedule that actually works
This assumes you get the news on Wednesday evening and interview Friday morning.
Wednesday evening (hours 0-4): do a diagnostic. Pick three easy and two medium LeetCode problems you haven’t seen before. Time yourself. Don’t look at solutions. This tells you where your gaps actually are, not where you think they are.
Thursday morning (hours 4-12): focus on your two weakest areas from the diagnostic. Do three problems in each area. Read the solution and the pattern explanation after attempting each one, even if you got it right. Understanding why the solution works matters more than just getting it working.
Thursday afternoon (hours 12-20): do two full mock problems under timed conditions, talking out loud the whole time. Record yourself if you can stand to watch it back. Most people talk too little during practice and then go silent in the actual interview. The silence is what kills you.
Thursday evening (hours 20-24): stop coding. Seriously. Review your notes on patterns. Write down the three things you most want to remember. Then sleep. Sleep is not optional for this. Sleep deprivation reduces working memory in ways that are genuinely measurable, and coding under pressure requires a lot of working memory.
Friday morning before the interview: no new problems. Do one warm-up you’ve already solved. Eat. Set up your environment the night before so you’re not troubleshooting audio settings with twenty minutes to go.
The mistakes that sink people who are otherwise ready
Going silent is the most common one. When you hit a wall and stop talking, the interviewer can’t tell if you’re thinking or lost. Keep talking. Say “I’m thinking about whether a hash map would help here” or “I don’t immediately see the optimization, let me think about the brute force first.” That running commentary shows process even when the answer isn’t there yet.
Skipping the clarifying questions is the second most common mistake. Before you write a single line, ask: what’s the input size? Can values be negative? Should I optimize for time or space? What should I return if the input is empty? This takes ninety seconds and prevents you from building the wrong solution for fifteen minutes.
Trying to write the optimal solution immediately, without first sketching the brute force, is also a trap. Interviewers generally want to see your thinking, and “I’d start with O(n^2) here to confirm the logic, then optimize” is a better opening than silence followed by a clever solution that has a subtle bug.
Testing with edge cases yourself, before the interviewer asks, is the move that separates candidates who get through screens from candidates who don’t. Test with null input, empty arrays, single elements, negative numbers. Walk through your solution with a specific example out loud.
One tool worth mentioning
Craqly does real-time mock interview feedback. If you’re doing your Thursday afternoon practice sessions and want feedback on your communication patterns, not just whether the code runs, it’s worth trying for the 48-hour crunch specifically. The most valuable thing in that final day is getting a read on whether you’re actually talking enough.
On the day itself
Log into the interview link two minutes early, not fifteen. Have a glass of water nearby. If your audio or the shared editor has a problem, say so immediately and clearly, don’t try to work around it quietly. Interviewers have seen every technical issue and they’re not testing your ability to troubleshoot a broken CoderPad session.
Ask your two or three prepared questions at the end. Make one of them specific to the team’s current work, something you found in their engineering blog or job description. It shows you spent actual time on this, which, in 48 hours, you did.