Cracking SDE and senior SDE interviews: DSA, design, and the rounds everyone forgets

There’s a lot of interview prep material out there. Most of it isn’t wrong, but there’s too much of it, and it rarely tells you what matters for the level you’re interviewing at.

This post splits it by level:

Software engineer (SDE 1, L3/L4, 0 to 3 years): DSA, plus behavioural.
Senior software engineer (SDE 2 and above, L5+): DSA, high-level design, low-level design, plus behavioural.

The behavioural and managerial rounds get their own section at the end, because they matter at every level and most people prepare for them last.

A note on sources: companies don’t publish their exact loops. The round structures below come from candidate write-ups and prep sites, so treat them as “what people usually see”, not a guarantee. Your recruiter will tell you the real loop. Ask them.

Before anything else: think out loud

This applies to every round, at every level, so it goes first.

The interviewer is scoring your thought process, not just your final answer. They can only score what they hear. If you sit in silence for ten minutes and then write a perfect solution, they have no idea how you got there, whether you considered alternatives, or whether you’d seen the problem before.

Talk the whole way through:

While understanding the problem. “So the input can have duplicates, and I need to return indices, not values. Let me confirm that.”
While choosing an approach. “The brute force is O(n²). I think a hash map gets this to O(n), because I only need to know if I’ve seen the complement before.”
While coding. “This loop builds the map. I’m checking before inserting so I don’t match an element with itself.”
While stuck. “I’m not sure how to handle the overlap case yet. One option is sorting first. Let me think about whether that breaks anything.”
While testing. “Let me run the empty input. Okay, that returns an empty list, which is what we agreed.”
In design rounds. “I’m choosing a NoSQL store here because the access pattern is a single key lookup and we need to scale writes. The trade-off is we lose joins, which we don’t need for this.”

Why it matters so much:

It turns the interview into a conversation. The interviewer can steer you before you spend 20 minutes on a wrong path.
It earns hints. If they hear where you’re stuck, they can nudge you. If you’re silent, they can’t.
It shows how you’d work on their team. Explaining your reasoning is a big part of a real engineering job: design reviews, code reviews, incident calls.
It gets you partial credit. A clear, well-reasoned approach that runs out of time often scores better than a correct answer with no explanation.

It feels unnatural at first. Practise it: solve problems out loud on your own, record yourself, or do mock interviews where the other person only gets to hear you, not read your mind.

Software engineer: DSA is most of the loop

For entry and mid-level roles at Google, Amazon, Microsoft, Meta and companies like them, the loop is usually:

An online assessment or phone screen with one or two coding problems.
2 to 4 coding rounds, each 45 to 60 minutes.
One behavioural or “hiring manager” round. At Amazon, Leadership Principle questions also show up at the start of the coding rounds.

Some companies add a light design question for SDE 1, like “how would you design the classes for a parking lot”. It’s rarely the deciding round at this level.

What the coding round checks

Getting the right answer is only part of it. Interviewers usually score you on:

Problem solving. Did you find a working approach, then a better one?
Communication. Did you explain your thinking before you started typing?
Code quality. Clear names, small functions, no copy-paste blocks.
Testing. Did you walk through an example and catch your own bugs?
Complexity. Can you state the time and space cost, and explain why?

A silent candidate who writes a perfect solution can score lower than one who talks through a slightly slower solution. The interviewer can’t give you credit for thinking they didn’t hear.

How to run a coding round

A simple structure that works:

Clarify. Repeat the problem back. Ask about input size, duplicates, negative numbers, empty input, and what to return when there’s no answer.
Examples. Work one small example by hand. Make up an edge case.
Brute force first. Say it out loud with its complexity, even if you won’t code it. It shows you can always get to a solution.
Optimise. Look for the pattern. Agree on the approach with the interviewer before writing code.
Code. Write it cleanly. Keep talking as you write: what each block does and why.
Test. Dry run your example. Then the edge cases. Fix bugs calmly.
Wrap up. State the final complexity and mention what you’d improve.

If you get stuck, say what you’re thinking. Interviewers often give hints, and taking a hint well is part of the score.

What to study

Learn patterns, not individual problems. Most interview questions are variations of a small set:

