Most tech interview processes follow the same shape: a recruiter screen, one technical screen, then a final round of three to five interviews covering coding, design or a take-home review, and behavioral questions. If you are already working in the field, four to six weeks of focused preparation (around an hour a day on weekdays plus a longer weekend session) is enough for most mid-level roles; plan for longer if you are rusty on algorithms or targeting senior system design.
The details vary by company and role, so the first step in every process is to ask the recruiter exactly what each stage involves. They will usually tell you, and it saves you from preparing for the wrong thing.
The typical loop, stage by stage
| Stage | Usual length | What it tests | Who runs it |
|---|---|---|---|
| Recruiter screen | 20 to 30 min | Fit with role, level, location, pay expectations, motivation | Recruiter |
| Technical screen | 45 to 60 min | Can you code or troubleshoot at a basic bar, live | Engineer |
| Coding rounds | 45 to 60 min each | Problem solving, code quality, communication | Engineers |
| System design | 45 to 60 min | Architecture judgment, trade-offs (mid-level and up) | Senior engineer |
| Take-home or project review | 2 to 6 hours of work, then 45 to 60 min discussion | Realistic work, how you explain choices | Team members |
| Behavioral | 45 to 60 min | Collaboration, ownership, conflict, scope | Manager or senior peer |
Not every company uses every stage. Many smaller companies swap algorithm rounds for a take-home or a pairing session on realistic code. Infrastructure and IT roles such as systems administrator often replace coding rounds with troubleshooting scenarios ("a user says the site is slow; walk me through it"). Data roles add a statistics or SQL round.
Recruiter screen: easy to pass, easy to fail
This call decides whether the hiring manager sees you. The recruiter is checking that your experience matches the level, that you can explain why you want this role, and that logistics work (location, work authorization, start date, pay range).
Prepare three things:
- A 60 to 90 second summary of your background that ends with why this role is the logical next step.
- Two or three specific reasons you are interested in this company. Read their product pages and engineering blog, if they have one.
- An answer on compensation. You can ask for their range first. If pressed, give a range you have researched (our role pages show Bureau of Labor Statistics pay data by occupation) and say it depends on the full package.
Also ask: how many rounds, what each covers, which language you can use, and whether the coding environment is a shared editor, an IDE or a whiteboard.
Technical screen and coding rounds
The screen is usually one or two problems in a shared editor. Final-round coding interviews are similar but sometimes harder or more open-ended.
What to practice. Focus on the core patterns that cover most interview problems: arrays and strings, hash maps, two pointers and sliding windows, stacks and queues, trees and graphs (BFS and DFS), sorting and binary search, simple recursion and dynamic programming basics. Learn the patterns rather than memorizing hundreds of problems. Solving 60 to 100 well-chosen problems with honest review usually beats grinding 400.
How to practice. Use one language, the one you know best. Solve out loud, with a timer, and without autocomplete for some sessions. After each problem, write down which pattern it was and what you missed. Revisit missed problems a week later.
In the room. A good sequence is:
- Restate the problem and ask about inputs, sizes and edge cases.
- Describe a simple approach, even a brute force one, and its complexity.
- Improve it if you can, explaining the trade-off.
- Code it, talking through what you are doing.
- Test it by walking through an example and an edge case by hand.
Interviewers routinely hire people who did not reach the optimal solution but communicated clearly and wrote correct code. They rarely hire people who went silent for 20 minutes and then produced a clever answer.
System design
System design rounds appear for mid-level roles and dominate for senior ones. You are asked to design something like a URL shortener, a notification service or a file-sync system, and the interviewer watches how you reason.
A structure that keeps you on track:
- Requirements. Clarify the functional requirements and the scale (users, requests per second, data size). Write them down.
- High-level design. Clients, API layer, services, data stores, queues, caches. Draw boxes.
- Data model and APIs. Key tables or documents, main endpoints.
- Deep dive. Pick the hardest part (often storage, consistency or a hot path) and go deep.
- Trade-offs and failure modes. What breaks first at ten times the load, what happens if a component fails, what you would monitor.
Prepare by studying a handful of common designs in depth and by reviewing systems you have actually built. Your own work is your best material: an interviewer will believe a trade-off you have lived through more than one you read about.
Take-home assignments
Take-homes reward people who treat them like real work. Read the instructions twice and respect the time limit (if it says four hours, a twenty-hour submission can look like poor judgment rather than dedication). Include a README that explains how to run it, what you prioritized, what you would do with more time, and any assumptions. Write a few meaningful tests. Expect a follow-up session where you extend the code or defend your choices, so make choices you can defend.
It is reasonable to ask whether a long take-home replaces other rounds. If it does not, you are entitled to weigh that cost.
Behavioral interviews
Behavioral rounds are not soft. At many companies they decide the level you are hired at. Interviewers want concrete evidence of how you handled ownership, disagreement, failure, ambiguity and influence.
Prepare six to eight stories from your real work, each usable for several questions:
- A project you led or drove end to end
- A production incident or serious mistake, and what changed afterwards
- A technical disagreement with a peer or manager
- A time you delivered with unclear requirements
- A time you helped someone else improve
- A trade-off between speed and quality
Use a simple structure: situation (two sentences), what you did (most of the time), result, and what you learned. Say "I," not "we," when describing your actions. Have real numbers ready where they exist.
What interviewers actually score
Rubrics differ by company, but most cover the same dimensions:
| Dimension | What earns a strong score |
|---|---|
| Problem solving | Breaks the problem down, finds a workable approach, improves it |
| Code quality | Correct, readable, sensible names, handles edge cases |
| Communication | Explains thinking without being prompted, listens to hints |
| Testing and verification | Checks own work before declaring it done |
| Design judgment | Names trade-offs, matches the design to the stated scale |
| Collaboration and ownership | Specific examples of taking responsibility and working with others |
Notice how much of this is about process. The final answer matters, but interviewers write up what they saw you do for 45 minutes.
A realistic preparation plan
For an employed engineer with an hour on weekdays and two to three hours on weekends:
| Week | Focus |
|---|---|
| 1 | Pick your language. Review core data structures. 10 to 15 easy and medium problems. Draft behavioral stories. |
| 2 | Core patterns: hash maps, two pointers, sliding window, stacks. 15 problems. First mock interview. |
| 3 | Trees, graphs, BFS/DFS, binary search. 15 problems. Read up on two system designs. |
| 4 | Dynamic programming basics, review of missed problems. Two more designs. Second mock interview. |
| 5 | Timed mixed practice. Full mock loop with a friend. Polish stories. |
| 6 | Light review, company research, rest before the final round. |
New graduates often need two or three extra weeks on fundamentals. Senior candidates may spend half their time on system design and behavioral stories instead. Mock interviews with a peer are worth more per hour than solo practice, because speaking while thinking is the actual skill being tested.
Common mistakes
- Starting to code before understanding the problem.
- Going quiet. Interviewers cannot score reasoning they cannot hear.
- Ignoring hints. A hint is the interviewer trying to help you pass.
- Over-engineering a system design for a scale nobody asked about.
- Behavioral answers that describe the team's work and never your own decisions.
- Speaking badly about a former employer.
- Not asking any questions at the end. Ask about the team's current problems, how work is planned, and what success looks like in the first six months.
How to handle not knowing
You will hit questions you cannot answer. How you handle that is itself assessed.
Say so plainly, then show how you would work it out: "I haven't used Kafka directly. My understanding is that it's a distributed log, so I'd expect ordering within a partition. Here's how I'd approach the design assuming that." This shows honesty and reasoning, and interviewers can redirect you if your assumption is wrong.
If you are stuck on a coding problem, go back to a brute force solution and get something working. Talk through small examples by hand, which often reveals the pattern. Ask a clarifying question if you are unsure what is being asked. Never bluff on a factual question; an experienced interviewer will notice, and it costs more than the gap itself.
After each loop, whether you get the offer or not, write down every question you were asked and where you struggled. That list is the best study guide for the next one.