Key Takeaways
- The standard sequence is recruiter screen, technical phone screen, and an onsite loop of four to six back-to-back sessions, over four to eight weeks.
- Algorithmic coding remains central at large technology employers, tested through explaining your reasoning out loud rather than silently producing an answer.
- System design usually determines your level, and it is the round most under-prepared by candidates coming from other markets.
- Behavioral rounds are scored formally at large employers, not treated as a friendly chat - prepare STAR stories with real numbers.
- American interview register rewards clear ownership of your achievements; candidates from modesty-oriented cultures routinely undersell themselves.
The American technology interview process is longer, more structured, and more standardised than in most other markets. That is intimidating on first contact and genuinely helpful once you understand it, because a standardised process is a preparable one.
The most common mistake international candidates make is preparing only for the coding rounds. Coding gets you through the middle of the process; system design usually decides what level you are offered, and behavioral rounds eliminate people who cleared everything technical.
This guide covers each stage, what it actually assesses, and how to prepare for the whole sequence.
Before any of it, your resume has to survive screening - run it through the free ATS score checker.
The Standard Sequence
1. Recruiter screen (20-30 minutes). Background, motivation, timeline, compensation expectations, and work authorisation. Non-technical, but it is a real filter.
2. Technical phone screen (45-60 minutes). Usually one or two coding problems in a shared editor, sometimes with a brief discussion of your experience.
3. Onsite loop (4-6 hours). Historically in person, now frequently virtual. Four to six back-to-back sessions: two or three coding, one system design, one or two behavioral, sometimes a domain-specific round.
4. Debrief and decision. Interviewers submit written feedback and a hiring committee or manager decides.
5. Offer and negotiation.
Timeline: four to eight weeks end to end is typical, longer at large companies. Run processes in parallel rather than sequentially - it saves months and improves your negotiating position considerably.
The Recruiter Screen
Underestimated, and people do fail here.
What they assess: whether you are genuinely interested, whether your background matches, whether your compensation expectations are in range, and whether you are authorised to work.
Prepare:
- A two-minute summary of your background - see the structure in how to write a resume summary
- A specific reason for interest in this company
- Your timeline and notice period
- Your work authorisation status, stated clearly. For international candidates this comes up early - see how to get a job in the USA as an international candidate
On compensation: try to get them to state a range first. If pressed, give a researched range with your target near its bottom. This first number anchors everything later - see US salary negotiation.
Coding Rounds
Still the core of technical assessment at most US technology employers.
What is tested
Data structures and algorithms - arrays, strings, hash maps, trees, graphs, sorting and searching, recursion, dynamic programming. Typically at medium difficulty, occasionally harder.
Common patterns: two pointers, sliding window, binary search, BFS and DFS, backtracking, heaps, and dynamic programming.
What actually gets scored
This is where candidates misunderstand the exercise. Interviewers are not only checking whether you reach a correct answer. They are assessing:
Communication. Can you explain your approach before and while coding? Silence reads as being stuck even when you are thinking clearly.
Problem-solving process. Do you clarify requirements, consider edge cases, and reason about tradeoffs?
Code quality. Meaningful names, sensible structure, no unnecessary complexity.
Testing. Do you check your own code on an example before declaring it done?
Response to hints. Interviewers deliberately give hints. Taking one gracefully is positive; ignoring it is not.
The approach that works
- Restate the problem in your own words.
- Ask clarifying questions - input ranges, duplicates, empty input, expected output format. Interviewers frequently leave these ambiguous on purpose.
- State a brute force solution and its complexity. Do this even if you see the optimal answer - it demonstrates structured thinking.
- Improve it out loud, explaining what insight lets you do better.
- Write the code, narrating as you go.
- Test on an example, walking through it deliberately.
- State the final complexity and any tradeoffs.
Preparation resources: coding interview preparation and technical interview preparation.
How much practice
Somewhere between 150 and 250 well-understood problems is a reasonable target for most candidates - understood meaning you could re-solve them in a week. Pattern recognition matters far more than raw count.
Practise out loud, ideally with another person. Solving silently at a desk builds a different skill than explaining under observation, and only one of those is tested.
System Design
The round that most often determines your level, and the one candidates from other markets are least prepared for.
Expected from mid-level upward, and increasingly present even in new-grad loops in a lighter form.
Typical prompts: design a URL shortener, a news feed, a rate limiter, a chat system, a ride-hailing backend, a notification service.
The structure interviewers expect
1. Clarify requirements. Functional - what must it do. Non-functional - how many users, how much data, what latency, what consistency guarantees. Do not skip this; jumping to a diagram is the classic failure.
2. Estimate scale. Rough numbers for traffic, storage, and bandwidth. Precision is not the point; demonstrating you think about magnitude is.
3. Define the API. A few endpoints with their inputs and outputs.
4. Sketch the high-level design. Clients, load balancer, services, databases, caches, queues.
5. Go deep on one or two components. The interviewer will usually steer you here.
6. Discuss tradeoffs. SQL versus NoSQL and why, caching strategy and invalidation, replication and consistency, how it fails and how it degrades.
7. Address bottlenecks. What breaks first at ten times the load.
What is being assessed: whether you can reason about tradeoffs, not whether you produce a canonical architecture. There is no single right answer, and interviewers are more interested in your justification than your diagram.
Preparation: learn the building blocks properly - load balancing, caching, database sharding and replication, message queues, CDNs, consistency models - then practise several classic problems out loud with a timer.
Behavioral Rounds
Formally scored at large US employers, not a friendly chat. Some companies weight these as heavily as technical rounds.
Standard questions:
- Tell me about a time you disagreed with a teammate
- Describe a project that failed, and what you learned
- Tell me about a time you had to influence without authority
- Describe your most technically challenging project
- Tell me about a time you received difficult feedback
- Give an example of when you had to make a decision with incomplete information
Answer in STAR - Situation, Task, Action, Result - with the situation kept short and the action given most of the time. Quantify the result. See behavioral interview questions and answers.
Prepare six to eight stories covering conflict, failure, leadership, influence, ambiguity, and technical depth. Most questions map onto these, so you adapt rather than improvise.
Use "I", not "we". This is the most common failure among candidates from collaborative cultures. Credit the team once, then describe your own contribution specifically. The interviewer is scoring you, and "we redesigned the system" tells them nothing about what you did.
On register: American interview culture expects you to own your achievements clearly. Candidates from cultures where modesty is the norm consistently undersell themselves and are rated lower as a result. Stating "I led that migration and it cut latency by 40%" is the expected register, not arrogance.
Compensation and Levelling
Two US-specific features worth knowing.
Levelling happens during the interview. Your performance, particularly in system design, determines whether you are offered as a mid-level or senior engineer - which affects compensation far more than negotiating the number afterwards.
Total compensation is the metric. Base salary, annual bonus, and equity - which at larger technology companies is often a substantial fraction of the package. Compare offers on total compensation and understand the vesting schedule rather than fixating on base. See US salary negotiation.
Common Mistakes
Solving silently. Interviewers cannot score reasoning they cannot hear.
Skipping clarifying questions. Deliberately ambiguous prompts are testing whether you ask.
Jumping straight to a system design diagram without establishing requirements or scale.
Preparing only coding. System design determines level and behavioral rounds eliminate people.
Saying "we" throughout behavioral answers. They are scoring you.
Underselling achievements. Reads as a weak candidate in US interview register.
Ignoring hints. They are offered deliberately.
Not testing your own code. Cheap to do and visibly missing when skipped.
Running processes sequentially. Four to eight weeks each means months lost, and no competing offers.
Naming a compensation number too early. It anchors the entire negotiation.
Frequently Asked Questions
How long does the US tech interview process take?
Typically four to eight weeks from first contact to offer, sometimes longer at large companies. Running several processes in parallel is standard practice and improves your negotiating position.
How many rounds should I expect?
A recruiter screen, a technical phone screen, and an onsite loop of four to six sessions. Some companies add a take-home exercise or a hiring manager conversation.
Do I need to grind hundreds of algorithm problems?
Somewhere around 150 to 250 well-understood problems is a common benchmark, with pattern recognition mattering far more than count. Practising out loud is more valuable than solving more problems silently.
How important is system design?
Very, from mid-level upward - it frequently determines the level you are offered, which affects compensation more than negotiation does. It is also the round international candidates most often under-prepare.
Are behavioral interviews really scored?
At large US employers, yes, formally and sometimes with the same weight as technical rounds. Candidates who clear every technical round and fail here are not unusual.
Should I use "I" or "we" in interviews?
"I" for your own contributions. Credit the team once for context, then be specific about what you personally did. This is the most common scoring problem for candidates from collaborative cultures.
What if I cannot solve the coding problem?
Communicate your reasoning throughout, state a brute force approach, and take hints when offered. Candidates who reason clearly without reaching an optimal solution frequently pass; candidates who go silent rarely do.
Get through resume screening before any of this matters. Check your ATS score free.
Make This Practical
Prepare all three tracks rather than only coding, because they eliminate at different stages. Coding gets you through the middle, system design decides your level and therefore your compensation, and behavioral rounds remove people who cleared everything technical.
For coding, practise out loud with another person rather than silently at a desk - restating the problem, asking clarifying questions, stating the brute force, then improving it. For system design, learn the building blocks and rehearse several classic prompts with a timer, always starting from requirements and scale rather than a diagram.
For behavioral rounds, write six to eight STAR stories with quantified results covering conflict, failure, leadership, influence, ambiguity, and technical depth - then rewrite each one using "I" rather than "we". Run several processes in parallel, avoid naming a compensation figure first, and negotiate the total package using US salary negotiation.
Was this guide useful?
Be the first to rate it.
TD





