What the Loop Actually Looks Like
Details differ by company and level, but the shape is remarkably standard across Google, Amazon, Microsoft, Meta and the Indian offices of all of them.
- Recruiter screen — resume walkthrough, level calibration, logistics
- Online assessment or phone screen — one to two coding problems, 45–60 minutes
- Onsite loop (usually virtual): 2–3 coding rounds, 1 system design (mid+ levels), 1–2 behavioural
- Amazon adds a bar-raiser: an interviewer from outside the team with veto power
- Hiring committee / debrief — your interviewers' written feedback decides, not any one person
DSA: Patterns, Not Problem Count
The single biggest mistake is grinding problem count instead of pattern recognition. Roughly 15 patterns cover the overwhelming majority of what gets asked.
- Two pointers and sliding window
- Binary search — including binary search on the answer
- BFS / DFS on grids and graphs, plus topological sort
- Heap / priority queue for top-K and merge problems
- Dynamic programming: 1-D, 2-D, knapsack, longest-subsequence family
- Backtracking for permutations, combinations and constraint problems
- Tries, union-find, and interval merging as the common 'second tier'
- For each pattern: recognise it, implement it clean, and state its complexity without pausing
System Design (Mid-Level and Above)
Design rounds are graded on structured reasoning and explicit trade-offs, not on naming the most technologies.
- Start with requirements and scale estimation — never start drawing boxes
- Functional vs non-functional requirements, stated out loud
- Core building blocks: load balancing, caching, sharding, replication, queues, CDN
- CAP in practice: what you give up, and why that is acceptable for this product
- Database choice justified by access pattern, not by preference
- Always cover: bottleneck, failure mode, and how you'd monitor it
Behavioural Rounds Are Not a Formality
At Amazon in particular, behavioural rounds carry the same weight as coding. Leadership Principles are graded explicitly, and vague answers fail.
- Prepare 8–10 STAR stories, each with real numbers in the Result
- One story should be a genuine failure where you own the mistake
- Use 'I', not 'we' — interviewers are scoring your contribution specifically
- Expect depth follow-ups: 'what was the data', 'who disagreed', 'what would you change'
- For Amazon, map your stories to specific Leadership Principles in advance
A Realistic 6-Month Plan
Compressing this into six weeks is where most preparation fails. A sustainable schedule beats an intense one you abandon in month two.
- Months 1–2: language fluency + patterns 1–8, roughly 100 problems, quality over speed
- Months 3–4: remaining patterns + timed mock problems, 45 minutes on a clock
- Month 5: system design study plus 4–6 full mock interviews with a human
- Month 6: behavioural stories written out, mock loops end to end, then apply
- Throughout: practise talking while coding — silent problem solving fails these rounds
The Honest Part
Being clear-eyed about this makes the process survivable rather than demoralising.
- Rejection is the base rate. Strong engineers get rejected routinely, often for reasons unrelated to their ability.
- Most companies allow reapplication after a cooling-off period — a rejection is a delay, not a verdict
- Referrals meaningfully improve your odds of getting a screen; they do not affect the bar
- Interviewer variance is real, which is why the process uses multiple interviewers
- No preparation guarantees an offer. It only makes you consistently interviewable.
Common Interview Questions & Answers
Q1. How do you approach a coding problem you've never seen?
I restate the problem and confirm the constraints and edge cases before writing anything — input size drives which complexity class is even acceptable. Then I say the brute force out loud with its complexity, so there's a working baseline on the board. Then I look for the structure that lets me improve it: is it sorted, is there overlapping subproblem structure, is there a monotonic property I can binary search on. I code only once I've stated the approach and the interviewer has agreed with it.
The out-loud brute force is what stops you from freezing and gives the interviewer something to steer.
Q2. Design a URL shortener.
Clarify first: expected writes per second, read-to-write ratio, custom aliases, expiry, analytics. Then estimate scale to decide whether one database is enough. Core design: a key generation service producing short unique ids (counter with base62 encoding, or pre-generated key pool to avoid collision checks), a KV store for the mapping since access is pure point-lookup, a cache in front because reads dominate heavily, and a CDN or edge redirect for latency. Then discuss the actual trade-offs — hash-with-collision-check versus counter, and how the counter shards without a single point of failure.
Requirements first, estimation second, boxes third. Reversing that order is the most common failure.
Q3. Tell me about a time you failed.
Pick a real failure with real consequences, own it without deflecting to a teammate, and spend most of the answer on what you changed afterwards. A shipped bug that caused a measurable outage, what your specific decision was that caused it, how you detected and fixed it, and the process change you introduced so it could not recur. The result should be the prevention, not a rescue.
'My weakness is I work too hard' style non-failures are the fastest way to lose a behavioural round.
Common Mistakes to Avoid
Optimising problem count over pattern understanding — 500 problems, no transfer
Coding in silence, so the interviewer cannot follow or help
Jumping into system design boxes before establishing requirements and scale
Treating behavioural rounds as a warm-up rather than a graded round
Preparing for six weeks, interviewing, and concluding you are not good enough
Expert Tips
Do mock interviews with a human — solving alone does not train the talking-while-thinking skill
Time every practice problem to 45 minutes from week one
Write your STAR stories down; you will discover half of them have no quantified result
Interview at lower-priority companies first to burn off nerves before your top choice
Pre-Interview Checklist
6 itemsFrequently Asked Questions
How many problems should I solve?
Roughly 200–300 well-understood problems across the core patterns beats 700 skimmed ones. The measure is whether you can recognise the pattern in an unseen problem, not the count.
Can I get in without a computer science degree?
Yes — many big tech engineers are non-CS graduates. The interview tests demonstrable skill rather than credentials, though you may need a referral or a strong portfolio to get the initial screen.
How long should I wait after a rejection?
Most companies specify a cooling-off period, commonly 6–12 months, and it is stated in the rejection communication. Use the interval to fix the specific round that went badly rather than restarting from zero.
Ready to ace your next interview?
Practice with SpeakWell AI. Upload your resume → get resume-based questions → practice with AI interviewers → improve communication → track progress → get instant AI feedback.