How many rounds are in a typical technical interview process?
Most mid-to-large technology organizations run three to five rounds: a recruiter screen, a technical screen, and an onsite loop of two to four sessions. Senior roles often include an additional system design or presentation round. A technical screen is a single focused session (45-75 minutes) that verifies your technical depth in one area.
The technical interview process is not a single event. Most organizations run candidates through multiple rounds, each designed to test different competencies using different methods. Showing up without understanding what each format is testing—and how to perform well in it—is a structural disadvantage. This article explains the major technical interview formats you will encounter, what interviewers are evaluating at each stage, and how to prepare accordingly.
The Phone Screen
What Recruiters and Junior Staff Are Evaluating
The phone screen is typically the first substantive technical interaction. It usually runs 30 to 45 minutes and is conducted by a recruiter or a junior technical staff member. The goals are to verify that you understand the role, confirm your stated experience is accurate, and determine whether a full interview loop is worth the organization's time.
At this stage, expect high-level questions: the technologies on your resume, your familiarity with the team's stack, and basic conceptual questions in your stated domain. A cloud engineer might be asked to explain the difference between IaaS and PaaS. A network engineer might be asked what OSPF does at a high level.
This is not the stage to overexplain or demonstrate deep knowledge. Answer clearly and concisely. If you do not know something, say so directly—interviewers at this stage are more interested in your honesty than your ability to bluff.
The Technical Screen
Live Coding, Verbal Technical, and Scenario-Based Formats
A technical screen is a structured 45- to 75-minute interview that goes deeper than a phone screen. It is almost always conducted by a practicing engineer or technical lead. Common formats include:
Live coding: You write code in a shared environment (CoderPad, HackerRank, or similar) while the interviewer watches. This is more common in software engineering roles than in infrastructure, security, or networking roles.
Verbal technical interview: The interviewer asks conceptual questions and expects spoken, detailed answers. A sysadmin role might ask you to walk through what happens when a Linux kernel receives an interrupt, or explain how iptables processes packets.
Scenario-based questioning: You are presented with a real-world situation and asked how you would approach it. "Our application is timing out intermittently in production. Where do you start?" This tests whether your knowledge is practical.
Some organizations include a brief take-home exercise before or after this round. It might be a short script, a configuration file, or a written diagnostic walkthrough.
The Onsite Loop
Session Types and What Each Evaluates
The onsite loop (which has become increasingly virtual) is the most rigorous stage. It typically runs three to six hours, with multiple back-to-back sessions involving different interviewers. Each session generally tests a distinct competency:
| Session Type | What It Tests |
|---|---|
| Algorithms and data structures | Coding efficiency, problem decomposition |
| System design | Architecture reasoning, trade-off analysis |
| Domain knowledge | Depth in the specific technology area |
| Behavioral | Communication, conflict, growth mindset |
| Culture or values fit | Team compatibility, decision-making style |
Not all roles have all of these. Infrastructure-heavy roles often skip pure algorithm rounds in favor of deeper system design and operations scenarios.
System Design Interviews
Requirements, Trade-offs, and Scale Reasoning
"The system design interview has no right answer. What separates strong candidates is not what they design but how they reason: how they clarify requirements, how they identify the bottlenecks, and how they articulate what they chose not to do and why." — Martin Kleppmann, author of Designing Data-Intensive Applications (O'Reilly Media)
System design interviews are open-ended discussions in which you are asked to architect a system from scratch or analyze an existing one. Common prompts include:
Design a URL shortener
How would you architect a notification system that handles 10 million users?
Walk me through how you would design the storage backend for a CI/CD artifact repository
There is no single correct answer. Interviewers are evaluating your ability to reason through requirements, identify constraints, discuss trade-offs (CAP theorem, eventual vs. strong consistency, synchronous vs. asynchronous processing), and arrive at a defensible design.
A common mistake is jumping directly to a solution without asking clarifying questions. Before sketching anything, confirm the scale (requests per second, data volume, geographic distribution), the reliability requirements, and any constraints the team has already decided.
Behavioral Interviews
STAR Framework and Preparing Specific Stories
Behavioral interviews appear in technical processes because technical performance alone does not predict whether a candidate will be effective. These sessions use structured questions based on the STAR framework (Situation, Task, Action, Result) to evaluate how you have operated in the past.
Common prompts in technical roles:
"Tell me about a time you had to debug a production incident under pressure."
"Describe a situation where you disagreed with a technical decision made by your team."
"Give me an example of when you had to learn a new technology quickly."
Prepare five to seven specific stories from your actual experience before entering a loop. Each story should have a clear technical component, a measurable outcome, and a reflection on what you learned.
Take-Home Assessments
Take-home assessments are becoming more common as organizations try to reduce the pressure and time constraints of live coding. You are typically given 48 to 72 hours to complete a technical task and submit it as a repository or written document.
These vary widely. They might ask you to:
Write a small working application or script
Audit a configuration file and write up findings
Produce a written architecture proposal for a described scenario
The key mistake candidates make is submitting work that runs but is not readable or documented. A take-home is also an opportunity to demonstrate engineering judgment—commenting your code, handling edge cases, and writing a brief README explaining your choices.
Technical Presentations
Some senior roles include a presentation component, where you are asked to present a past project, a proposed solution, or a domain topic to a panel. This format tests communication skills, the ability to structure technical information for mixed audiences, and how you respond to questions under mild adversarial conditions.
If you are asked to give a technical presentation, structure it as: context and problem statement, approach and key decisions, outcomes and what you would do differently. Panels are often more interested in your reasoning than your conclusions.
Pair Programming Sessions
Pair programming sessions involve writing code alongside an interviewer who takes either the navigator or driver role. This is common at organizations that practice pair programming day-to-day and want to evaluate how you collaborate while coding.
These sessions reward candidates who:
Verbalize their thinking as they code
Accept suggestions gracefully
Ask questions rather than guessing at requirements
Catch and acknowledge their own mistakes
How to Prepare Across Formats
The trap most candidates fall into is preparing exclusively for one format—usually algorithmic coding—when the actual loop includes multiple formats they have not practiced. A structured preparation plan addresses each format:
- Technical screen: Review core concepts in your domain. For cloud roles, review IAM, networking fundamentals, and storage options across providers. For security roles, review the OSI model, common CVE types, and incident response frameworks.
- System design: Practice designing three to five systems at different scales. Use the "Designing Data-Intensive Applications" framework for thinking about consistency, availability, and fault tolerance.
- Behavioral: Write out specific stories before the interview. Do not improvise these under pressure.
- Take-home: Practice producing clean, documented solutions to small exercises before you encounter them in an actual interview context.
- Live coding: Practice solving problems while talking. Silence during live coding is interpreted as confusion, even when you are thinking.
What Interviewers Are Actually Evaluating
Across all formats, interviewers are generally assessing three things: whether you know the material, whether you can communicate what you know, and whether working with you would be productive and pleasant. The third factor is underrated. Candidates who are technically sound but dismissive, who do not listen to hints, or who respond to uncertainty with defensiveness are frequently not advanced.
The most consistent feedback that hiring managers give about strong candidates is that they explained their reasoning clearly, acknowledged what they did not know, and engaged the interview as a collaborative exercise rather than an interrogation.
See also: Take-Home Technical Assessments: How to Approach and Submit Them Well
Format prevalence by company type
Not all companies use every format. Matching your preparation to the actual format mix at your target companies is more efficient than blanket preparation.
| Company type | Phone screen | Live coding | System design | Take-home | Behavioral | Pair programming |
|---|---|---|---|---|---|---|
| FAANG (Meta, Google, Amazon, etc.) | Heavy | Heavy (LeetCode-style) | Heavy | Rare | Moderate | Rare |
| Mid-stage startup (Series B-D) | Moderate | Moderate | Moderate | Heavy | Heavy | Moderate |
| Early startup (Seed-A) | Light | Moderate | Light | Heavy | Heavy | Heavy |
| Traditional enterprise | Moderate | Light | Moderate | Light | Moderate | Rare |
| Cloud-native consultancy | Moderate | Moderate | Heavy | Moderate | Heavy | Moderate |
| Financial services | Moderate | Heavy (often in-person) | Moderate | Moderate | Heavy | Rare |
| Government contractor | Light | Light | Light | Rare | Heavy | Rare |
| Open-source company | Light | Light | Heavy | Heavy | Moderate | Heavy |
Candidates targeting FAANG should over-invest in LeetCode-style live coding and large-scale system design; candidates targeting early-stage startups should over-invest in take-home polish and behavioral storytelling about ambiguity tolerance.
Certifications as interview pre-screens
Some companies use certifications as pre-screen filters that skip the technical phone screen entirely. This is most common in cloud-native consultancies and AWS partner firms.
| Certification | Current exam code | Fee | Pre-screen value |
|---|---|---|---|
| AWS SAA-C03 | SAA-C03 | $150 | Waives AWS fundamentals screen at many partners |
| AWS SAP-C02 | SAP-C02 | $300 | Waives associate-level screens at AWS Advanced Tier partners |
| Azure AZ-104 | AZ-104 | $165 | Common prerequisite for Microsoft-partner engineer roles |
| Azure AZ-305 | AZ-305 | $165 | Senior Azure solutions architect pre-screen waiver |
| Google Professional Cloud Architect | PCA | $200 | Required at many Google Cloud Premier partners |
| CKA | CKA | $395 | Often waives Kubernetes fundamentals screen |
| CISSP | CISSP | $749 | Frequently listed as job requirement in security roles |
| Red Hat RHCE | EX294 | $500 | Near-requirement at RHEL-heavy enterprises |
| Terraform Associate | 003 | $70.50 | IaC fundamentals pre-screen at IaC-heavy firms |
| PMP | PMP | $555 | Required for many senior PM roles, particularly in government contracting |
System design interview depth by seniority
System design interviews are scaled to candidate level. Junior candidates face simpler prompts and are expected to produce simpler designs; staff-level candidates face ambiguous prompts and are expected to ask clarifying questions, articulate multiple design options, and reason through trade-offs at scale.
| Seniority | Prompt complexity | Expected depth | Typical prompt |
|---|---|---|---|
| Junior (L3) | Well-scoped | Data model, basic API, one layer of caching | Design a URL shortener |
| Mid-level (L4) | Moderately scoped | Sharding, indexing, background jobs | Design a rate limiter for an API |
| Senior (L5) | Ambiguous | Consistency trade-offs, availability SLAs, cross-region | Design a notification system |
| Staff (L6) | Very ambiguous | Migration strategy, org-wide platform design | Design a multi-tenant analytics platform |
| Principal (L7+) | Open-ended | Strategic alignment, investment prioritization | Reshape a legacy system over 2 years |
"The best signal I get from a system design interview is not the correctness of the final design. It is the quality of the clarifying questions the candidate asks in the first five minutes. Candidates who ask about traffic patterns, consistency requirements, failure modes, and budget constraints demonstrate the thinking that produces sound architectures. Candidates who jump into a diagram after the prompt typically miss critical constraints." - Martin Kleppmann, PhD, University of Cambridge, author of Designing Data-Intensive Applications [1].
Behavioral interview deep-dive
Behavioral interviews are often underestimated by technical candidates. At senior levels, behavioral performance frequently determines the outcome even when technical performance is strong.
Amazon Leadership Principles - Amazon interviews explicitly evaluate candidates against sixteen Leadership Principles. Candidates should have two to three specific stories mapped to each principle.
Google Googleyness and Leadership - Google evaluates cultural fit and leadership using a rubric that weights both individual contributor craftsmanship and collaboration signals.
Meta Cross-Functional Collaboration - Meta weights the ability to work across engineering, product, and design teams; behavioral stories should demonstrate boundary-spanning.
Microsoft Growth Mindset - Microsoft's transformation under Satya Nadella explicitly prioritizes learning orientation; candidates should prepare stories about professional mistakes and what they learned.
Netflix Culture Deck principles - Netflix interviews probe for high performance bar, candor, and judgment; rehearse stories about difficult decisions you made with limited information.
Candidates interviewing at companies with explicit behavioral rubrics should spend at least ten hours writing out and rehearsing STAR-format stories mapped to each pillar. Winging behavioral interviews at senior levels is the most common cause of avoidable rejections.
"Our data from over 400,000 interviews suggests that behavioral performance is significantly under-weighted by candidates and significantly over-weighted by hiring managers. Candidates who invest a full weekend preparing behavioral stories convert offers at substantially higher rates than candidates who spend that same weekend on additional LeetCode problems." - Aline Lerner, CEO of Interviewing.io [2].
Format-specific preparation resources
| Format | Best preparation resources (2024-2025) |
|---|---|
| LeetCode-style live coding | LeetCode premium, NeetCode 150 list, HackerRank |
| System design | Designing Data-Intensive Applications, Alex Xu's System Design books, Grokking the System Design Interview |
| Behavioral | The STAR Interview Method blog posts, Glassdoor interview reviews |
| Take-home | GitHub exemplar repos, Clean Code review patterns |
| Cloud architecture | AWS Well-Architected Framework, Azure Architecture Center, GCP Architecture Framework |
| Mock interviews | Interviewing.io, Pramp, Hello Interview |
| Salary negotiation | Fearless Salary Negotiation by Josh Doody, Levels.fyi |
References
[1] Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media. ISBN: 978-1449373320
McDowell, G. L. (2015). Cracking the Coding Interview (6th ed.). CareerCup. ISBN: 978-0984782857
Mongan, J., Suojanen, N., & Giguere, E. (2012). Programming Interviews Exposed: Secrets to Landing Your Next Job (3rd ed.). Wrox. ISBN: 978-1118261361
Sonmez, J. (2019). The Complete Software Developer's Career Guide. Simple Programmer. ISBN: 978-0999081426
Pramp. (2023). "Technical Interview Formats and What Interviewers Look For." https://www.pramp.com/blog/technical-interview-formats
Google. (2024). "How We Hire: The Google Interview Process." https://careers.google.com/how-we-hire/
Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley. ISBN: 978-0134757599
[2] Interviewing.io. (2023). Why Behavioral Interviews Matter More Than Candidates Think. https://interviewing.io/blog
Robert Half. (2024). 2024 Technology Salary Guide. https://www.roberthalf.com/us/en/insights/salary-guide/technology
Frequently Asked Questions
How many rounds are in a typical technical interview process?
Most mid-to-large technology organizations run three to five rounds: a recruiter screen, a technical screen, and an onsite loop of two to four sessions. Senior roles often include an additional system design or presentation round.
What is the difference between a technical screen and an onsite interview?
A technical screen is a single focused session (45-75 minutes) that verifies your technical depth in one area. An onsite loop is a multi-session day-long process where different interviewers test different competencies including design, coding, domain knowledge, and behavioral fit.
Are algorithmic coding rounds required for infrastructure or security roles?
Not always. Many infrastructure, networking, and security roles skip pure algorithm rounds in favor of system design, domain knowledge walkthroughs, and scenario-based troubleshooting questions that better reflect the actual job.
How long do take-home technical assessments typically take?
Most take-home assessments are scoped to take between two and six hours of actual work, though the submission window is typically 48 to 72 hours. If an assessment is clearly scoped to take longer than that, it is worth asking the recruiter to clarify expectations.
What do interviewers look for beyond technical correctness?
Communication clarity, willingness to acknowledge uncertainty, responsiveness to hints and feedback, and collaborative behavior. Interviewers consistently report that candidates who explain their reasoning and engage with the interview as a conversation are rated more highly than candidates who produce correct answers silently.