Arrays and strings: two pointers, sliding window, prefix sums.
Hashing: frequency counts, seen-before checks.
Binary search, including “binary search on the answer”.
Linked lists, stacks, queues, monotonic stacks.
Trees: traversals, BST properties, lowest common ancestor.
Graphs: BFS, DFS, topological sort, union-find, Dijkstra.
Heaps: top-K, merging sorted lists, scheduling.
Backtracking: subsets, permutations, combinations.
Dynamic programming: 1D, 2D, knapsack, strings, intervals.
Intervals and greedy.

Google tends to lean harder on graphs and DP. Amazon and Microsoft cover a broad mix of mediums. Recent company-tagged questions on LeetCode are the best signal for a specific company.

The easy question is only the warm-up

Many candidates spend weeks on hard graph and DP problems, then get surprised when the interview opens with something simple: a hash map, a stack, a heap.

That simple question is only the setup. Once you solve it, the interviewer changes a constraint and asks you to adapt. This follow-up is where most of the evaluation happens, and it’s where memorised solutions fall apart, because they were never understood well enough to change.

A few examples of how it plays out:

Two Sum. What if the input is sorted? What if the numbers arrive one at a time as a stream?
Top K frequent elements. What if the data is too large to fit in memory?
Merge intervals. What if intervals arrive one by one, and the merged result must stay correct after each?
LRU cache. How would you make it thread-safe? How would you add expiry for keys?
Hit counter for the last five minutes. What changes at a million hits per second?

None of these need an advanced algorithm. They need a solid grasp of the basic data structures you already think you know.

How to prepare:

Understand the everyday structures deeply. For hash maps, heaps, deques, stacks and linked lists, know what each operation costs and when each one is the right choice.
Change one constraint after every problem. Once you’ve solved something, ask what happens if the input is sorted, huge, streaming, or shared across threads, and solve that version too.
Write a first solution that’s easy to extend. Clear names and small functions turn a follow-up into a small change instead of a rewrite.
Explain what breaks before you fix it. For example: “Sorting works while everything fits in memory. For a stream, I’d keep a min-heap of size K instead.” Interviewers want to see that you noticed the limit, not just that you patched it.

A clean answer to an easy question, followed by two well-handled follow-ups, usually scores better than a hard problem solved with nothing after it.

Resources

NeetCode 150. The best short list of core problems, with video explanations.
Striver’s A2Z DSA sheet. Longer, more complete, good if your basics are rusty.
take U forward on YouTube. Striver’s channel, with clear, step-by-step explanations of each topic and problem, from brute force to optimal. It pairs well with the A2Z sheet, and its playlists on graphs, DP and trees are among the best free explanations out there.
LeetCode. Use the company tags in the last two to three weeks before an interview.

150 problems you actually understand are worth more than 600 you’ve seen once. After solving a problem, close it, wait a few days, and solve it again from scratch. If you can’t, you didn’t learn the pattern. Then change one constraint and solve it again.

Do some problems with a 45-minute timer, out loud, in a plain editor without autocomplete. That’s closer to the real thing than solving on LeetCode with the run button.

Senior software engineer: DSA + HLD + LLD

At SDE 2 and above, the coding bar doesn’t go away. Design rounds are added on top, and they usually decide whether you get the senior level or get down-levelled.

Reported loops at a few companies:

Amazon SDE 2: an online assessment, then 4 to 5 rounds. Typically DSA, LLD, HLD and a Bar Raiser, with Leadership Principle questions in almost every round.
Microsoft SDE 2: coding rounds, a design round covering LLD and HLD, and a final “As Appropriate” (AA) round with a senior leader.
Google L5: coding rounds, a system design round, and a Googleyness and Leadership round.
Atlassian senior: a coding screen, then DSA, LLD, HLD, a values round and a manager round.
Flipkart SDE 2: a machine coding round, DSA, HLD and a hiring manager round.
Confluent, LinkedIn, Salesforce, Oracle: the same building blocks. Coding, one or two design rounds, and a behavioural or manager round.

High-level design (HLD)

The question is something like “design Uber”, “design a URL shortener”, “design WhatsApp” or “design a rate limiter”. There’s no single correct answer. The interviewer wants to see how you reason about a large system.

A structure that works for most questions:

