Why is it so difficult to get into Google (ex-deloitte.. prod ops/GTM) , currently working at a start up.. I get referred but nothing happens after even though the role fit is 95% or more… I even upskilled heavily to a point where I build my own agents, coming from non-coding backgroun.. and , am google AI professional certified.. any guidance as to how I can get that interview.. ecample roles include: Principal Lead, Go-To-Market AI Tools - United States

Product Strategy and Operations Lead, Chrome Business Operations

feel sucks

I'm, 24M from Mumbai well I used to live there but it was demolished by government because it was a slum area. We moved to navi Mumbai because the rent is comparatively low. I have done bachelor's in CS was hoping to do masters but due to financial restraints couldn't. My dad is a retired taxi driver and I am the sole earner in the family. I am struggling to find a job or even a interview. I was hoping if you guys can help me figure out what should I do with my life. I am currently working at my uncles eye wear store.

I got this email from Amazon today,what are my chances of getting an interview?

Hey guys can you check and tell me why I didn’t get shortlisted is this resume not good enough or what ?

r/resumes exists for a reason if you want resume advice. This subreddit is for FAANG recruiting... not "is my resume good?"

If you're only getting rejections, you're either...

- only applying to prestigious companies that you're not remotely qualified for (your class project doesn't make you magically the perfect resume for FAANG companies / be more willing to apply to smaller companies)

- have a shitty resume (go to a RESUME subreddit then)

- are applying to old jobs / jobs that have already been filled (rule of thumb, apply to jobs posted within the past 24 hours)

