You have been grinding LeetCode for weeks. Your pattern recognition is solid, your problem count is healthy, and you feel ready. Then you get a Google interview invite and someone tells you, "Google loves dynamic programming and graph problems." Suddenly, you realize that half your practice has been on sliding window and two pointer problems, and you have barely touched DP on trees.
This is the mistake of preparing generically when your interview is specific. Different companies have different preferences, different difficulty expectations, and different evaluation criteria. A preparation strategy that works for Amazon might leave you underprepared for Google, and what gets you through a startup interview might not be enough for Meta.
This chapter covers how the major companies differ in their coding interview focus, how to use publicly available data to tailor your prep, how timelines and expectations change by company tier and seniority level, and how to structure those final 2-3 weeks before your interview.
Every company says they evaluate "problem-solving ability," but in practice, the types of problems they favor vary significantly. This is not random. It reflects the engineering challenges each company faces and, to some extent, the preferences of the people who build their question banks.
Here is a breakdown of the major tech companies and what their coding interviews tend to emphasize:
| Company | Primary Focus Areas | Secondary Focus | Difficulty Level | Notable Traits |
|---|---|---|---|---|
| DP, Graphs, Binary Search, Strings | Greedy, Math, Backtracking | Medium-Hard to Hard | Novel problems, expect multiple solutions, optimization matters | |
| Meta (Facebook) | Trees, Graphs, BFS/DFS, Arrays | Sliding Window, Hash Maps, DP | Medium to Medium-Hard | Fast pace (2 problems in 40 min), clarity valued over cleverness |
| Amazon | BFS/DFS, Hash Maps, Arrays, Sorting | Greedy, Trees, Strings | Medium | Leadership Principles woven into coding rounds, practical problems |
| Apple | Fundamentals, Arrays, Strings, Trees | Linked Lists, Sorting, OOP concepts | Easy-Medium to Medium | Emphasis on clean code and design thinking |
| Microsoft | Trees, Arrays, Strings, Linked Lists | DP, Graphs, OOP | Medium | Balanced across topics, values clear communication |
| Netflix | System design heavy, less DSA | Arrays, Hash Maps, Trees | Medium | Senior-only hiring, system design dominates |
| Startups | Practical problems, Arrays, Hash Maps | Strings, Trees, API design | Easy to Medium | Speed matters, often real-world scenarios |
A few things to notice. Google stands out for difficulty. Their interviewers often ask problems that require genuine insight, and they expect candidates to discuss trade-offs between multiple approaches. If a brute force works, they will ask you to optimize. Meta is known for speed. Two problems in one round means you cannot spend 20 minutes on problem one and have nothing for problem two. You need to be fast and decisive. Amazon is unique because their Leadership Principles (ownership, bias for action, customer obsession) are not just behavioral round material. Coding interviewers will evaluate how you communicate and whether you ask the right clarifying questions.
One of the most useful features on LeetCode Premium is the company tag filter. For each problem, LeetCode tracks which companies have asked it in interviews (reported by users), and how frequently it has appeared in the last 6 months, 1 year, and 2 years.
Here is how to use this data effectively.
Sort by frequency, not difficulty. When you filter by a company, sort problems by how recently and frequently they have been asked. A medium-difficulty problem asked 50 times at Google in the last 6 months is far more valuable to practice than a hard problem asked twice three years ago. Companies rotate their question banks, but popular problems tend to stay in rotation for 6 to 12 months.
Focus on the last 6 months. Older data is less reliable. Companies update their question pools regularly, and a problem that was hot two years ago might have been retired. The 6-month window gives you the most actionable signal.
Look for pattern clusters, not individual problems. You will never see the exact same problem in your interview (interviewers often modify problems slightly). What you will see is the same pattern. If a company has asked 8 different BFS problems in the last year, that tells you BFS is in their question bank's DNA. Practice the pattern, not just the specific problems.
Do not try to solve every tagged problem. For a company like Google with 1500+ tagged problems, solving them all is impossible and unnecessary. Pick the top 30-50 by frequency, and make sure you cover each major pattern that appears.
Here is a practical approach:
The "how hard should I prepare" question depends heavily on where you are interviewing. The expectations at Google are genuinely different from a Series B startup, and preparing the same way for both wastes time.
Companies like Google, Meta, Amazon, Apple, Microsoft, and equivalents (Stripe, Airbnb, Uber, LinkedIn) have structured interview processes with calibrated difficulty. Expect:
For these companies, you need deep preparation across all major patterns, the ability to solve medium problems quickly (under 20 minutes), and comfort with hard problems even if you do not always reach a perfect solution.
Companies like Salesforce, Adobe, Oracle, Intuit, Atlassian, and similar mid-tier firms still have technical interviews, but the bar is calibrated differently:
For these companies, solid coverage of core patterns with emphasis on medium-difficulty problems is sufficient. You probably do not need to grind hard DP or advanced graph algorithms unless they specifically appear in company tags.
Startup interviews are the most varied. Some startups copy the Google process (especially those founded by ex-FAANG engineers). Others ask you to build something practical in a take-home assignment or pair-program on a real codebase. Some skip DSA entirely and focus on system design or a live coding exercise with their actual codebase.
Before preparing for a startup interview, research their specific process. Check Glassdoor, ask the recruiter, and look for interview experiences on Blind or Reddit. You might spend weeks preparing for LeetCode-style problems only to discover they do a 3-hour take-home project instead.
Company tags on LeetCode give you problem data, but interview experience reports give you process data, which is equally valuable. Here is where to look and what to look for.
Glassdoor interview reviews. Search for your target company and filter by "Interviews." Read the last 6 months of reports. Pay attention to: how many rounds, what each round covers, specific problems mentioned, and whether the process has changed recently.
Blind (Teamblind). This is where current and former employees share more candid experiences. Search for "[Company] interview experience" or "[Company] coding interview." The signal-to-noise ratio can be low, but the specific problem mentions are often accurate.
LeetCode Discuss. The "Interview Experience" section has detailed reports with specific problems. These are gold because they often include the exact problem or a close variant.
Reddit (r/cscareerquestions, r/leetcode). Useful for trends and general advice, less useful for specific problems.
When reading these reports, look for:
Create a summary document for each company you are targeting. Something simple like:
| Aspect | Details |
|---|---|
| Coding rounds | 2 rounds, 45 min each |
| Typical difficulty | Medium-Hard |
| Common patterns | DP, Graphs, BFS |
| Specific problems mentioned | LeetCode #X, #Y, #Z |
| Follow-up questions? | Yes, often asked to optimize |
| Behavioral component | Light, mostly in separate round |
| Red flags / gotchas | Fast pace, need to code quickly |
Timing your preparation is important. General pattern-based practice can happen months in advance, but company-specific prep should be concentrated in the 2-3 weeks before your interview. Here is why.
LeetCode problem rotation means the most relevant problems are the most recent ones. Studying company-tagged problems too early means you might practice problems that have since been retired. More importantly, you want company-specific patterns fresh in your mind during the interview.
A recommended timeline:
8-12 weeks before interview: General preparation. Build your pattern foundation. Solve 100+ problems across all core patterns. This is the work from the previous chapter.
3-4 weeks before: Pattern gap analysis. Look at your target company's focus areas. Compare against your tracking data. If Google is your target and you have only solved 3 DP problems, you have a gap. Spend these weeks filling pattern gaps.
2 weeks before: Company-specific deep dive. Filter LeetCode by company, solve the top 20-30 problems by frequency. Note which patterns dominate. Do timed practice sessions matching the company's interview format (e.g., 2 problems in 40 minutes for Meta).
1 week before: Review and mock interviews. No new problems. Re-solve problems you struggled with. Do 2-3 full mock interviews. Review your flashcards. Rest.
The same company can have very different expectations depending on the level you are interviewing for. An L3 (junior) candidate at Google faces easier problems and more lenient evaluation than an L6 (staff) candidate. Understanding these differences helps you calibrate your preparation.
An important nuance: at senior levels, the coding bar does not necessarily go up in difficulty. What changes is the speed expectation and the depth of discussion. A senior candidate who solves a medium in 30 minutes might get a weaker signal than one who solves it in 15 minutes and spends the remaining time discussing edge cases, alternative approaches, and real-world considerations.
Most companies have a multi-stage process with a phone screen (or online assessment) followed by an on-site (or virtual on-site). These stages have different characteristics that affect how you should prepare.
| Aspect | Phone Screen / OA | On-Site |
|---|---|---|
| Duration | 30-45 minutes (1 problem) | 45-60 minutes per round (1-2 problems) |
| Difficulty | Easy to Medium | Medium to Hard |
| Purpose | Filter out unqualified candidates | Deep evaluation of qualified candidates |
| Environment | CoderPad, HackerRank, or phone | Whiteboard, laptop, or shared editor |
| Interaction | Less discussion, more coding | More discussion, trade-off analysis |
| Pass rate | ~20-30% move forward | ~20-30% get offers |
For phone screens, speed matters more than depth. You need to get to a working solution quickly because the time is short and the problems are usually straightforward. Practice solving easy-medium problems in under 20 minutes.
For on-sites, depth matters more than speed. You have more time per problem, but the problems are harder and interviewers expect you to discuss your thinking throughout. Practice thinking out loud, analyzing multiple approaches, and writing clean code while explaining what you are doing.
Let us bring all of this together into an actionable plan. Say you have a Google on-site in 3 weeks. Here is what your prep plan might look like.
Week 1: Pattern gap fill. Google emphasizes DP, graphs, and binary search. Check your tracking data. If you have fewer than 5 DP problems solved, spend this week on DP fundamentals and medium-difficulty DP problems. Same for graphs.
Week 2: Company-specific problems. Filter LeetCode by Google, last 6 months, sort by frequency. Solve the top 25 problems. Note which ones you struggle with and add them to your review list. Practice the Google format: 45 minutes per problem, discuss trade-offs after solving.
Week 3: Mock interviews and review. Do 3-4 mock interviews simulating Google's format. Re-solve the 10 problems you struggled with most. Review flashcards for key insights. Get a good night's sleep before each mock and definitely before the real thing.
This same template works for any company. Swap in the relevant patterns, adjust the difficulty level, and match the format.
Generic interview prep gets you 80% of the way there. Company-specific prep gets you the remaining 20%, and that last 20% often makes the difference between an offer and a rejection. Know what your target company emphasizes, use frequency data and interview reports to focus your practice, and time your company-specific prep for the 2-3 weeks before your interview. Adjust your expectations by level, prepare differently for phone screens versus on-sites, and build a concrete week-by-week plan.
In the next chapter, we will cover mock interviews, the single most underused preparation technique that can dramatically improve your interview performance.