Requirements (5 min). Functional: what the system does. Non-functional: scale, latency, availability, consistency. Agree on what’s out of scope.
Estimates (2 to 3 min). Requests per second, storage per year, read/write ratio. Rough numbers are fine. They guide later choices.
API and data model. The main endpoints, the main entities, and how they’re stored.
High-level diagram. Clients, load balancer, services, databases, caches, queues. Keep it simple at first.
Deep dives. Pick one or two hard parts and go deep. For a chat app, that might be message delivery and ordering. For a URL shortener, ID generation and caching.
Trade-offs and failures. What happens when a node dies, a region goes down, or traffic spikes 10x? What did you give up, and why?

The topics that come up again and again:

SQL vs NoSQL, and when each fits.
Caching: where to cache, eviction, invalidation.
Sharding and replication. Consistent hashing.
Message queues and event streaming (Kafka, SQS) for decoupling and async work.
Consistency models: strong, eventual, read-your-writes.
Rate limiting, idempotency, retries with backoff.
Load balancing, CDNs, and how a request actually travels.

Say every decision and its reason out loud as you draw. A diagram with no reasoning behind it doesn’t tell the interviewer much.

At the senior level, the depth matters more than the breadth. Drawing ten boxes is easy. Explaining why one of them is Cassandra and not Postgres, and what that costs you, is the actual interview.

Resources:

System Design Interview Vol 1 and 2 by Alex Xu. The most common starting point, with clear worked examples.
Hello Interview. Free, well-structured guides and walkthroughs.
Designing Data-Intensive Applications by Martin Kleppmann. Slower to read, but it’s where the real understanding of databases, replication and streaming comes from. Worth it even outside interviews.

Practise by drawing out a design on paper or a whiteboard tool with a 45-minute timer, then comparing it with a reference solution. Better still, do mock interviews with a friend who’ll push back on your choices.

Low-level design (LLD)

The question is something like “design a parking lot”, “design an elevator system”, “design Splitwise”, or “design a rate limiter class”. This round is about object-oriented design and code you’d be happy to maintain.

What they look for:

Clear entities and responsibilities. Each class does one thing.
Good interfaces. Can a new vehicle type or payment method be added without rewriting everything?
SOLID principles, used where they help, not everywhere.
Design patterns where they fit naturally: Strategy, Factory, Observer, State, Singleton.
Concurrency, for some questions. Two users booking the same seat. Two elevators answering the same call.

A structure that works:

Clarify requirements and list the use cases.
Identify the main entities and their relationships.
Sketch the classes and interfaces.
Walk through one or two use cases end to end.
Write the core code.
Handle a change. Interviewers often add a new rule halfway (“now add VIP parking”). A good design absorbs it with a small change.

Machine coding is a variant common at Flipkart, Swiggy, and some Amazon India teams. You get 60 to 90 minutes to write working, runnable code for something like a cab booking service or a snake and ladder game, often followed by a review. Here, finishing a clean working core matters more than a perfect design. Practise with a timer, in your own IDE, and get comfortable starting from an empty project.

Resources:

awesome-low-level-design. A large collection of LLD problems with solutions in several languages.
Refactoring Guru. The clearest explanations of design patterns, with examples.

Coding at the senior level

Senior coding rounds are often the same difficulty as SDE 1, sometimes a little harder. The difference is in what’s expected around the code: cleaner structure, better naming, sharper reasoning about trade-offs, and less help from the interviewer. Don’t drop DSA practice when you start on design. Plenty of senior candidates fail the coding round because they assumed it would be easy.

The rounds people skip: managerial and values

Every company has at least one round that isn’t about code:

Amazon asks Leadership Principle questions in almost every round, and the Bar Raiser can veto a hire even when every other round went well.
Atlassian has a dedicated values interview.
Google has a Googleyness and Leadership round.
Microsoft has the AA round, often with a senior leader.
Most others have a hiring manager round that mixes behavioural questions with a look at your past projects.

These rounds aren’t a formality. Strong coding doesn’t save a weak behavioural round, especially at the senior level.

What they’re actually checking

Under the different names, they’re mostly asking the same things:

