To prepare for coding interviews, and for the behavioral and design rounds that come with them, you need to get ready for three different tests: solving a problem in code while explaining your reasoning, answering behavioral questions with specific stories, and, from mid-level up, designing a system and defending its trade-offs. The most efficient preparation is to learn the common problem patterns instead of memorizing solutions, practice out loud under a timer, and build a small bank of stories before you need them.
This guide covers all three, with a study plan you can follow. If your interviews are remote, pair it with our interview tips for your first remote job, which cover video setup, take-home assignments, and written evaluations.
What a typical interview loop looks like
Every company runs its process differently, but most loops are built from the same parts:
| Stage | What’s being tested | How to prepare |
|---|---|---|
| Recruiter screen | Basic fit, logistics, salary range, communication | A two-minute introduction, your reasons for applying, your salary range |
| Online assessment | Solving standard problems against a timer | Timed practice in a similar environment |
| Technical screen | Coding while an interviewer watches and asks questions | Practicing out loud, ideally with another person |
| Take-home assignment (some companies) | Code quality, structure, tests, documentation | A clean project setup you can start from |
| Final loop | More coding, behavioral rounds, and system design for mid-level and above | Everything in this guide |
| Hiring manager conversation | Motivation, team fit, how you like to work | Your stories, plus questions about the team |
Ask the recruiter what the loop includes and what each round focuses on. Most will tell you, and it lets you spend your preparation time where it counts.
Coding interviews: learn patterns, not problems
Interview problems seem endless, but most are variations on a small set of patterns. Once you can recognize the pattern from the problem statement, you’re adapting a known approach instead of inventing one under pressure.
| Pattern | Clues in the problem | Typical examples |
|---|---|---|
| Hash map counting and lookup | “Find a pair”, “count occurrences”, “have we seen this before?” | Two sum, grouping anagrams, first unique character |
| Two pointers | Sorted input, pairs, comparing from both ends | Pair with a target sum in a sorted array, valid palindrome |
| Sliding window | “Longest or shortest subarray or substring that…” | Longest substring without repeating characters, minimum window substring |
| Prefix sums | Repeated range sums, “subarray sum equals k” | Range sum queries, counting subarrays with a given sum |
| Binary search | Sorted input, or “find the smallest value that works” | Search in a rotated array, minimum shipping capacity within D days |
| Stack | Matching brackets, “next greater element” | Valid parentheses, daily temperatures |
| BFS and DFS | Grids, trees, graphs, shortest path in an unweighted graph | Number of islands, level-order traversal, course schedule |
| Heap | “Top k”, “k closest”, merging sorted lists | Kth largest element, merge k sorted lists |
| Intervals | Start and end times, overlaps | Merge intervals, meeting rooms |
| Backtracking | “All combinations, permutations, or subsets” | Subsets, permutations, word search |
| Dynamic programming | “Number of ways”, “minimum cost”, overlapping subproblems | Climbing stairs, coin change, longest common subsequence |
Alongside the patterns, know the time and space complexity of basic operations in your language: array access, hash map and set lookups, sorting, and heap push and pop. You’ll be asked for the complexity of every solution you write.
Pick one language and stick with it. Python is a popular interview choice because it’s concise, but the right choice is the language you can write without looking things up. Learn the parts of its standard library that come up in interviews; in Python, that means collections (deque, Counter, defaultdict), heapq, and bisect.
A study plan you can follow
The Tech Interview Handbook study plan suggests about three months at roughly 11 hours a week, built around its Grind 75 problem list. If you have less time, compress it into eight weeks with this shape:
| Week | Focus |
|---|---|
| 1 | Arrays, strings, hash maps; a Big-O refresher |
| 2 | Two pointers, sliding window, prefix sums |
| 3 | Binary search, stacks, queues, linked lists |
| 4 | Trees and graphs (BFS and DFS), heaps |
| 5 | Intervals, backtracking, and an introduction to dynamic programming |
| 6 | Timed, mixed practice across all topics; your first mock interview |
| 7 | Behavioral stories and, for mid-level roles, system design |
| 8 | Mock interviews, re-solving problems you got wrong, and rest before the real thing |
A daily routine that works:
- Pick one problem from the week’s pattern and set a timer for 30 to 40 minutes.
- Talk through your approach out loud before coding, even when you’re alone.
- If you’re stuck when the timer ends, read a solution, make sure you understand it, then close it.
- Re-solve that problem from scratch a few days later. This is where the learning sticks.
- Log every miss in one line: the problem, the pattern, and what you didn’t see.
The number of problems you’ve solved matters less than whether you can solve a new medium-difficulty problem within the time limit while explaining yourself. Practice wherever you like; LeetCode is the most common place to practice, and since many companies run their online assessments on hiring platforms such as HackerRank or CodeSignal, a few timed sessions in that kind of environment are worth doing.
How to think out loud
Interviewers grade your process as much as your answer. A candidate who reaches a working solution in silence gives them very little to write in their feedback. Use this sequence:
- Restate and clarify. Repeat the problem in your own words and ask about the input: size, empty cases, duplicates, negative numbers, sorted or not.
- Work an example. Walk through a small input by hand, plus one edge case.
- State a brute-force approach and its complexity. It proves you can solve the problem at all and gives you a baseline.
- Optimize. Name the pattern you think applies and why, and agree on the approach with the interviewer before writing code.
- Code while narrating intent, not syntax. Say “this map stores the last index where I saw each character”, not “now I’m writing a for loop”.
- Test by hand. Trace your code with the example and an edge case. Find your own bugs before the interviewer does.
- Analyze. Give the time and space complexity, and mention what you’d change with more time or different constraints.
Phrases that help under pressure:
- “Before I start, can I check a couple of assumptions about the input?”
- “The brute force is O(n²). I think a hash map gets this to O(n); let me check that against the example.”
- “I’m deciding between two approaches. Here’s what I’m weighing…”
- “Let me trace this with an empty input before I call it done.”
Getting stuck is normal. Say what you’re considering, and if the interviewer offers a hint, take it and build on it. Using a hint well is a better signal than ten silent minutes on a dead end.
Rehearse this with another person a few times before a real interview. Record yourself solving a problem, or trade mock interviews with a friend who’s also preparing. If you don’t have anyone to practice with, services such as interviewing.io offer anonymous mock interviews with working engineers.
Behavioral interviews: answering with STAR
Behavioral rounds check how you work with people: how you handle conflict, mistakes, ambiguity, deadlines, and ownership. At more senior levels, they also help decide what level you’re hired at. Answer “Tell me about a time…” questions with a specific past event, not a description of what you’d generally do.
The STAR method gives those answers a structure. The University of Washington career center suggests roughly this balance:
- Situation (about 20%): just enough context to follow the story
- Task (about 10%): your goal or responsibility
- Action (about 60%): what you did, in detail; the part interviewers care about most
- Result (about 10%): the outcome, with numbers where you have them
The Tech Interview Handbook’s behavioral interview guide adds a final Reflection step: what you learned or would do differently. It’s worth including, because it shows you improve from experience.
A STAR answer template
Here’s the structure for a common question, “Tell me about a time you disagreed with a teammate.” It’s a template to fill with your own story, not a model answer to memorize.
Situation: “On [project], [teammate’s role] and I disagreed about [the decision], about [time] before [deadline or milestone].”
Task: “I owned [your part], so I needed us to settle [the decision] without delaying [the milestone].”
Action: “First I [asked questions to understand their reasoning]. Then I [wrote up both options with their trade-offs / built a quick prototype / measured something]. We [agreed on criteria / asked a third person to weigh in]. Once we decided, I [what you did next].”
Result: “We went with [option]. [Concrete outcome: shipped on time, the problem didn’t come back, the approach became the team default.]”
Reflection: “Next time I’d [raise it earlier / write the trade-offs down before the discussion].”
Keep the whole answer to about two minutes. Say “I” for your own actions, even in team stories; the interviewer needs to know what you did, not what the team did.
Build a story bank
You don’t need a story for every possible question. The Tech Interview Handbook recommends preparing three to five core stories and adapting them, which matches what I’d suggest. Choose projects with real stakes, real complexity, and real personal involvement, then check that between them they cover these themes:
- A project you’re proud of and your specific role in it
- A disagreement, and how it was resolved
- A mistake or failure, and what you changed afterward
- A tight deadline or a sudden change in priorities
- Working with unclear requirements
- Helping or teaching someone
- Taking ownership of something nobody was assigned to
Common behavioral questions
- Tell me about yourself.
- What’s the most impactful project you’ve worked on?
- Tell me about a time you disagreed with someone on your team.
- Describe a bug or outage you caused. What happened next?
- Tell me about a time you had to deliver with incomplete requirements.
- Tell me about feedback that was hard to hear.
- Why are you leaving your current role, and why this company?
Some companies publish the values they hire for. Amazon’s Leadership Principles are the best-known example. If a company publishes something similar, read it and decide in advance which of your stories best demonstrates each value.
Avoid the usual mistakes: stories with no clear result, blaming other people, long setups, and fake weaknesses such as “I work too hard”.
System design basics for mid-level roles
Junior candidates rarely get a full system design round. From mid-level up, expect one: an open-ended prompt such as “design a URL shortener” or “design a notification service”, discussed on a whiteboard or a shared diagram. At mid-level, the bar is usually a sensible, working design with clear reasoning, not deep expertise in distributed systems. For how expectations change at each level, see our software engineering career roadmap.
The System Design Primer on GitHub breaks the conversation into four steps, which make a good default script:
- Clarify requirements and constraints. Who uses it, what the core features are, how much data, how many reads versus writes. Do rough back-of-the-envelope estimates.
- Sketch a high-level design. Clients, API, services, databases, and how data flows between them.
- Design the core components in detail. The data model, the API endpoints, and the one or two hardest parts.
- Scale it. Find the bottlenecks and address them, explaining the trade-off of each fix.
Building blocks you should be able to explain in plain language:
- Load balancers and horizontal scaling
- Caching: what to cache, where, and how to avoid serving stale data
- SQL versus NoSQL, indexes, replication, and sharding
- Message queues and background workers
- CDNs for static content
- Rate limiting, retries, and idempotency
- Consistency versus availability trade-offs
Practice prompts: a URL shortener, a rate limiter, a chat app, a notification service, a news feed, and a file upload service. Sketch each one in 30 minutes, then compare your design with a reference solution. If you’ve built backend features at work, connect your answers to them; “we ran into exactly this with our webhook queue” is more convincing than a textbook answer.
The week before and the day of
- Stop learning new topics two or three days before. Review your mistake log and re-solve a few problems instead.
- Prepare your two-minute introduction and three or four questions for each interviewer.
- Research the company’s product, and use it if you can.
- Sleep. Being tired costs you more in a coding round than one extra practice problem gains you.
- On the day, keep water, a pen, and paper nearby, and have a blank editor open that you’re comfortable in.
- After each round, write down the questions you were asked. Those notes are the best preparation for your next loop.
FAQ
How many practice problems should I solve?
There’s no magic number. Cover every pattern above with several problems each, and stop counting once you can reliably solve new medium problems in time. Curated lists such as Grind 75 exist precisely so you don’t have to grind through hundreds.
Which language should I use in coding interviews?
The one you’re most fluent in, as long as the company allows it. Python is a common choice for its brevity, but fluency matters more than brevity.
What if I freeze completely?
Go back to the first step: restate the problem and work through a small example by hand, out loud. It gives your brain something concrete to do, and it gives the interviewer a chance to help.
Your next step
Book your first mock interview for two weeks from today, then work backward: spend this week on arrays, strings, and hash maps, and write down the three stories you’d tell in a behavioral round. A fixed date turns preparation into a plan. And if you’re not getting interviews yet, start with your software engineer resume.