Split View: 기술 면접 준비 플레이북 — 코딩·시스템 설계·행동 면접까지

The Tech Interview Playbook — Coding, System Design, and Behavioral

• Introduction — The Interview Is a Skill Separate from the Job
• What the Interviewer Actually Grades
• Coding Interviews — Study Patterns, Not Problems
• System Design — The 5-Step Frame
• Staple Questions by Role
• Behavioral Interviews — STAR and the Story Bank
• The 8-Week Countdown Plan
• When You Get Rejected
• References

Introduction — The Interview Is a Skill Separate from the Job

Some excellent engineers keep failing interviews; some average ones pass easily. It looks unfair, but there is a structural reason: an interview is an imperfect proxy for skill, and the proxy itself is a trainable skill.

This article covers how to prove the knowledge mapped in part 1 inside the interview room. It is organized around the four interview types — coding, system design, domain deep-dive, and behavioral — the signals each one grades, the staple questions per role, and an 8-week countdown plan.

What the Interviewer Actually Grades

Before the prep methods, understand the grader's rubric. What interviewers collect is not correctness — it is signal.

• Problem-solving process: how you structure an ambiguous problem; whether you ask clarifying questions about requirements.
• Communication: whether you think aloud; when stuck, whether you go silent or share your state.
• Trade-off sense: whether sentences like "this approach is faster but uses more memory" appear.
• Collaborativeness: when given a hint, whether you get defensive or absorb it.

This single shift of perspective changes the direction of your preparation. The goal is not to memorize perfect answers but to build the habit of consistently emitting good signals.

Coding Interviews — Study Patterns, Not Problems

The most common mistake in coding prep is grinding hundreds of problems. Problems are infinite, but patterns are finite — the frequent ones number about fifteen.

• Two pointers / sliding window — subarray and substring problems
• Hash maps — frequency, duplicates, two-sum family
• BFS/DFS — graph and tree traversal, island counting family
• Binary search — searching sorted spaces, "minimize the maximum" family
• Heaps — top-K, streaming median
• Dynamic programming — defining subproblems is the crux (knapsack, longest subsequence)
• Stacks — bracket matching, monotonic stacks
• Backtracking — generating permutations and combinations

The efficient study loop: pick one pattern, solve 3–5 representative problems of that pattern, and after each one verbalize which feature of the problem calls for that pattern. That verbalization converts directly into a strong interview signal: "sliding window came to mind because this is an optimization over contiguous ranges."

Two non-negotiables while practicing: time yourself (real rounds are 20–35 minutes) and explain aloud while solving. Solving quietly and solving while talking are different muscles. Make a habit of stating time and space complexity when you present the approach — not after the code is done.

System Design — The 5-Step Frame

Freezing in front of "design a URL shortener" usually comes not from missing knowledge but from missing a sequence. This 5-step frame is the standard.

1. Clarify requirements (5 min) — separate functional (what it does) from non-functional (scale, latency, availability). "Is this read-heavy or write-heavy?" is almost always a good question.
2. Back-of-envelope estimates (5 min) — daily users, QPS, storage, to an order of magnitude. The goal is not precision but judgments like "at this scale a single database will not do."
3. API and data model (5 min) — sketch three or four core endpoints and the table/key structure.
4. High-level design (10–15 min) — draw client → load balancer → services → storage, and explain what happens along each arrow.
5. Deep dives and trade-offs (10–15 min) — go deep where the interviewer probes: bottlenecks, failures, scaling. Cache invalidation, shard key choice, and consistency levels are the staples.

What differentiates candidates is not an inventory of components but the language of trade-offs: "a cache cuts read latency but adds invalidation complexity; this service is overwhelmingly read-heavy, so it is worth it." Practice justifying every choice against the requirements. For the perennial distributed-systems topics — retries and idempotency — this blog's payment idempotency piece is good pre-reading.

Staple Questions by Role