Do you take ownership, or wait to be told?
How do you handle conflict and disagreement?
Do you learn from mistakes, or explain them away?
Do you care about customers and users?
Can you work with people who aren’t like you?
At senior level: can you lead without authority, make decisions with incomplete data, and grow the people around you?

Build a story bank

Write down 8 to 10 real stories from your work before the interview. Not in your head. Written. Cover:

A hard technical problem you solved.
A disagreement with a teammate or manager, and how it ended.
A mistake you made, and what you changed afterwards.
A missed deadline or a project that went wrong.
A time you went beyond your role.
A time you helped someone else improve.
A decision you made without all the information.
Feedback you received and acted on.
For senior roles: a project you led end to end, a design you pushed back on, and a time you changed how your team works.

One good story can answer several questions. Map each story to the values or principles of the company you’re interviewing with.

Use STAR, but keep the S short

Situation, Task, Action, Result. Most people spend too long on the situation and run out of time before the action, which is the part being scored.

A rough split: 15% situation and task, 60% action, 25% result and learnings.

Say “I”, not “we”. They are hiring you, not your team. Be clear about what you personally did.
Use numbers. “Cut p99 latency from 800 ms to 120 ms” is better than “made it faster”. “Reduced on-call pages by about half” is better than “improved reliability”.
Include the trade-off. What did you give up? Why was it the right call?
End with what you learnt or what you’d do differently.

Expect follow-ups

Interviewers, especially Amazon’s Bar Raisers, will dig three or four levels into a single story. “Why did you choose that?” “What did your manager think?” “What would have happened if you hadn’t?” “What data did you have?”

This is why made-up or borrowed stories fail. Use real ones, and know the details.

Questions you’ll hear

Tell me about a time you disagreed with your manager.
Tell me about a time you failed.
Tell me about a time you had to deliver with a tight deadline.
Tell me about the most complex project you’ve worked on.
Tell me about a time you received critical feedback.
Tell me about a time you made a decision without enough data.
Why do you want to leave your current role? Why this company?

For the last two, be positive and specific. Talk about what you want to move towards, not what you’re running from.

Read the values before the interview

Amazon and Atlassian publish theirs:

Read them, pick a story for each one that matters most, and use the company’s own language where it fits naturally.

The hiring manager round

This one usually mixes behavioural questions with a deep dive into a past project. Pick one or two projects you know inside out. Be ready to draw the architecture, explain why it was built that way, what broke, what you’d change, and what part was yours. Have a few questions ready for them too: how the team works, what success looks like in the first six months, what the biggest challenge is right now.

One thing that’s changing

Google and Meta are piloting AI-assisted coding rounds. Instead of solving a fresh problem, you work in an existing multi-file codebase with an AI assistant available, and you’re judged partly on how well you check, debug and correct its output. It’s early, it varies by team and level, and the classic rounds haven’t gone away. But practising reading and changing unfamiliar code is now worth some of your time.

A rough prep plan

If you’re working full-time, a realistic plan looks like this.

Software engineer (8 to 10 weeks):

Weeks 1 to 6: DSA patterns, around 2 hours a day. Finish NeetCode 150 or most of the A2Z sheet.
Weeks 7 to 8: Timed practice, revision of weak topics, company-tagged problems.
Throughout: Write your story bank. Do at least two or three mock interviews.

Senior software engineer (10 to 12 weeks):

Weeks 1 to 4: DSA refresh. Focus on patterns, not volume.
Weeks 5 to 8: HLD. Read Alex Xu, practise one design every couple of days, and start DDIA in the background.
Weeks 9 to 10: LLD and machine coding. Do a few problems end to end in code.
Weeks 11 to 12: Mocks across all rounds, story bank polish, company-specific prep.

Adjust it to your gaps. If design is your strong side, spend more time on DSA, and the other way round.

So

Software engineer: DSA, solid communication in the coding round, and a handful of honest behavioural stories.
Senior software engineer: DSA, HLD and LLD, plus stories that show ownership, judgement and leadership.
Everyone: Think out loud in every round. And the managerial and values rounds are real rounds. Prepare for them like you prepare for the technical ones.

Pick a few good resources and finish them. That beats collecting fifty.

Was this useful?

Mohammed Ashfaq Ahmed

Senior Software Engineer at Confluent, based in Hyderabad. I write about building software and what I learn along the way. More about me