Voca Voca

How to Prepare for a Technical Interview in Two Weeks

2026-08-02 · 9 min read

Most technical interview advice assumes you have three months and no commitments. The common situation is different: you have an interview in two weeks, a full-time job, and evenings that are already partly spoken for.

Two weeks is enough to move meaningfully — not to transform, but to close the gap between what you know and what you can demonstrate under pressure. That gap is usually the actual problem. Most candidates who fail technical interviews are not incapable of the work; they're unpractised at doing it out loud, at speed, while being watched.

Diagnose before you study

Spend the first evening finding out where you actually stand. Not studying — measuring.

Do one medium problem in 35 minutes with a timer, out loud, writing real code. Then sketch one system design for something you use daily — a URL shortener, a chat app — for 30 minutes, also out loud.

You'll land in one of these:

Most people skip this step and default to grinding coding problems, which is frequently not where their gap is.

The coding side: patterns, not volume

You cannot do 300 problems in two weeks and you shouldn't try. Interview problems cluster into a small set of patterns, and recognizing the pattern is most of the battle.

The ones that cover the majority of what you'll be asked:

  1. Two pointers / sliding window — arrays and strings, subarrays, pairs
  2. Hash map for lookup — the answer to a surprising share of "do this in O(n)" problems
  3. Binary search — including on answer spaces, not just sorted arrays
  4. BFS / DFS on trees and graphs — grid problems are graph problems
  5. Recursion with memoization — the entry point to dynamic programming
  6. Heap / top-k — "k largest," "median of a stream"
  7. Intervals — merging, overlapping, scheduling
  8. Stack — matching, monotonic stack for next-greater problems

Do three or four problems per pattern, not thirty. After each one, the critical step: close the editor and say out loud what the pattern signal was. "Sorted array plus find a pair" → two pointers. "Shortest path in unweighted graph" → BFS. You're training recognition, not memorizing solutions.

Recognition transfers to unseen problems. Memorized solutions don't.

Talk while you code

This is the single highest-return change most candidates can make, and it costs no extra study time — just do your practice differently.

Interviewers are evaluating your thinking, and they can only see it if you externalize it. A silent candidate who solves the problem often scores lower than a talking candidate who doesn't quite finish, because the second one demonstrated a process.

The shape that works:

  1. Restate the problem. Thirty seconds. Confirms you understood it and buys thinking time.
  2. Ask about edge cases. Empty input? Duplicates? Size bounds? This is scored.
  3. State the brute force. "The naive approach is O(n²) — check every pair." Never skip this. It shows you understand the problem before optimizing.
  4. Then optimize out loud. "The repeated work is the inner scan. If I keep seen values in a hash map, that becomes O(1)."
  5. Say the complexity before coding. Time and space.
  6. Narrate while writing. "I'll handle the empty case first."
  7. Trace an example at the end. Walk through with real values. This catches off-by-ones and it's what a careful engineer does.

Practise this from day one. Adding narration to a solution you already have is much harder than building the habit.

System design in two weeks

You won't become good at system design in a fortnight. You can become structured, which is most of what's being assessed at mid-level.

Learn one framework and apply it every time:

1. Requirements (5 min). Functional: what must it do? Non-functional: how many users, read-heavy or write-heavy, latency tolerance, consistency needs. Ask — don't assume. Candidates who design before scoping lose points here.

2. Estimate (3 min). Rough numbers. 10M daily users, 10 actions each = 100M requests/day ≈ 1,200/sec average, call it 5,000/sec peak. Precision doesn't matter; showing you reason about scale does.

3. API (3 min). The three or four core endpoints. Concrete and quick.

4. Data model (5 min). What you store, and the access patterns. Then which store fits — and be able to say why, not just "I'd use Cassandra."

5. High-level design (10 min). Boxes and arrows. Client, load balancer, service, cache, database, queue. Keep it simple first.

6. Scale it (15 min). Now find the bottlenecks. Where's the hot path? What do you cache and how does it get invalidated? Do you shard, and on what key? What breaks when this component dies?

7. Trade-offs (5 min). Name what you gave up. "I've chosen eventual consistency for the feed, which means a user might briefly not see their own post — I'd fix that by reading their own writes from the primary."

That last step is what distinguishes senior candidates. Every design has costs; naming them unprompted signals experience more than any specific technology choice.

Do four or five designs, spoken, timed. URL shortener, chat app, news feed, rate limiter, file storage. The framework is the transferable thing.

The two-week schedule

Week 1

Week 2

Things that lose offers unnecessarily

Silence. Ten minutes of quiet thinking reads as being stuck even when it isn't. Narrate.

Optimizing immediately. Jumping to the clever solution without stating the brute force reads as pattern-matching rather than reasoning — and if the clever approach is wrong, you've shown nothing.

Not asking about edge cases. It's a scored dimension, not a formality.

Arguing with a hint. A hint means the interviewer wants you to succeed. Take it, say thank you, move on. Defending a wrong path is expensive.

Bluffing. "I haven't used Kafka, but I'd expect it to handle X — is that right?" is a strong answer. Inventing details about something you don't know is the fastest way to lose credibility, because interviewers usually do know.

Neglecting the behavioral round. Strong engineers get rejected for a flat "tell me about a conflict" answer more often than they realize.

The core point

Two weeks won't make you a better engineer. It will substantially improve your ability to demonstrate the engineer you already are — which is what's actually being measured and where most of the recoverable loss is.

Everything above depends on practising out loud, timed, uninterrupted. That is the part people skip, because it's uncomfortable and requires either a willing human or a tool that plays the role.

If you want the reps, Voca's mock interviews run live for a specific role, seniority, and format — technical, system design, behavioral, or mixed — and produce a written report afterward on what held you back. First round is free.

Whatever you use: out loud, timed, and don't skip the behavioral day.

Learn this properly — out loud

Name any skill and Voca builds the full course, then a live AI teacher teaches it to you phase by phase. Interrupt with a question anytime. You can also practise a job interview with AI and get a scored report.

Try 10 minutes free