I need to get something off my chest. If I see one more YouTube video titled "How I Cracked Google in 30 Days by Grinding 500 LeetCode Problems," I might lose it. Not because LeetCode is useless - it is not - but because this narrative has created an entire generation of engineers who think that technical interviews are just a coding contest. They are not. And the people selling you that story are either lying about their timeline, had a very unusual experience, or are leaving out about 80% of what actually matters.
I have been recruiting engineers for top MNCs for seven years. I have sat on interview panels at two FAANG-adjacent companies in India. I have debriefed with hiring managers after literally hundreds of interviews. And the pattern I see in who gets hired versus who does not is way more nuanced than "solve more problems on LeetCode."
Let me tell you about someone I will call Arjun. He came into an Amazon interview last year having solved over 600 LeetCode problems. Six hundred. The man could reverse a linked list in his sleep, probably did it in his dreams. He breezed through the coding rounds. Solid solutions, good time complexity, clean code. Then came the system design round and the behavioral rounds. He froze. Could not design a basic URL shortening service. Could not articulate a single time he had dealt with a disagreement at work. He did not get the offer.
Meanwhile, a woman with maybe 150 solved problems on LeetCode, but who had spent serious time understanding system design trade-offs and could talk about her engineering decisions with real depth - she got the offer at the same company, same role, same month.
The problem is not hard work. Indian engineers are some of the hardest working people I have ever met. The problem is misallocated effort.
What These Interviews Actually Test
Let me walk you through what a typical MNC interview loop looks like, because I think a lot of people have a distorted picture of it.
First there is usually a phone screen or online assessment. One or two coding problems, medium difficulty, 45 to 60 minutes. This is the filter. If you cannot solve a medium LeetCode-style problem under time pressure, you are not going to progress. That is just the reality. So yes, you do need to practice coding problems. I am not saying you do not.
Then comes the on-site loop, which is typically four to six rounds over one or two days. For someone with three or more years of experience, this usually breaks down into two coding rounds, one system design round, one or two behavioral rounds, and sometimes a domain-specific round. The weighting varies by company, but here is what shocks most people: the behavioral and system design rounds carry as much weight as the coding rounds. Sometimes more. I have seen hiring committees pass on candidates who aced the coding but fumbled the behavioral. It happens all the time.
Google cares a lot about what they call "Googleyness" - can you collaborate, are you humble, do you take feedback well. Amazon maps every single behavioral question to their Leadership Principles. If you walk into an Amazon interview without knowing those 16 principles backwards and forwards, you are not serious about getting that job.
The Coding Prep Everyone Talks About
Fine, let us talk about DSA prep since that is what everyone wants to hear. But I am going to tell you what actually works based on what I have observed from successful candidates, not what the YouTube algorithm wants you to believe.
First: quality over quantity. Always. Solving 150 problems deeply - understanding why the approach works, what the alternative approaches are, when each one is better - beats solving 500 problems by looking at the solution after ten minutes every single time. The candidates who get hired are the ones who can explain their thinking, not just produce correct output.
Focus on patterns, not individual problems. There are maybe fifteen to twenty core patterns that cover the vast majority of interview questions. Sliding window. Two pointers. BFS and DFS. Binary search variations. Dynamic programming (start with basic DP before jumping to hard problems, please). Backtracking. Topological sort. Union-Find. If you can recognise which pattern a problem belongs to, you are most of the way to solving it.
Practice in the language you are strongest in. I have seen people try to switch to Python for interviews because they heard it is faster to write. Then they spend the interview fighting with syntax instead of focusing on the problem. Bad idea. Use what you know.
Time yourself. Every single practice session. If you cannot solve a medium problem in 25 minutes, you are not ready yet. Harsh but true. The actual interview gives you about 30 to 40 minutes per problem, and that includes the time for clarifying questions, discussing your approach, and answering follow-ups.
Resources That Actually Help
LeetCode is fine. It is the standard for a reason. But do not just randomly solve problems. Use the curated lists. Blind 75 is a good starting point. NeetCode's roadmap organises problems by pattern, which is more useful than sorting by difficulty. Striver's SDE sheet is very popular among Indian engineers and for good reason - it covers the topics that actually come up in Indian MNC interviews specifically.
For system design, read "Designing Data-Intensive Applications" by Martin Kleppmann. It is dense but it is the best single resource I know of. The System Design Primer on GitHub is a solid free alternative. Watch some of the Gaurav Sen or Alex Xu videos to see how people talk through designs, because the talking part matters as much as the designing part.
System Design - Where Most People Fall Apart
If you have three or more years of experience and you are interviewing at any senior-ish level, you will get a system design round. And this is where I see the most pain. Because unlike coding problems, there is no single correct answer. The interviewer wants to see how you think. Can you identify requirements? Can you make trade-offs and explain why? Do you understand how systems behave under load?
Here is a dirty secret about system design interviews: the interviewer usually does not care whether your final design is perfect. They care about the journey. They want to see you ask good clarifying questions at the start. They want to hear you think out loud about trade-offs. "We could use a SQL database here for strong consistency, but if we need to scale reads, maybe a NoSQL store with eventual consistency makes more sense for this use case." That kind of reasoning is what gets you hired.
The candidates who fail system design are usually the ones who either go silent for long stretches (the interviewer has no idea what you are thinking if you do not say it out loud) or the ones who memorise a specific design and try to regurgitate it without adapting to the actual requirements being asked about.
Practice by designing systems you actually use. How would you design BookMyShow? Swiggy? The UPI system? WhatsApp? Pick one per week and spend an hour talking through it, ideally with a friend who can ask you hard questions. If you do not have a friend to practice with, record yourself and listen back. It is awkward. It is also incredibly effective.
The Behavioral Round Nobody Prepares For
This drives me absolutely crazy. I see engineers spend three months grinding algorithms and then walk into the behavioral round completely unprepared. "Tell me about a time you disagreed with your manager." Long silence. "Uh, I do not think that has happened." That is not a real answer, and the interviewer knows it.
Every engineer has dealt with disagreements, failures, tight deadlines, ambiguous requirements, and difficult team dynamics. You need to have these stories ready. Not memorised scripts - that comes across as fake - but thought through in advance so you can tell them clearly.
Use the STAR format. Situation, Task, Action, Result. Keep each story to about two minutes. Have at least eight to ten stories prepared that cover different themes: conflict resolution, leadership, failure and what you learned from it, working under ambiguity, going above and beyond, influencing without authority. You can often reuse the same story for different questions by emphasising different aspects of it.
For Amazon specifically: study the Leadership Principles. Print them out. For each one, have at least one concrete story from your work experience that demonstrates it. Amazon interviewers are literally trained to evaluate you against these principles. This is not optional advice. This is the game, and you either play it or you lose.
A Realistic Timeline
Forget 30 days. If you are starting from a point where you have not touched DSA since college, a realistic timeline is three to four months of consistent preparation. Not twelve hours a day - that leads to burnout. Two to three hours daily, consistently, with periodic breaks.
Weeks 1 through 4: rebuild your foundations. Data structures from scratch. Easy problems, lots of them, focusing on understanding not speed. Start reading one system design resource.
Weeks 5 through 8: medium problems, organised by pattern. Start doing one or two system design practice sessions per week. Begin preparing behavioral stories.
Weeks 9 through 12: hard problems selectively. Full mock interviews at least twice a week, covering all round types. Timed sessions. Start applying to companies you are less excited about first to get real interview experience before going for your top choices.
That last point is something nobody talks about. Your first two or three real interviews are going to be rough no matter how much you have prepared. There is a huge gap between practicing on your laptop and sitting in front of an actual interviewer on a video call with your career on the line. Use your early interviews as practice. Apply to some companies that are not your dream jobs, get some reps in, learn from the experience.
I talked to a candidate recently who got rejected from her first three interviews and was ready to give up. I told her to keep going. She got offers from two companies in the next month. The preparation was the same. The difference was interview stamina and familiarity with the actual pressure of the situation.
Things That Will Hurt You That Nobody Mentions
Talking too fast. When you are nervous, you speed up. The interviewer cannot follow your reasoning. Slow down deliberately.
Not asking clarifying questions. If someone gives you a problem and you immediately start coding, that is a red flag. Good engineers ask questions first. What are the constraints? What are the edge cases? What is the expected input size? Five minutes of clarification saves you from solving the wrong problem.
Giving up too quickly. If you hit a wall on a problem, do not say "I do not know." Say "Let me think about this differently." Try a brute force approach first and then optimise. Interviewers give partial credit. They want to see you fight through difficulty, not fold at the first sign of it.
Ignoring the interviewer's hints. When an interviewer says "Have you considered what happens when the input is very large?" they are practically giving you the answer. They are telling you to think about time complexity and possibly a more efficient approach. Take the hint. Some candidates are so focused on their own solution that they miss these nudges entirely.
Not knowing your own resume. If your resume says you worked on a distributed caching system, you better be able to explain that system in detail. I have seen people put impressive-sounding projects on their resume that they cannot actually discuss. That is a trust-killer. Better to have a simple project you know inside out than a complex one you can barely explain.
Here is my honest take on the whole process. It is imperfect. It over-indexes on certain skills and under-indexes on others. Some brilliant engineers fail these interviews and some mediocre ones pass them. But it is the system we have right now, and if you want to work at these companies, you have to work within it.
Stop looking for shortcuts. Stop watching motivational videos about cracking interviews. Open your laptop, pick a problem, set a timer, and start. Do that every day for three months. Prepare your system design and behavioral stories with the same discipline. Apply broadly. Handle rejection without spiralling. That is the actual playbook. It is not glamorous, but it works.
Comments