Keyed to the five roles of part 1, these are the domain deep-dive staples.

AI/LLM engineer

• When do you choose RAG vs. fine-tuning? (by knowledge-refresh frequency, cost, data volume)
• How do you reduce hallucination in production? (grounding, citations, eval sets)
• How do you regression-test the quality of an LLM feature?

Platform/DevOps/SRE

• p99 latency spiked right after a deploy — how do you diagnose? (the thought sequence: rollback decision → metrics → traces)
• A pod is in CrashLoopBackOff. Your first three commands? (kubectl describe, logs --previous, check events)
• How do you set an SLO, and what happens when the error budget is spent?

Security engineer

• Where do you store a JWT, and why? (comparing the attack surfaces of localStorage vs. cookies)
• Why does the authorization code flow need PKCE in OAuth 2.0?
• Threat-model a login feature. (credential stuffing, session fixation, enumeration)

Data engineer

• A large join is slow — what is your order of attack? (execution plan → partitioning/bucketing → broadcast join judgment)
• How do you handle late-arriving events in streaming aggregation? (watermarks, allowed lateness)
• How do you design an idempotent backfill?

Frontend

• What happens when you type a URL into the browser? (the universal question with adjustable depth)
• How do you diagnose and improve a page with bad LCP?
• How do you find and reduce unnecessary re-renders in React?

Rather than memorizing answers, turn these into lived stories by experimenting with this site's tools — the Kubernetes playground, SQL playground, auth & security lab, and Linux command quiz.

Behavioral Interviews — STAR and the Story Bank

Improvising a behavioral interview is like solving a coding problem cold. The preparation artifact is a story bank.

The STAR structure — Situation, Task, Action, Result. The two common failure modes: letting the situation eat half your time (finish it in 30 seconds), and narrating actions with "we" (the interviewer wants to know what you did).

Prepare six stories — ① a hard technical problem you solved ② a disagreement with a colleague ③ a failure or mistake ④ something you proactively improved ⑤ a prioritization call under deadline pressure ⑥ a time you failed to persuade but learned. Attach numbers to each (latency down 40%, on-call alerts from 30 to 5 per week) and credibility jumps.

In the disagreement story, what the interviewer grades is not who won but your ability to separate ego from ideas — a theme covered in depth in most arguments are about ego. "I was right and eventually pushed it through" reads junior; "I understood their constraint and we found a third option together" reads senior.

The 8-Week Countdown Plan

A standard plan counted back from interview day, assuming ~10 hours a week. Stretch or compress to fit.

• Weeks 8–7: audit the knowledge map for your target role and patch fundamental gaps. Rewrite the résumé so STAR material surfaces.
• Weeks 6–5: coding pattern block — 1–2 problems a day, organized by pattern. Rehearse the system design frame on three problems.
• Weeks 4–3: role deep-dive questions + write the story bank. At least two mock interviews (a peer or an AI interviewer — prompts in part 3).
• Week 2: repeat weak patterns only. Study the target company's tech blog and architecture (fuel for your reverse questions).
• Week 1: no new problems, review only. Fix your sleep rhythm — as the secrets of memory showed, sleep is when consolidation happens.
• Interview day: warm up with one light problem in the morning. Prepare 2–3 reverse questions for the end of each round ("what does on-call look like on this team?" works everywhere).

When You Get Rejected

Finally, the most important part. A rejection is not a verdict on your ability — it is one sample draw. With identical skill, outcomes swing on problem luck, interviewer style, and the day's condition. After a rejection there are only three things to do: write down every question you remember immediately, feed the sticking points back into your story bank and pattern list, and keep applying. As where confidence comes from argued, confidence is built from accumulated attempts. Interviews are exactly that.

References

• Tech Interview Handbook (free)
• Gayle Laakmann McDowell, "Cracking the Coding Interview"
• Alex Xu, "System Design Interview"
• The STAR method (MIT Career Advising)
• levels.fyi — level and compensation data