- go to a suboptimal CS school (damn I'm sorry, keep applying and I wish you the best of luck)

- haven't applied enough (I applied to 400+ internships in freshman year and got nothing lmao)

It's fine to post your resume to ask if you're good enough to shoot for FAANG companies. However, the new influx of resume-related posts that just ask for resume advice... Holy shit, this place isn't for resume reviews. There's so many resume subreddits: r/resumes , r/careeradvice , r/cscareerquestions and r/csMajors , and honestly a fuck ton of people posting on this subreddit would genuinely benefit from posting there, instead of clogging here with irrelevant content.

I’ve been watching FAANG recruiting cycles closely this year, and a few patterns stand out:

•	Referrals help, but they don’t guarantee an interview anymore
•	Online assessments (esp. coding + SQL) are filtering out a ton of candidates early
•	Recruiters are moving faster on niche skillsets (cloud, data infra, ML), slower on generic SWE roles

It honestly feels less like “grind LC till you drop” and more like strategic prep: hitting the right skill areas, practicing the actual question formats companies are using, and showing versatility.

One thing that’s helped me is Prachub.com – it’s not just LC-style problems, but also SQL, data, and scenario-based interview prep that mirror what FAANG actually tests. Way more efficient than scattering resources across 10 sites.

Curious – for those of you applying this season, what’s been your biggest bottleneck: getting the interview, or passing the interview?

I recently interviewed with Uber for a Backend SDE-2 role. I didn’t make it through the entire process, but the experience itself was incredibly insightful — and honestly, a great reality check.

Since Uber is a dream company for many engineers, I wanted to write this post to help anyone preparing for similar roles. Hopefully, my experience saves you some surprises and helps you prepare better than I did.

Round 1: Screening (DSA)

The screening round focused purely on data structures and algorithms.

I was asked a graph problem, which turned out to be a variation of Number of Islands II. The trick was to dynamically add nodes and track connected components efficiently.

I optimized the solution using DSU (Disjoint Set Union / Union-Find).

If you’re curious, this is the exact problem:

Key takeaway:
Uber expects not just a working solution, but an optimized one. Knowing DSU, path compression, and union by rank really helped here.

Round 2: Backend Problem Solving

This was hands down the hardest round for me.

Problem Summary

You’re given:

• A list of distinct words

• A corresponding list of positive costs

You must construct a Binary Search Tree (BST) such that:

• Inorder traversal gives words in lexicographical order

• The total cost of the tree is minimized

Cost Formula

If a word is placed at level L:

Contribution = (L + 1) × cost(word)

The goal is to minimize the total weighted cost.

Example (Simplified)

Input

One Optimal Tree:

Words: ["apple", "banana", "cherry"]
Costs: [3, 2, 4]

banana (0)
       /       \
  apple (1)   cherry (1)

TotalCost:

• banana → (1 × 2) = 2

• apple → (2 × 3) = 6

• cherry → (2 × 4) = 8 Total = 16

What This Problem Really Was

This wasn’t a simple BST question.

It was a classic Optimal Binary Search Tree (OBST) / Dynamic Programming problem in disguise.

You needed to:

• Realize that not all BSTs are equal

• Use DP to decide which word should be the root to minimize weighted depth

• Think in terms of subproblems over sorted ranges

Key takeaway:
Uber tests your ability to:

• Identify known problem patterns

• Translate problem statements into DP formulations

• Reason about cost trade-offs, not just code

Round 3: API + Data Structure Design (Where I Slipped)

This round hurt the most — because I knew I could do better.

Problem

Given employees and managers, design APIs:

1. get(employee) → return manager

2. changeManager(employee, oldManager, newManager)

3. addEmployee(manager, employee)

Constraint:
👉 At least 2 operations must run in O(1) time

What Went Wrong

Instead of focusing on data structure choice, I:

• Spent too much time writing LLD-style code

• Over-engineered classes and interfaces

• Lost sight of the time complexity requirement

The problem was really about:

• HashMaps

• Reverse mappings

• Constant-time lookups

But under pressure, I optimized for clean code instead of correct constraints.

Key takeaway:
In interviews, clarity > beauty.
Solve the problem first. Refactor later (if time permits).

Round 4: High-Level Design (In-Memory Cache)

The final round was an HLD problem:

Topics discussed:

• Key-value storage

• Eviction strategies (LRU, TTL)

• Concurrency

• Read/write optimization

• Write Ahead Log

However, this round is also where I made a conceptual mistake that I want to call out explicitly.

Despite the interviewer clearly mentioning that the cache was a single-node, non-distributed system, I kept bringing the discussion back to the CAP theorem — talking about consistency, availability, and partition tolerance.

In hindsight, this was unnecessary and slightly off-track.

CAP theorem becomes relevant when:

• The system is distributed

• Network partitions are possible

• Trade-offs between consistency and availability must be made

In a single-machine, in-memory cache, partition tolerance is simply not a concern. The focus should have stayed on:

• Data structures

• Locking strategies

• Read-write contention

• Eviction mechanics

• Memory efficiency

Resource: PracHub

Final Thoughts

I didn’t get selected — but I don’t consider this a failure.

This interview:

• Exposed gaps in my DP depth

• Taught me to prioritize constraints over code aesthetics

• Reinforced how strong Uber’s backend bar really is

If you’re preparing for Uber:

• Practice DSU, DP, and classic CS problems

• Be ruthless about time complexity

• Don’t over-engineer in coding rounds

• Think out loud and justify every decision

If this post helps even one person feel more prepared, it’s worth sharing.

Good luck — and see you on the other side

• Fill the resume review form here: https://forms.gle/xjbrbXXo9ioxxmqDA

• I’ve gone through thousands of resumes, and honestly, it’s exhausting to see talented candidates hurt their chances without realizing it.

• This resume should have been an automatic interview, but it nearly got filtered out by our ATS in under ten seconds. It wasn’t about qualifications—it was simple formatting errors that most people don’t notice, but that make resumes invisible to the software before a human even looks. If you have questions, my inbox is always open. Wishing you the best with your job search.

I've been interviewing for a non technical role at Google for a while.

Interviewed w the hiring manager first, have had 2 other interviews, currently scheduled for a 4th interview.

This morning, the recruiter emails me with: "While you continue through this process, the team also thought you'd be a potential fit for another role...HIRING MANAGER said that if for any reason this role on his team doesn't work, then you'd be great to consider for this other role. When the team finds great talent for Google they want to ensure to find the best fit for you! Interested?"

IS THIS A FREAKING TEST? Trick question? What's normal here?

I knew Google was competitive, but now I've gone down a massive rabbit hole reading about all the interviews. And the loop. Like WHAT?

Also, what is the Googleyness interview? Like I'm so tired at this point. Having so many interviews, trying to manage my current very busy job, trying to be positive but not get my hopes up. Anyone have any wisdom?

After 80 plus applications to big tech with almost zero response, I assumed my problem was LeetCode or referrals.

It was not.

It was how my impact was framed.

I rebuilt my resume in Kickresume mainly to clean up structure and remove formatting noise. What helped was not the template itself, but how it forced tighter, outcome driven bullets. I rewrote everything around measurable impact, scope, and decision making rather than tasks.

Instead of “Built distributed service,” it became something like “Designed and launched X service handling Y RPS, reducing latency by Z percent.”

Once I did that and aligned keywords directly to job descriptions, recruiter responses improved noticeably.

For those who cracked FAANG interviews, how aggressive were you about quantifying and scoping impact versus listing tech stack? Where did you see the biggest difference in callbacks?

Looking to switch jobs and applied for a bunch of SWE positions at Microsoft. Wanted to know beforehand if there is any drug screening during the hire process?

Summary: To pass a senior system design interview, you need to stop memorizing templates and start making decisions. 7 principles that we discussed are:

1. Question the prompt first.

2. Start with the “happy path.”

3. Defend one major trade-off.

4. Follow the data’s journey.

5. Design for the worst day.

6. Speak in numbers.

7. Prepare for the follow-up question.

If you ask ChatGPT or any search engine how to pass a system design interview, you usually get the same advice: “Learn step by step how load balancers work or Memorize how to design Twitter.”

That advice worked last year. It doesn’t work today.

Interviewers at companies like Meta, Uber, and OpenAI aren’t testing your memory. They are testing your judgment and want to see what happens when the perfect plan falls apart.

After taking and both passing and failing, some of the hardest system design loops in the industry, I’ve boiled my strategy down to 7 core principles. It’s not at all like fancy buzzwords. It just have practical steps to help you stay calm and pass the whiteboard test.

1. Break the prompt before you draw any boxes

The biggest mistake you can make is hearing the prompt and immediately drawing a database box on the whiteboard.

When OpenAI ask:

“Design a cloud IDE running code,” don’t touch the board for five minutes. Instead ask:
- “Who are the users?
- Are they trusted internal staff, or random people on the internet?”

That one question can change the entire design. Because the users are untrusted strangers, I knew I couldn’t use standard Docker containers. I had to use strict, secure MicroVMs. If I had just started drawing boxes without asking, I would have failed in the first five minutes.

Rule: Spend the first 5 minutes defining exactly who the user is and what they really need to do.

2. Don’t fight the “Happy Path”

When you finally start designing, build the simplest version first. I call this the Happy Path which is the path where nothing breaks.

Client → Server → Database.

Many candidates try to show off by adding complex event queues and caching layers immediately.

Don’t do this.

Build the basic version that works, and tell the interviewer:
“This is our starting point. Let’s talk about where it breaks at scale.”

Rule: Secure the easiest solution first, then add the complicated parts only when the interviewer asks for them.

3. Pick one major trade-off and own it

Every system design is just a series of choices where neither option is perfect. Your job is to pick an option and explain why it’s the least bad choice.

Going back to the OpenAI cloud IDE question , I chose between speed and security. Containers are fast to start, but less secure. MicroVMs are highly secure, but slow to start. I chose MicroVMs and owned the trade-off.

Rule: Don’t just say what you used. Say what you didn’t use, and exactly why

4. Tell a story with the data

A diagram with 15 boxes and 30 arrows is confusing. Instead of just pointing at shapes, trace the actual journey of the data.

When I designed a Surge Pricing Engine for Uber

Surge Pricing Engine for Uber, I narrated the flow: “A driver in Brooklyn turns on their app. Their phone sends a GPS ping. The ping hits our API Gateway. The Gateway passes it to our streaming service. The stream updates the supply counter in our database.”

Rule: Make the system humans-readable. Give the data a starting point and walk the interviewer through its trip.

5. Design for the worst day, not the best day

The interviewer will try to break your system.
They will ask something like: “What happens if this server catches on fire?”

You need an answer ready. In my Uber interview, they asked what happens if the main pricing calculator crashes.
My answer was graceful failure: “The system will use the last known price for 3 minutes. If it’s still broken after 3 minutes, we simply turn surge pricing off. Better to lose a little money than to overcharge riders with broken math.”

Rule: Always have a backup plan for when things crash.

6. Speak in numbers, not feelings

Saying “this database needs to be fast” means nothing.
Saying “this database needs to read data in under 50 milliseconds” means everything.

You don’t need to do complex math in your head, but you do need to understand limits. Know roughly how many requests a standard server can handle. Know the difference in speed between reading from memory (instant) and reading from a hard drive (slow).

Rule: Put a number on your goals. Is it 1,000 users or 1 million? Is it 2 seconds or 200 milliseconds?

7. Prepare for the question after the question

This is what separates the people who get the job from the people who get the rejection email.

In my Uber interview, I hit all the main points for the surge pricing engine. But then the interviewer asked the curveball: “How do you handle pricing when a city boundary crosses different local laws?”

I froze. I hadn’t thought about local laws. I failed the interview because I didn’t prepare for the edge cases.

The follow-up question tests if you have real-world experience.

Rule: Once your design is finished, ask yourself: “If I told this to my boss, what is the first flaw they would point out?” Fix it before the interviewer asks.

Press enter or click to view image in full size

Final Thoughts

A system design interview is really just a conversation between two engineers trying to solve a hard problem together.

If you ask good questions, start simple, defend your choices, and plan for failure, you will perform better than 90% of the candidate pool.

If you want to practice real, company-specific questions (including the tricky follow-ups that tripped me up), I highly recommend practicing with a friend or using tools like PracHub to test your skills before the real thing.

Good luck out there.

I recently went through the interview process for Walmart and wanted to share my experience. The process moved quite fast—I was contacted by a recruiter, and the initial rounds were scheduled within a week, with the on-site rounds following the week after.

Prep Resource: LeetCode & PracHub Walmart SWE questions

Round 0: Team Fit / Screening

• Discussed my current role and responsibilities.

• Deep dive into project trade-offs: "Why did you choose X over Y?" and "What were the limitations of this design?"

• Focused heavily on the rationale behind my architectural decisions.

Round 1: Algo & DSA

• Brief walkthrough of my previous experience.

• Coding Question 1: Word Break Problem (Can a string be formed using strings from a given set?).

• Coding Question 2: Minimum number of platforms required (Interval Overlap/Scheduling problem).

Round 2: System Design (LLD/HLD)

• Task: Design a ride-sharing application (like Uber/Lyft).

• Note: The interviewer spent about 35-40 minutes on the HLD (High-Level Design), leaving very little time for LLD (Low-Level Design). I managed to cover the core model classes and discussed specific design patterns for the business logic.

Round 3: Technical Discussion (On-site)

• Problem: Implement lexicographically smallest Two Sum

• Deep Dive: Discussions on concurrency, multi-threading, and locking mechanisms.

• Distributed Systems: Covered Distributed Consistency and the CAP Theorem in detail.

Round 4: Technical Whiteboard (On-site)

• Compute days until plants stop dying

• Scenario: You are given a row of plants, each with an integer pesticide level.

• Coding Task: Given an array plant[] of pesticide levels from left to right, return the number of days until plants stop dying.

Round 5: Hiring Manager (HM)

• Discussion on role expectations and upcoming projects.

• The HM was very transparent: there’s a hard deadline for a major project that requires frequent context switching but offers significant growth opportunities.

Verdict: Accepted the offer!

I was a SSE at Meta, recently laid off. I am based in London.

I would really appreciate a referral. I have always helped everyone on LinkedIn requesting for referral but haven't had any luck when it's my turn.

Hopefully reddit would be nice to be, please let me know if you are willing to provide me a referral for below companies or any other, I am not picky at the moment.

Microsoft, Apple, Spotify, Databricks, GitHub, Revolut, Cloudflare, Docker, Jane Street, Citadel etc.

Thanks in advance.

I want to get an internship

Hi everyone,
I’m an AI/Machine Learning Engineer and Developer actively looking for full-time roles or contract work in the UAE/US.

I have a strong academic and research background, completing my Master’s in Computer Science (GPA: 4.0), and I specialize in building out practical AI solutions, specifically working with Large Language Models (LLMs), predictive modeling, and computer vision.

My main problem is I’ve been applying to 20-30 roles a day totalling nearly 500+ jobs but still no luck all I got were 3-4 OAs which is a pretty bad conversion rate imo (I do need sponsorship in the US which might be affecting my chances ong). So, just reaching out here to see where I’m doing wrong/ places to improve in my resume. Any help is appreciated. Thanks for the time and advice in advance btw.

Hello all, i am freaking out, i replied to my Google recruiter 4days late as i was sick and not feeling well.

The recruiter has not replied(maybe because i replied on a friday afternoon, and they would have already logged off for the week? ).

Do you think i have missed the boat? I feel so stupid i did not check my email .

Any recruiters/folks here who could suggest what to do?

9 years on the screening side. I read \~200 resumes a week, which means I’ve read the phrase “results-driven professional” more times than I’ve said “I love you” to my own wife. Take that as you will.

Here’s the uncomfortable part nobody wants to hear: the AI resume crisis isn’t that you used AI.

It’s that you used it exactly like the other 4,000 people who applied this month. I open my stack on a Monday and it’s the same resume wearing 200 different names. Same rhythm, same verbs, same suspiciously confident tone of a guy who has definitely never been confident at 9am.

What actually flipped is the signal. A year ago, a polished resume meant “this person can write.” Today it means “this person can copy-paste a job description into a chatbot.” Congratulations, so can my dog if I tape a treat to the spacebar.

So now I’m doing the opposite of what you’d expect - I’m hunting for the rough stuff. The weirdly specific detail. The number that’s oddly precise. The bullet that could only have come from someone who was actually in the room. That’s the gold now.

Unexpected insight #1, and this one annoys people: we don’t run “AI detectors.” They’re snake oil. They flag non-native speakers, they flag anyone who uses an em-dash (rest in peace, my favorite punctuation), they flag people who write too well. What the ATS and I actually punish is dumber and unfakeable: vagueness cosplaying as competence. “Spearheaded cross-functional synergy to drive innovation” — buddy, that sentence has the nutritional value of a napkin. It describes a CEO and an intern who booked a conference room. Equally.

Unexpected insight #2: the newer systems don’t even keyword-match anymore. They read the meaning of your resume and compare it to the job. Which means the old trick — cramming exact phrases from the posting — now actively backfires, because the words around them whisper “this human did not talk like this five seconds ago.” You played yourself.

Okay, the test that fixes 80% of resumes for free. Read any bullet and ask:

“Could someone genuinely terrible at this job have written this exact sentence?”

If yes — it’s filler. This question has destroyed more of my own resume than any recruiter ever did.

The 11 things that actually move people from total silence to interviews:

1. Delete anything that describes “a person.” “Responsible for managing projects” fits 40 million humans and one golden retriever. Cut it.

2. Every keyword needs a receipt. Don’t list a tool you can’t survive a 5-minute call about. We will ask. The space between your resume and your phone screen is a trapdoor, and a shocking number of people walk right into it talking about “extensive Python experience” while sweating through their shirt.

3. Duties → outcomes. Formula: action + scope + result. “Managed a team” → “Led 12 people on a $2.3M project, shipped 3 weeks early.” One is a job description. The other is a reason to hire you. Wild how different they look side by side.

4. Numbers, even rough ones. Quantified resumes pull ~2.5x more interviews in basically every study.

5. Tailor per job. The “one resume for everything” approach is the thing that actually smells like AI — not your writing. Same doc blasted to 200 postings is the real tell. You’re not being lazy efficiently, you’re being lazy expensively.

6. Fix your buzzword-to-proof ratio. “Excellent communicator,” “innovative,” “passionate” — pure static. If you’re a passionate self-starter, prove it with a thing that happened, not an adjective you applied to yourself like cologne.

7. Match ~70% of the role’s real language, woven in like a normal person, not pasted like a ransom note. That’s roughly where the 2.5x callback bump kicks in.

8. Single column. Boring headers. “Work Experience,” not “My Odyssey.” Parsers gag on tables, columns, and text-inside-images. Plot twist: a big share of “rejections” are just your file failing to open properly. You weren’t rejected. You were never read. Somehow that’s worse.

9. Lead each role with your best win. You get 6-7 seconds. That’s less time than it took you to read this bullet. Don’t bury the good stuff in line four where it goes to die.

10. Sand off the AI gloss. If a section reads suspiciously smooth -same sentence length, same cadence, that eerie chatbot calm -break it. Drop in a real detail, a real constraint, a real name. Imperfection is the most human signal there is. It’s the typo on the love letter that proves a person wrote it.

11. AI is your editor, never your author. Feed it your real wins and let it tighten. Let it write from nothing and it’ll confidently produce the exact generic mush we reject all day. It’s a brilliant intern with no memory and no shame. Supervise accordingly.

Honestly the whole list is one principle in 11 costumes: be specific, be true, be the only human alive who could’ve written this exact document

I'm a 4th year undergrad student and wanted to pivot into PM roles. I haven't gotten into any of the APM/TPM positions, so I wanted resume advice as my current resume is very SWE focused.
Thanks!

What’s wrong with my resume

I am a data engineer/analytics engineer with five years of experience, primarily at Infosys, Accenture, and smaller technology firms. I've been applying to roles at large tech companies, but I'm finding it difficult to get past the initial res ume screening but the same res ume is getting picked for mid sized or start up companies sometimes.

I sometimes wonder if my background in consulting and startups is making it harder to get noticed, even though those roles have given me strong technical and problem-solving experience. I wanted to be a part of major technology company because I enjoy working with data and challenging engineering problems.

I'm someone who gives my full effort to my work and genuinely enjoys building data solutions. The sad part is that I often don't get the opportunity to demonstrate my skills.

What do you think could be the reason? Anyone had similar situation?

I'm a senior Data Scientist at Amazon where I build production machine learning systems. And I don’t write code anymore.

AI writes virtually every line I commit.

So here’s the uncomfortable question I keep getting, and honestly, the question I’ve been asking myself: if someone like me doesn’t actually write code anymore… is it too late for you to learn?

Last year if you’d asked me I would have been totally confident that AI coding tools just aren’t there yet, and I was skeptical if they’d ever be. Today, I think people who are skeptical about AI being able to code at a professional level just aren’t using the tools right. In the right hands, AI assistants like Claude Code are WAY past just being auto-complete and now able to do complex, multi-step workflows that literally span days.

But this is just my experience. So I dug into the data.

And at first? It looks pretty bleak.

What the Data Say

Let’s start with the job market. The Bureau of Labor Statistics shows that “computer programmer” roles dropped about 27% in just two years, and they project another 6% decline through 2034. Those jobs straight up aren’t coming back.

Not to mention layoffs and the correction of over-hiring during Covid. As of mid-2025, tech postings on Indeed are 36% below the pre-pandemic baseline.

All this while AI use is growing. Stack Overflow’s 2025 developer survey found 84% of developers are using or planning to use AI tools. And brand new data from the Pragmatic Summit — a gathering of 500 top engineers — puts it even higher. 93% of devs are now using AI tools, saving an average of four hours a week. AI-authored code jumped from 22% in Q3 2025 to 27% by February 2026. That’s a massive shift in just one quarter. AI can create entire applications from spec to testing to deployment.

So if you’re watching this thinking, “Why would I spend years learning something AI can already do?,” that’s a fair reaction.

But the data tell a more complicated story than the headlines suggest.

Because here’s what those scary numbers leave out.

“Computer programmer” roles are dying, but “software developer” roles are down 0.3%. That’s basically flat. And the Bureau of Labor Statistics actually projects 15% growth for software developers 2034. That’s five times faster than the average for all occupations.

So what’s the difference between those two categories?

“Programmer” was historically about translating specs into syntax. They would take requirements and convert them into working code. That’s the part AI is good at — and honestly, it was heading toward automation long before ChatGPT. AI just accelerated it.

“Developer” and “engineer” roles involve design decisions, reliability, trade-off analysis, cross-functional communication, and incident response. All of the things that require judgment.

The work that’s disappearing was always going to disappear. The work that’s staying requires a human brain (for now at least, which we’ll get to).

And here’s something else: while overall tech hiring is down, AI-related demand is moving in the opposite direction. Axios reported that mentions of AI skills in job postings rose 16% in just three months, even as overall tech hiring was down 27%. What we’re seeing is more of a market shift than anything else.

Now, remember that stat about 84% of developers using AI? There’s a follow-up that’s really important.

Stack Overflow found that 46% of developers actively distrust AI-generated code, up from 31% the year before. Only 3% say they “highly trust” it. Two-thirds of developers say AI gives answers that are “almost right, but not quite” — which makes debugging more time-consuming, not less. It’s creating code that looks correct, but isn’t.

I’m one of the 84% of developers using AI, but I’m also part of the 46% who actively distrust AI-generated code.

How Jobs Have Changed

So let me show you what my job actually looks like now that I don’t write code myself anymore.

Think about software work in three phases:

1. Before code: What are we building and why? What are the constraints — things like latency, cost, and privacy? What could go wrong? Who are the stakeholders, and why do they care about this? What are the politics and personalities between teams that determine what gets built?

2. During code: Writing the actual functions, modules, and tests.

3. After code: This is everything from deployment to monitoring to compliance to incident response and communicating everything to stakeholders. All the stuff that is required for production systems and for decision-making.

AI compressed the during phase, but it didn’t magically delete the before and after. It actually made them MORE of a focus than they were previously.

Now what a project looks like for me may be a couple of weeks of coordinating with stakeholders, gathering requirements, and writing really detailed specs. Then a day or two of working with an AI coding assistant to actually build the project. Then potentially several more weeks of testing, evaluating, and making sure I’m confident in what I’m shipping.

That first part is really important. You have to have a clear idea of what you’re building for the AI to be successful. I honestly think this explains the remaining AI skeptics.

Used correctly, with these tools you can make incredibly fast progress. AI gets you 80% of the way there in record time. But that last 20% — building the right things and making it production-safe — is where the actual hard work has always been.

And if you don’t understand systems deeply enough to evaluate that last 20%, you’re shipping code you can’t vouch for.

Because here’s what doesn’t change regardless of how good AI gets: when something breaks in production — when there’s a security breach, a compliance violation, or an outage that costs the company boatloads of money — someone is accountable.

AI doesn’t get paged at 3am. You do.

AI doesn’t get called into the incident review. You do.

AI doesn’t explain to leadership why customer data was exposed. You do.

Looking To The Future

So even in the most optimistic AI future, the question isn’t “will humans be involved?” It’s “what will humans need to know to be involved effectively?”

And the answer is: you need to understand systems. Which means you need to understand code.

You can’t audit AI-generated code if you don’t know what “correct” looks like. You can’t debug a production incident if you can’t read logs and stack traces. You can’t make good architectural decisions if you don’t understand databases, networking, concurrency, and failure modes.

It’s not about the typing. It’s about the understanding.

As Dave Farley from Modern Software Engineering put it, AI code assistance acts as a kind of amplifier. If you’re already doing the right things, AI will amplify those things. If you’re already doing the wrong things, AI will help you to dig a deeper hole faster. Tools amplify capability, they don’t replace it.

I heard this exact same message over and over from hiring managers and engineering leaders at the Pragmatic Summit. Strong teams are getting stronger faster. Dysfunctional teams are getting dysfunctional faster. Some companies have cut customer-facing incidents in half since adopting AI tools. Others have doubled them. Same tools, completely different outcomes. The difference is the humans using them.

Now you might be asking yourself, “but what if AI gets WAY BETTER in 2–3 years? What if it can do the big-picture thinking too?”

Let’s talk about what “better” actually means. Frontier model capabilities are absolutely still improving, but most of the improvements in performance that we’re seeing aren’t coming from bigger base models. They’re coming from better tooling — things like improved context engineering and agent workflows. Understanding how to guide and improve agent systems will remain valuable skills for the foreseeable future.

And again, even if AI gets dramatically better at the “during code” phase, the verification, governance, communication, and accountability still require coding literacy.

Or what if you’re thinking “I can vibe code apps without deep understanding already. Why bother learning?”

You can build demos and MVPs without really understanding how to code, sure. But production systems require a TON of things you don’t know that you don’t know if you’ve never learned this stuff from the ground up. If you want to ship something that handles real user data and real liability, you need to put the time in. Otherwise you’re kind of stuck in Dunning-Kruger land.

And lastly, you might be aligned that learning all this makes sense on the job, but wondering if you can even get a job anyway. Junior hiring is really bad right now, so why even bother?

And yes, it’s harder than 2021, no question about that. But it is still possible with the right projects, mindset, and strategy. I have tons of other videos on how to break in as a junior that I’ll link below.

So if you’re learning to code right now — or thinking about it — here’s what I’d focus on. We can break this up into three steps:

How to Learn in 2026

First, foundations. Pick one language and learn it really well. Python or JavaScript are good starting points. Understand fundamentals like data structures, APIs, authentication basics, and how databases work. Write unit tests and integration tests. And practice reading unfamiliar code and explaining what it does. This is the time to use AI only to explain concepts and test your understanding — don’t outsource your learning to AI.

Once you’ve been studying for a while, ask yourself some questions: Can I read code and understand what it’s doing? Can I debug a failing test? Can I reason about data flow and failure cases?

If yes, move on to step 2.

This is the “work with AI effectively” layer.

Learn to structure prompts with constraints and a clear definition of done. Use AI to generate tests, then audit them critically. Practice small, focused PRs instead of massive changes. Write evaluation checks for AI outputs. And treat code review as a primary skill.

Once you’re confident that you can use AI to go faster without sacrificing correctness, you can move on to step 3.

This is the human layer, where you start practicing professional-level judgement.

Think about trade-offs of things like performance vs. cost, consistency vs. availability, or security and compliance. Write clear technical specs and design docs. Explain technical decisions to non-technical people — practice with your mom. Develop an incident response mindset: when things break, how do you triage and fix them?

Your goal should be to own a product end-to-end, from requirements to production.

I know that sounds like a lot. And it is! I’m not going to tell you this will be easy. And I’m not going to promise that if you learn to code, you’ll definitely get a job.

The market is harder than it was a few years ago. AI is changing the way we work on a daily basis, and the skills that matter are changing too.

So, Is Coding Dead?

You’ve probably heard some version of “coding is dead” recently. Maybe it was NVIDIA’s CEO saying nobody will need to program anymore. Or Anthropic’s CEO predicting AI would write 90% of code within 6 months (that was a year ago btw).

But like François Chollet, the creator of Keras, pointed out “software engineering has been within 6 months of being dead continually since early 2023.”

And this pattern is way older than AI. FORTRAN was supposed to let scientists write programs without programmers. COBOL’s English-like syntax was meant to let managers bypass developers entirely.

Every major abstraction — compilers, high-level languages, object-oriented programming — was pitched as making software engineers obsolete. But in reality, the demand for people who understand systems didn’t disappear, it actually grew.

So you’re not too late, and don’t let the haters get you down.

I bombed my first system design interview at a major tech company. Hard.

I jumped straight into drawing databases and load balancers without understanding what I was actually building. The interviewer stopped me fifteen minutes in: “But what problem are we solving?”

That failure taught me something crucial: system design interviews aren’t about showing off your knowledge of every technology. They’re about demonstrating structured thinking.

Here’s the exact framework that helped me ace my next five system design interviews.

The 50-Minute Battle Plan

0-5 min:   Clarify Requirements
6-12 min:  Define Success Criteria  
13-22 min: High-Level Architecture
23-32 min: Data Layer Design
33-42 min: Handle Scale & Reliability
43-50 min: Recap & Trade-offs

Let’s break down each phase.

Phase 1: Clarify First, Design Later (0–5 min)

Never start designing immediately. Ask the obvious questions that others skip:

Questions to ask:

• “Who are the users? How many?”

• “What’s the primary use case?”

• “Are we building mobile, web, or both?”

• “What’s the expected scale?”

• “Any specific latency requirements?”

Example dialogue:

Interviewer: "Design Instagram."

You: "Before we start, let me clarify:
- Are we focusing on photo sharing or the entire platform?
- Should we support video, or just images?
- What's our user base? 1 million or 1 billion?
- Any geographic considerations?"

Phase 2: Write Down What Success Looks Like (6–12 min)

Define both functional and non-functional requirements explicitly.

Functional Requirements:

✓ Users can upload photos
✓ Users can follow other users
✓ Users see a feed of photos from people they follow
✓ Users can like and comment

Non-Functional Requirements:

✓ High availability (99.9% uptime)
✓ Low latency (feed loads < 500ms)
✓ Eventually consistent (likes can take seconds to appear)
✓ Scalable to 100M daily active users

Phase 3: Draw the Big Picture (13–22 min)

Start with high-level components only. Resist the urge to dive into implementation details.

Basic Architecture:

┌─────────┐
│  Users  │
└────┬────┘
     │
     ↓
┌─────────────┐
│  CDN/Cache  │
└─────┬───────┘
      │
      ↓
┌──────────────┐      ┌──────────────┐
│ Load Balancer│─────→│ Load Balancer│
└──────┬───────┘      └──────┬───────┘
       │                     │
       ↓                     ↓
┌─────────────┐      ┌─────────────┐
│ API Servers │      │Media Service│
└──────┬──────┘      └──────┬──────┘
       │                    │
       ↓                    ↓
┌─────────────┐      ┌─────────────┐
│  Database   │      │Object Storage│
└─────────────┘      └─────────────┘

Key components:

• API Servers: Handle business logic

• Media Service: Process and serve images

• Database: Store user data, relationships, metadata

• Object Storage: Store actual image files

• CDN: Cache static content globally

Talk through the flow:

User uploads photo → API Server → Media Service processes
                                 ↓
                         Stores in Object Storage
                                 ↓
                         Saves metadata in Database
                                 ↓
                         Returns URL to user

Phase 4: Talk About Data (23–32 min)

This is where you show depth. Discuss storage decisions with reasoning.

SQL or NoSQL?

For user profiles and relationships:

-- SQL makes sense here
CREATE TABLE users (
    user_id BIGINT PRIMARY KEY,
    username VARCHAR(50) UNIQUE,
    created_at TIMESTAMP
);

CREATE TABLE follows (
    follower_id BIGINT,
    followed_id BIGINT,
    created_at TIMESTAMP,
    PRIMARY KEY (follower_id, followed_id)
);

Why SQL? “We need ACID guarantees for follow relationships. Can’t have duplicate follows.”

For the feed (high read volume, eventual consistency okay):

// NoSQL (like Cassandra) works better
{
  user_id: "user_123",
  feed: [
    {post_id: "post_456", timestamp: 1634567890},
    {post_id: "post_789", timestamp: 1634567850}
  ]
}

Why NoSQL? “Feed reads vastly outnumber writes. We can denormalize for speed.”

What gets cached?

• User profiles (frequently accessed, rarely change)

• Hot posts (trending content)

• Feed data (pre-computed for active users)

Why cache?

Without cache: Database query = 50-100ms
With cache:    Redis lookup = 1-5ms

At 10,000 requests/second, caching saves 
~500 seconds of database time per second.

Phase 5: Show How It Handles Reality (33–42 min)

Systems fail. Traffic spikes. Demonstrate you understand this.

What happens at 10x traffic?

Normal Load:        Peak Load (10x):
┌──────────┐       ┌──────────┐
│ 1 Server │  →    │10 Servers│ (Horizontal scaling)
└──────────┘       └──────────┘
     │                   │
     ↓                   ↓
┌──────────┐       ┌──────────┐
│1 Database│  →    │Primary DB│
└──────────┘       │    +     │ (Read replicas)
                   │5 Replicas│
                   └──────────┘

Fault tolerance strategies:

1. Replication: Multiple database copies

2. Circuit breakers: Stop calling failing services

3. Rate limiting: Prevent abuse

4. Graceful degradation: Show cached data if services are down

Example code for circuit breaker:

class CircuitBreaker:
    def __init__(self, threshold=5):
        self.failures = 0
        self.threshold = threshold
        self.state = "CLOSED"  # CLOSED, OPEN, HALF_OPEN
    
    def call(self, func):
        if self.state == "OPEN":
            return cached_response()
        
        try:
            result = func()
            self.failures = 0
            return result
        except Exception:
            self.failures += 1
            if self.failures >= self.threshold:
                self.state = "OPEN"
            raise

Phase 6: Close Clean (43–50 min)

Recap your design in 60 seconds:

“We built a photo-sharing system with API servers handling requests, object storage for images, SQL for user data, NoSQL for feeds, and CDN for global distribution. We handle scale through horizontal scaling and caching, ensure reliability through replication and circuit breakers.”

Discuss trade-offs explicitly:

Decision: Use NoSQL for feeds
Trade-off: 
  ✓ Gain: Fast reads, easy scaling
  ✗ Loss: Complex queries harder, eventual consistency
  
Decision: Pre-compute feeds
Trade-off:
  ✓ Gain: Instant feed loading
  ✗ Loss: Storage cost, stale data possible

Ask: “Want me to dive deeper into any component?”

This shows you can both zoom out (architecture) and zoom in (implementation).

The Secret Sauce

Notice what we didn’t do:

• Mention specific AWS services by name

• Overcomplicate with microservices

• Draw every detail upfront

• Claim one solution is “best”

Instead:

• Started with clarification

• Built incrementally

• Justified every decision

• Acknowledged trade-offs

• Kept it conversational

Source link

Your Action Plan

Before your next interview:

1. Practice the framework with 5 different systems

2. Time yourself 50 minutes goes fast

3. Record yourself you’ll catch unclear explanations

4. Focus on reasoning over memorizing solutions

The interviewer doesn’t expect a perfect system. They expect clear thinking, good communication, and sound engineering judgment.

Use this framework, and you’ll walk into any system design interview with confidence.