DEV Community: Emily Davis

The Interview Prep Stack I Used as a Senior Software Engineer Targeting Big Tech

Emily Davis — Mon, 25 May 2026 06:58:56 +0000

Preparing for senior software engineering interviews at big tech is not just about solving LeetCode problems.

At senior levels, the interview loop usually tests a broader set of skills:

Can you solve ambiguous engineering problems?
Can you design systems with reasonable tradeoffs?
Can you communicate clearly under pressure?
Can you explain past work with senior-level judgment?
Can you show technical depth without overcomplicating the answer?

I used a mix of AI tools, interview prep platforms, design tools, and personal tracking systems to prepare across these areas.

Tools I used

Category	Tool	URL	How I used it
General AI assistant	ChatGPT	https://chatgpt.com	Breaking down concepts, simulating interviewers, reviewing answers
AI writing / reasoning	Claude	https://claude.ai	Refining behavioral stories and system design explanations
Coding practice	LeetCode	https://leetcode.com	Core DSA practice and timed coding drills
Coding explanations	NeetCode	https://neetcode.io	Pattern-based review for common coding problems
Architecture sketching	Excalidraw	https://excalidraw.com	Quick system design diagrams
Product / UX thinking	Figma	https://figma.com	Wireframing product flows and interface-heavy design discussions
Notes and tracking	Notion	https://notion.so	Tracking problems, weak areas, stories, and interview learnings
Mock interviews	Skillio	https://tryskillio.com	Practicing realistic role-specific interviews and getting structured feedback

My overall approach

I split preparation into five tracks:

Coding interviews
System design
Behavioral interviews
Resume and project deep dives
Mock interview practice

This mattered because each track required a different preparation style.

Coding needed repetition and pattern recognition. System design needed structured thinking. Behavioral prep needed storytelling. Mock interviews needed pressure and feedback. Resume deep dives needed clarity on the actual impact of my work.

A single tool was not enough. The stack mattered because each tool solved a different problem.

1. Coding interviews: pattern recognition over random grinding

For coding, I used LeetCode and NeetCode as the core stack.

My goal was not to solve the maximum number of problems. It was to get comfortable with the most common patterns:

Arrays and hash maps
Two pointers
Sliding window
Binary search
Trees and graphs
BFS / DFS
Dynamic programming
Heaps
Intervals
Backtracking

The biggest improvement came when I stopped treating every problem as new.

Instead, after solving a problem, I would write down:

What pattern was used?
What was the key insight?
What mistake did I make?
Would I recognize this pattern again in a different problem?

I used ChatGPT mostly after solving or getting stuck. I avoided asking it for the final answer immediately. Instead, I used prompts like:

Give me a hint without revealing the full solution.

Or:

Explain the pattern behind this problem and show me how to recognize similar problems.

That made the AI useful without turning it into a shortcut.

For senior engineer interviews, I also practiced explaining the solution out loud. A correct solution is not enough if the interviewer cannot follow your reasoning.

2. System design: practicing structure, not memorizing architectures

System design prep was the most important part of my senior SWE preparation.

At senior levels, system design interviews are usually less about whether you know the perfect architecture and more about whether you can reason through ambiguity.

I used Excalidraw for quick architecture sketches. I preferred it over heavier tools because it forced me to stay rough and fast.

My system design flow usually looked like this:

Clarify requirements
Define functional and non-functional constraints
Estimate scale if needed
Sketch the high-level architecture
Deep dive into one or two critical components
Discuss bottlenecks
Discuss tradeoffs
Close with failure modes and future improvements

I used AI tools to stress-test my designs.

For example, after designing a feed system, I would ask:

Act like a senior staff engineer interviewing me. What are the biggest weaknesses in this design?

Or:

What follow-up questions would a big tech interviewer ask on this architecture?

This was useful because system design prep often creates a false sense of confidence. You can read a polished architecture and feel like you understand it, but the real test is whether you can defend your choices live.

I also used Figma occasionally when the design problem involved user-facing flows, dashboards, internal tools, or configuration-heavy products. It helped me think through the interface, not just the backend.

That said, Figma was secondary. For most system design interviews, Excalidraw was enough.

3. Behavioral interviews: building a reusable story bank

Behavioral prep is easy to underestimate.

For senior engineers, behavioral interviews are not just about being pleasant. They test signals like:

Ownership
Conflict resolution
Technical leadership
Mentorship
Decision-making under ambiguity
Cross-functional collaboration
Handling failure
Raising engineering standards

I created a story bank in Notion.

Each story had this structure:

Field	What I wrote
Situation	What was happening?
Problem	Why did it matter?
Role	What was I responsible for?
Action	What did I actually do?
Tradeoffs	What alternatives did I consider?
Result	What changed because of my work?
Reflection	What would I do differently now?

