Lead: seven days and cold sweat
You are a Senior. You have designed fault-tolerant systems, mentored juniors, and shipped production at 3 a.m. And yet, seven days before a technical interview, cold sweat hits. Sound familiar?
There is no filler here. Only a tactical plan split into two routes: “I prepared” and “I am in panic.” Be honest about which state you are in, and follow that path.
While you read, do not grind alone: a mock with a live engineer catches pressure; an express quiz catches the topic you resist.
Scenario A: “I am in shape” (polish)
You have been solving problems for the last 1–2 months. Lists, trees, and DP no longer make your knees shake.
Your goal is not to learn something new. It is to polish what you already have.
- Audit the weak spots. Open the topic list. Which one makes you flinch? Give it two hours, no heroics. An express quiz finds the hole faster than another Hard “just in case”.
- Re-solve on a timer. Take a problem you solved a month ago and redo it from a blank page, clock running. If you finish in 25 minutes, you are ready. The same timer and voice are trained on a mock.
- The company. Stop drilling algorithms. Study the business. Why do they need a Senior? What hurts in their architecture? Stack and wording live in jobs; scaling pains at least in a write-up like Amazon system design.
Scenario B: “I did nothing” (triage)
The interview is in five days, and you opened LeetCode for the first time in a year.
Hard truth: in five days you will not become an algorithms guru.
Your way out: ask to slip the interview by 2–3 weeks. In our editorial experience, HR agrees about 90% of the time — that is risk judgment, not weakness. If a slip is impossible, go into hard time-economy mode: a quiz for the base and a mock for pressure, not segment trees.
Five-day intensive
If the slot did not move, cut volume, not sleep. Below is not a full-width table: four blocks, matching the original plan.
Day 1 — data structures
Do: Hash Maps (your Swiss Army knife), dynamic arrays, and basic tree ops (DFS/BFS). Check understanding with an express quiz, not a LeetCode clone.
Skip: segment trees, Cartesian trees, suffix arrays.
Day 2 — graphs and recursion
Do: write three path-finding algorithms. Drill the basic recursion template (base + step).
Skip: heavy graph algorithms (flows, bridges).
Day 3 — solution framework
Do: the interviewer dialogue (below). Solve not in silence — narrate every step on a mock.
Skip: solving problems in silence.
Days 4–5 — mock interviews
Do: 2–3 mocks with colleagues or on /find/. The goal is not to solve — it is to survive pressure and hear feedback.
Skip: watching walkthroughs without writing code.
Checklist: company research (48 hours out)
Do not walk in blind. A Senior has to understand the context. Cross-check the JD stack against the job catalog.
| What to check | Why a Senior needs it | Where to look |
|---|---|---|
| Tech stack | Show that you understand their choice — or can critique it with arguments. | Job description, the company’s GitHub. |
| Leadership principles (Amazon, for example) | The loop is built around these values. Bring stories from your experience that fit the frame. | Company site, Glassdoor. |
| Engineering blog | Show you know their current scaling problems. Mention it in System Design. | Medium, Habr, the company’s YouTube. |
Talking algorithm: not just “Fibonacci”
For a Junior the job is to write the code. For you it is to design the solution. Use this template every round and rehearse it on a mock.
- Clarify (3–5 min): “What are the memory limits? Will the input stream be large? Can it be null?”
- Brute force (2 min): “Naive is O(n²), but that would kill the database in production. Let’s think…”
- Optimize (10 min): “A hash table drops us to O(n). We spend memory. For this microservice that is fine: the data is small.”
- Write code: like a Pull Request. Guard clauses, clear names, comments on the hard blocks. Readability is easier to show once in a pet project.
- Test: not “it works”. Walk the edges:
[-1, -2], empty array, a huge number.
You cannot memorize a dialogue from a sheet
Brute force → O(n) sounds fake if you say it for the first time on the real loop. Say it out loud first.
Senior strengths (use them)
Forget the typing-speed race. Your edge is architectural thinking.
| Your skill | How to show it on an algorithms problem |
|---|---|
| Scale | “If the data grew 1000×, we would not use an ArrayList — we would partition or externally sort.” |
| Fault tolerance | “We need try-catch and retries with exponential backoff so we do not take the service down.” |
| Readability | “I will extract this into a private method so the main flow stays clean.” Same habit as building a pet project. |
| Debugging | If the code fails, do not panic. Use a mental debugger: walk the stack by hand, the way you do in production. |
Big O cheat sheet
Glance at this before you join Zoom. It is a memory aid, not a separate Space column.
| Structure / operation | Insert | Search | Delete |
|---|---|---|---|
| Array | O(n) | O(1) | O(n) |
| Linked list | O(1)* | O(n) | O(1)* |
| Hash table | O(1) | O(1) | O(1) |
| Binary search tree (BST) | O(log n) | O(log n) | O(log n) |
| Heap | O(log n) | O(1)** | O(log n) |
* Insert at head/tail. ** Min/max lookup.
Day X: morning ritual
Do not improvise.
- Warm-up. An hour before the call, open a simple problem (FizzBuzz-class) and write it — that wakes finger memory. We do not promise FizzBuzz in the catalog: any easy one in the express quiz will do.
- Quiet. Fifteen minutes out, close the laptop, look out the window. Slow the breath.
- Frame. You are not sitting an exam. You are having a technical meeting with a future colleague. You are both engineers.
Close: a philosophy that works
If you are reading this three days out — take a slow breath. You are not a robot that must emit a perfect solution in 20 minutes.
Seniors get hired for decisions under uncertainty and for communication. If you stall, say:
I see two paths. The first is hard but optimal and needs time. The second is simpler to ship and will be slow. What would you pick for your production system?
That fork shows seniority better than perfect syntax. That is how you should sound on a mock.
Want a free mock with feedback from a live engineer — not algorithm grinding: an account, a first mock, and a quiz on the weak spot.
Good luck. You will be fine. This is just a conversation between two professionals.
FAQ
Only one row stays open. This is last-week triage, not a glossary.
-
Interview in five days, have not opened LeetCode in a year — grind segment trees?
No. You will not become a guru in five days. Ask to slip 2–3 weeks first. If you cannot — triage: Hash Maps, DFS/BFS, a recursion template. Holes on an express quiz, pressure on a mock.
Link to this answer -
Is it embarrassing to ask HR to move the slot?
No. For a Senior that is adult risk judgment, not weakness. In our experience they usually agree. While you wait for the new date — a mock, not a marathon of walkthroughs.
Link to this answer -
Why not solve in silence if the code is correct?
A senior round grades design. Silence sounds like a Junior who just types. The talking algorithm is trained only out loud on a mock.
Link to this answer -
Is FizzBuzz an hour before Zoom beneath a Senior?
It is a motor-memory warm-up, not an exam. Then fifteen minutes of quiet. An easy problem in the express quiz instead of another Hard.
Link to this answer -
If I stall: stay quiet, or admit two paths?
Say the fork: hard-but-optimal versus simple-but-slow in prod — and ask which they would ship. That beats perfect syntax. That is how you should sound on a mock.
Link to this answer
This is a conversation between two professionals
Do the mock before Day X. Do not grind segment trees for five nights.
Related: When the interviewer is unprepared · STAR stories · Amazon system design · AI in interviews