I did not want robotic STAR answers. The goal was not to memorize scripts. The goal was to have well-structured raw material.

Then I used AI to improve the stories.

Useful prompts included:

Make this story sound more senior without exaggerating my role.

What leadership signals does this answer show?

What follow-up questions would an interviewer ask?

Rewrite this answer to be tighter and more outcome-driven.

The main lesson: behavioral prep gets much better when you treat it like product positioning. You are not inventing stories. You are packaging real work clearly.

4. Resume and project deep dives: preparing for scrutiny

For senior software roles, interviewers often go deep into past projects.

They may ask:

Why did you choose this architecture?
What was the hardest technical problem?
What would break at 10x scale?
What did you personally own?
How did you measure success?
What tradeoffs did you make?
What would you do differently?

I picked 4-5 major projects from my resume and created a deep-dive sheet for each.

The template looked like this:

Area	Notes
Context	What was the business or engineering problem?
My role	What did I directly own?
Architecture	What was the technical design?
Scale	Users, requests, data size, latency, cost, or team size
Tradeoffs	What options did we reject and why?
Failure modes	What could go wrong?
Impact	Metrics, reliability improvements, revenue, cost, speed, or adoption
Lessons	What I learned as an engineer

This helped me avoid vague answers like “I worked on improving performance.”

Instead, I could say what changed, why it mattered, and how I made decisions.

This is especially important at senior levels because interviewers are looking for judgment, not just implementation ability.

5. Mock interviews: where the gaps became obvious

The biggest difference between studying and interviewing is pressure.

You may understand a concept when reading it, but struggle when you need to explain it live, structure an answer, and respond to follow-ups.

That is where mock interviews helped.

I used Skillio for practicing realistic interviews and getting feedback. The useful part was having a more interview-like environment instead of just chatting with a generic AI assistant.

For me, the value of mock interviews was in identifying issues like:

Rambling answers
Weak opening structure
Missing clarifying questions
Jumping into implementation too early
Not explaining tradeoffs clearly
Giving behavioral answers without enough impact
Sounding less senior than the actual experience justified

This is the kind of feedback that is hard to get from solo prep.

I also used ChatGPT for lighter interview simulation, especially for quick drills. For example:

Interview me for a senior backend engineer role. Focus on distributed systems and ask one question at a time.

But for more structured interview prep, I preferred using a dedicated mock interview flow.

How I used AI without becoming dependent on it

AI was useful throughout the process, but I tried not to let it replace thinking.

The best use cases were:

Use case	Good AI usage	Bad AI usage
Coding	Hints, pattern explanation, complexity review	Asking for full solutions immediately
System design	Stress-testing tradeoffs	Memorizing generated architectures
Behavioral	Tightening stories	Inventing fake experience
Resume prep	Finding weak spots	Over-polishing until it sounds unnatural
Mock interviews	Simulating pressure	Avoiding real practice

The rule I followed was simple:

Use AI to expose gaps, not hide them.

If I could not explain the answer without AI, I was not prepared.

My weekly preparation structure

A typical week looked something like this:

Track	Frequency	Focus
Coding	4-5 days/week	Pattern practice and timed problems
System design	2-3 days/week	One full design problem plus review
Behavioral	2 days/week	Story bank refinement and live answers
Resume deep dives	1-2 days/week	Project-level technical detail
Mock interviews	1-2 sessions/week	Pressure testing and feedback

This was not perfectly followed every week, but it gave structure to the preparation.

The most important thing was balancing depth and repetition.

Only doing coding made the prep too narrow. Only reading system design made it too passive. Only writing behavioral stories made it too theoretical.

The combination mattered.

What I would do differently next time

If I were doing this again, I would start mock interviews earlier.

I spent too much time preparing in isolation before testing myself in interview-like conditions. That delayed useful feedback.

I would also create my behavioral story bank earlier. Senior interviews often use past experience as the backbone of the conversation, so having strong stories helps across multiple rounds.

Finally, I would track mistakes more rigorously.

Not just:

I got this problem wrong.

But:

I failed because I did not identify the sliding window pattern.

Or:

My system design answer lacked a clear bottleneck analysis.

The more specific the mistake, the easier it is to fix.

Final thoughts

Interview prep for senior software engineering roles is not just about knowledge.

It is about performance.

You need to retrieve information quickly, structure ambiguous problems, explain tradeoffs, and communicate in a way that gives interviewers confidence.

The tools helped, but the system mattered more:

Use coding platforms for repetition.
Use AI tools for feedback and stress testing.
Use design tools to make architecture visible.
Use notes to track patterns and stories.
Use mock interviews to practice under pressure.

That combination made my preparation much more deliberate and much less random.

How I Prepared for PM Interviews

Emily Davis — Thu, 05 Mar 2026 10:40:46 +0000

How I Prepared for PM Interviews (Targeting Google, Uber & Co.)

When I decided to seriously prepare for Product Manager interviews, I was targeting companies like Google and Uber.

I knew two things:

The bar would be high.
“Winging it” wasn’t going to work.

This post is not an exhaustive guide. It’s simply what actually worked for me — especially what moved the needle the most.

Spoiler: mock interviews.

Step 1: I Treated Prep Like a Product

Before diving into frameworks and question banks, I paused and asked:

What skills are being evaluated?
Where am I weak?
How will I measure improvement?

For PM roles at companies like Google and Uber, interviews usually test:

Product sense
Execution / metrics
Analytical thinking
Leadership & drive
Communication clarity

Instead of studying randomly, I mapped my prep to these buckets.

This alone made my prep feel structured instead of chaotic.

Step 2: I Used AI — But Not the Way You Think

AI didn’t replace practice. It accelerated feedback.

Here’s how I used it:

1. Brainstorming partner

When practicing product design questions (“Design a product for X”), I would:

Draft my answer.
Ask AI to critique it like a senior PM interviewer.
Request pushback: “Where is this weak?” “What follow-ups would you ask?”

It forced me to defend my thinking.

2. Generating realistic follow-ups

One mistake I made early: practicing only the first question.

Real interviews don’t stop there.

So I used AI to simulate:

Edge case challenges
Metric trade-off questions
Prioritization conflicts

It made my answers less rehearsed and more flexible.

3. Tightening communication

Sometimes I’d paste a long, messy answer and ask:

“How can I say this more concisely while keeping the structure strong?”

Over time, I internalized cleaner communication patterns.

But here’s the important part:

AI improved polish.
It did not build instinct.

Mock interviews did.

Step 3: Mock Interviews Changed Everything

Nothing — and I mean nothing — improved my performance more than mock interviews.

Here’s why.

1. Real-time pressure exposes gaps

When practicing alone, you feel smart.

When someone interrupts you with:

“Why that metric?”
“Is that really the biggest user pain?”
“What trade-offs are you making?”

You suddenly realize where your thinking is shallow.

I still remember one mock where I confidently proposed a feature and the interviewer asked:

“What would you cut from the roadmap to ship this?”

I had no answer.

That moment hurt — but it permanently upgraded how I approached prioritization.

2. You Fix Communication, Not Just Thinking

In one mock, I spent 8 minutes structuring the problem.

The feedback:

“This was solid, but too slow. In a real interview, you’d run out of time.”

That changed my pacing completely.

Mocks helped me:

Get sharper openings
Be hypothesis-driven
Avoid rambling
Drive conversations instead of reacting to them

3. Patterns Start Clicking

After ~15–20 mocks, something interesting happened.

Questions stopped feeling random.

“Improve Uber Eats”
“Design a feature for Google Maps”
“Launch a new product in X market”

They all started feeling like variations of the same core muscles:

Clarify user
Identify pain
Prioritize ruthlessly
Tie everything to impact

That confidence only came from repetition under pressure.

Step 4: I Reviewed My Own Performances Brutally

After each mock, I wrote down:

Where did I hesitate?
What feedback repeated?
Did I drive or react?
Did I quantify impact?

Patterns emerged:

I over-explained.
I sometimes skipped trade-offs.
My metrics weren’t always crisp.

Instead of fixing everything at once, I picked one weakness per week.

That compounding effect was real.

What Helped the Most?

If I had to rank what mattered most:

Mock interviews (by far)
Reviewing and iterating deliberately
Using AI for structured feedback
Reading frameworks (least impactful after a point)

Frameworks are useful early.
Mocks are transformative later.

One Anecdote That Stuck With Me

In an early mock, I was asked:

“How would you improve driver retention at Uber?”

I jumped straight into features.

The interviewer stopped me:

“What’s the root cause?”

I hadn’t even defined the problem properly.

From that day on, I forced myself to:

Diagnose before prescribing
State assumptions explicitly
Anchor every solution in a user pain

That shift alone made my answers feel more senior.

Final Thoughts

Preparing for PM interviews — especially for companies like Google and Uber — is less about memorizing frameworks and more about building product instinct under pressure.

AI can:

Sharpen you
Stress-test ideas
Improve clarity

But it won’t replace the discomfort of someone challenging your thinking live.

If you’re preparing right now, my biggest advice:

Do more mocks than you think you need.
Then do five more.

That’s where the real growth happens.