NeetCode on Why Learning Hard Things Still Matters When AI Writes the Code
The Pragmatic Engineer
Navdeep Singh, known to many as NeetCode, built one of the most widely used coding-interview preparation platforms. He worked briefly at Amazon and then at Google before going full-time on his own business. In this conversation on The Pragmatic Engineer, the central question is a paradox: most engineers now prompt rather than type code at work, yet data structures and algorithms (DSA) interviews have barely changed. Singh's position throughout is that the value of that kind of preparation, and of learning difficult things in general, was never mainly the algorithms. It lies in the thinking, communication, trade-off reasoning, and effort the work builds. He argues that these are becoming more important as AI makes everything else cheap.
Why coding interviews have not died
The host opens by noting how many people predicted that coding interviews would disappear once AI could write code, and that they haven't. Singh finds this funny too. Coding itself has changed dramatically over the last few years, and especially the last few months, yet the DSA format has been "really really sticky." Some companies are experimenting with AI-assisted coding interviews, but the core format persists. That confuses people, himself included. In his description, you can now ask an AI almost anything about a codebase or have it implement a feature, and it gets perhaps 90% of the way there.
He gives two reasons for the stickiness. First, DSA interviews were never a good test of whether the skill translates to the job. They were a way to check whether someone can think. Second, he believes companies simply don't know how to evaluate candidates and probably never did. He cites a conversation with a friend at Amazon named Steve, who said Amazon had run studies showing that, however much data you have and however you run the process, it is very hard to predict how someone will perform. Even a skilled hire might not be motivated or might not fit the team.
The host suggests an "if it ain't broke, don't fix it" mentality may also be at work, and Singh agrees. Any change risks making things worse, and changing the process at a large company is bureaucratic and requires retraining. He points to Meta's attempts at AI coding interviews. Getting training right is hard because most interviewers dislike interviewing. Large companies want a standardized process for thousands of interviewers, and adding variables such as new evaluation criteria and AI prompts makes that "practically impossible" to measure. He expects companies to try new formats, but thinks the transition will be slower than most people predict.
From electrical engineering to a love of programming
Singh originally studied electrical engineering because he loved math and physics. His first programming course, an intro to C, was a requirement he didn't want to take, and he struggled at first. He remembers fighting with printf format specifiers while classmates seemed to pick them up quickly. Although programming seemed related to math, it was a different way of thinking.
After a couple of months of variables, conditions, loops, and functions, something clicked. What first felt boring revealed "infinite complexity": simple primitives compose into software that solves enormous problems. His example is Google Spanner, which draws on physics, atomic clocks, and GPS as well as programming. He fell in love with it.
That enthusiasm met reality once he started working professionally. Programming in industry is a business, so you don't get to choose the languages you like or the problems you enjoy. That took some of the fun out of it for him, and he describes a "love-hate relationship" with programming that he thinks many people share.
The CAP theorem and the urge to go deep
The host brings up Singh's dislike of the CAP theorem. Singh explains it as the familiar "pick two of three" framing across consistency, availability, and partition tolerance in a distributed system. He calls that framing not very accurate and the theorem itself incomplete. What he loves about programming is its determinism: if you want to, you can trace behavior down to the exact line, the assembly, the ones and zeros. The CAP theorem felt hand-wavy by comparison.
He felt validated when he found a blog post by Martin Kleppmann criticizing CAP. He notes that the post was somewhat controversial, with commenters arguing Kleppmann was technically right but nitpicky. Singh prefers PACELC: during a partition you choose between availability and consistency, and otherwise you still trade off latency against consistency. He finds it more complete and, if anything, simpler, and doesn't understand why anyone would learn CAP instead.
The host wonders whether only a small subset of engineers actually go that deep, while most accept "two out of three" and move on. Singh ties this back to the tension of professional work. During onboarding at Google, with its enormous internal documentation, he wanted to do a depth-first search through every linked document. Jobs don't work that way, and no one understands a massive codebase in full. He sees a similar transition now with agentic coding, where engineers may not even read the code they ship. You lose some of what you enjoyed, he says, but that's business.
Quitting Amazon after two months
Singh corrects the host: he attended Washington State University, not the University of Washington, which rejected him because he wasn't a strong high school student. He ground hard on interview preparation, kept a good GPA, and landed at Amazon, where the DSA-heavy interviews suited him.
He was self-aware that he wasn't well-rounded. He was comfortable reading documentation alone but found working with people very difficult. He joined a team in Alexa, an org he says has reportedly been gutted in the LLM era. He describes it as a stressful environment with lots of manual work, "not a well-oiled machine." While reading the team chat history from the week before he joined, he found a message saying the job felt "thankless."
About five or six new grads joined within one or two weeks, more than doubling a team of about four experienced engineers. Because the team faced deadlines, the new hires were largely left on their own. At the introduction meeting the experienced engineers said almost nothing, and the manager had to keep prompting them. He saw every experienced engineer committing code at 3 a.m. before an 8 or 9 a.m. meeting, with others reviewing PRs at the same hour. He doesn't think a manager ordered this. He read it as an implicit culture: if you're the one not working at 3 a.m., you may be first in line to be pushed out.
The host adds context about Amazon's target of 6% "unregretted attrition" at the time, which made some orgs cutthroat. Singh says he submitted his resignation three times before it was accepted, and half-jokingly speculates this was because it would count as regretted attrition. At two months he was too early to be put on a performance improvement plan. He stresses that he holds no grudges against individuals or Amazon. It was a bad situation, he had personal issues at the time, and he made an impulsive decision. He believes that if he did it over he could probably have survived, though it would have been stressful either way. He felt relief at first and then much worse, not knowing what to do next.
Google: the opposite experience
Singh later joined Google Cloud and describes it as the opposite experience. He arrived in "Amazon PTSD mode," assuming that professional life meant not asking questions, not being friendly, and working as intensely as possible. People were friendly, so he reciprocated, but he was still afraid to ask questions and mostly worked alone.
His manager gave him a project that turned out harder than expected. Believing he had to finish it independently, he did almost all the work himself. The manager and team read this as independence, which is what promotion from junior to mid-level requires, and he was promoted in almost exactly a year, which he says is uncommon at Google. Only after the promotion did he feel comfortable asking questions, which he finds ironic since that is expected more of juniors.
The host observes that engineers carry reflexes from earlier companies that can make adapting hard. Singh adds that much of Google Cloud's leadership came from elsewhere, including Amazon. A VP or GM who came from Amazon left after a few months, though Singh doesn't know the details. Googlers worried Amazon managers would bring Amazon's frugality. Over his time there, he says, Google moved somewhat in that direction, especially with the layoffs.
On promotions, Singh plays down any suggestion of genius. You need to put in the work and be reasonably smart, which he thinks most people are. Beyond that it comes down to the right team and the right project, because a 10x engineer on easy work can't show they solved hard problems. He describes Google's culture of supporting everything with metrics or artifacts, such as design docs, which produces too many docs for simple things. He calls it a necessary evil, since otherwise engineers might work on things with no business impact.
How NeetCode started
Singh began making videos after quitting Amazon, about six years before this conversation, purely "for the love of the game." He was studying anyway and wanted to help others. There were few tutorials then, mostly forum posts with complex solutions he struggled to understand. He believes most people only grasped those solutions at a high level without knowing why they worked, which was often enough to pass an interview. He went much deeper, spending hours on videos that 50 people would watch, because he enjoyed it. He calls this deep-thinking tendency more of a personality trait.
About a year after he started posting consistently, he got into Google. He found the interview fairly easy by then, backed off the videos, and posted that he had joined Google and wouldn't be around as much. After that the channel "went exponential." He thinks the announcement added credibility: he had made the videos before getting in, so it was proof that the method worked, "the best sales pitch in the world." It bothers him somewhat that the videos didn't change, only the framing. He then built a free website that cataloged the videos, and that went viral too.
Leaving Google to go all in
Shortly after his promotion to L4, Singh considered going full-time. At Google he couldn't go as deep as he wanted, whereas with algorithms and data structures he could go deeper than most people would ever want to, and he had a reason to because he was explaining them to others. He genuinely liked Google, its people, and its relatively low-stress environment. His tech lead, effectively his manager at the time, said he was perplexed that Singh would leave after such a fast promotion when another seemed likely.
Singh had assumed he would spend his whole career at Google working his way up. But he felt the chance to try something on his own might not last. Google's policy of generally letting people in good standing return within about a year made the decision easier. Friends still ask him whether they should leave Google; one asked just the week before because she wanted to do content creation full-time. He observes this seems almost like a trend.
The switch was hard in unexpected ways. He had struggled with Google's internal tools at first, then missed them after leaving. He isn't a big fan of GitHub, citing UX issues rather than the uptime complaints others raise, and notes that companies like Cockroach Labs were founded by people recreating Google-internal systems for the public.
The bigger challenge was people. He only got comfortable delegating and managing within roughly the last six months. That came after hiring people, letting some go, and learning what fits and how to motivate different individuals. People aren't like agents that take a task and produce code, he says. He used to hate this work and now loves it. When a hire works out and he can guide their growth, he finally understands what leadership means and can imagine how much it matters at larger scale, as when a new CEO sends a company up or down.
The tech stack and taking shortcuts deliberately
While still at Google he built the free site with tools he knew: Firebase on Google Cloud and Angular. He regrets both. He mentions that he now meets people and thinks he might move to Convex. With LLMs, though, migration has become "relatively trivial," so he may switch eventually. Building the application never interested him much because there were few deep problems in it. What mattered was the education: if an explanation is bad, no one cares how the site looks or performs. By his account, he was bad at building, but the value of the content outweighed his poor tech choices. That taught him to prioritize what matters and take shortcuts elsewhere. He cites Elon Musk's multi-step process for optimizing a workflow, which involves cutting aggressively and adding back what turns out to be necessary. Working mostly alone, he probably should have hired sooner, but he took many shortcuts and still does.
The memory leak he chooses not to fix
His example, which he expects people to get mad about, involves a code-execution service he was paying about $3,000 a month for. When "vibe coding" took off, he figured he could write his own version, perhaps in a couple of weeks with AI, instead of the month or two he had estimated before. He finished it in two or three days, and says it did require coding skill; a non-programmer could not have done it. It now costs about $200 a month.
The service has a bug, probably a memory leak, that crashes one or two instances every couple of days. He estimates that finding it would take longer than the three days it took to build the service, since this is the point where vibe coding forces you into the details. Instead he runs about four instances, so a crash is replaced within a couple of minutes. Before switching over he routed only a small amount of traffic to it for a couple of weeks and, despite expecting problems, saw essentially none. He says he has had practically zero outages and fewer than LeetCode, with only a couple of people running things. Because the service runs on better hardware, it is also faster, and no user has complained.
The host pushes back: isn't this typical of AI-assisted development, where founders replace a SaaS product with something subpar, get by, and then find it too hard or uneconomical to fix code they didn't fully write? Singh says he has thought about it a lot. Fixing the leak would let him shrink the server pool and save perhaps another hundred dollars. The engineer in him hates leaving it, and he admits it still bothers him. But he has learned to prioritize business value, short and long term, over perfection. The host sums it up: the overall package is cheaper, faster, and replicated, so it is better than before despite the regression.
What interview prep actually teaches
The host asks what DSA preparation gives people beyond the algorithms. Singh points to his own path. In the year between Amazon and Google, he mostly made NeetCode videos rather than doing development. That work trained him in speaking, communicating, thinking deeply about a problem, and weighing trade-offs between approaches. At Google he believes his raw coding experience was below most of his peers', yet he got promoted. Faced with a hard problem and unfamiliar internal tools, he could sit down, make a plan, and communicate it to his manager much as in an interview: here's the approach I'm thinking of, so we're on the same page; give feedback if you have time.
He sees trade-offs as the essence of engineering. Unlike math or science, engineering has no single correct answer, only the best solution for the moment, as with his memory leak. He worries people now focus too narrowly on hard skills, like whether they can write a particular loop or know a particular data structure, and miss what engineering is about. Strong engineers who move successfully between domains usually don't stand out for mastering one language. They stand out for what they gained from learning hard things, much as years of education shape a person in ways that are hard to pin down.
Systems thinking versus domain expertise
Singh recounts a conversation with Chip, a previous guest of the show. She said it is impossible to know which hard skills will matter with AI, such as which language to learn, how high-level to go, or whether coding will be necessary. What she was confident about was systems thinking. Singh illustrates with a construction site. Individual workers do small tasks, but someone designed the system of rules, procedures, and verification that makes a complex building possible. Most people are the "worker bees," while the value comes from whoever architects the system. He says there's no course for this, and that it takes many experiences to get there.
The host challenges this: systems don't exist in a vacuum. Agriculture, law, and healthcare look very different by country, and great systems thinkers are often simply deep domain experts. Payments, where the host worked, is one example. Perhaps abstract systems thinking and domain expertise overlap, and knowing several domains improves the abstract skill. Singh agrees domain knowledge matters and admits his idea is hard to articulate. Still, he points to engineers you'd trust to move from payments to real estate. They face a learning curve but learn faster and perform better. He doesn't think this is innate. He calls it a mistake to dismiss any subject as wasted time because you didn't use its details on the job. He sees people making the same mistake now when they ask why they should learn loops they may not write in a few years. Going deep, especially when it's hard, is not a waste of time, he says.
The hiring bar and alternatives that work at small scale
From user feedback, Singh sees early-level interviews at big companies still dominated by DSA. People anecdotally say interviews are getting harder. But judging from those who pass, he thinks difficulty at companies like Google isn't very different from before, at least in the US. India is very different, he says, with nearly all algorithms and LeetCode hards and "super hards." Because of cheating tools during five or six years of mostly remote interviews, Google has "pretty much" returned to on-site, whiteboard-style interviews. Candidates can use a laptop, but someone watches them code in person.
Asked what he'd do without DSA interviews, he says any standardized, scalable process can be gamed. The best signal is seeing someone actually work, as with an intern. He says many small companies he has spoken to recently use trial periods ranging from a few days to a couple of months, though others say this doesn't work for candidates who already have jobs. He has moved that way himself. He can gauge LeetCode ability quickly, so he doesn't spend four rounds on it. He gives candidates work similar to the real job, or just talks with them, and focuses on why they give an answer rather than what it is. He wants to know whether they are regurgitating something from ChatGPT or can reason through trade-offs, and what's good, bad, or improvable about their work. He doesn't expect big tech to adopt this because it's hard to scale.
The host notes that open-source companies rarely struggle to hire because they recruit their contributors. Singh adds that Dax, of OpenCode, hired people he already knew from contributions or their own open-source projects, sometimes with just a DM. Working in public lets others see how you work.
AI at NeetCode and why value got harder to build
Over the last six months, Singh says, most of NeetCode's code has been written by AI. He was a "really big AI hater" for a long time and is sometimes accused of becoming an "AI shill." His view is that he's being pragmatic: the tools used to be worse, and his work is mostly CRUD apart from the code-execution service. The stack is Angular, Firebase, Google Cloud, and TypeScript, which he describes as somewhat outdated.
In the early years his code quality was "very very bad." He used TypeScript riddled with any, inline CSS, and other shortcuts, knowing he understood the whole codebase and could move faster. He now considers that trade-off fully vindicated, because AI has cleaned much of it up, and he could probably migrate stacks quickly if he wanted. His broader point is that you may make the wrong decision, but you can go back and correct it.
The host quotes one of Singh's posts: in 2026 it has never been easier to build things, but it's ten times harder to build value. Singh explains that features once not worth building are now trivial to add, so products can accumulate a new feature every day that nobody wants. That clutters the product, confuses users, and can slow performance. Speed matters, but so do decisions. Teams shipping too fast don't measure impact and let things regress. He cites Anthropic as an example of recent regressions. He says he saw Boris replying to users that they hadn't noticed a problem, before the company recently published a blog post acknowledging it.
The host reflects that the old trade-off between moving fast and breaking things doesn't appear to have been abolished by AI. Singh adds OpenAI shutting down Sora and refocusing on a smaller set of things, including coding, as he sees it following Anthropic's more focused approach. The host notes the apparent lesson that focus beats fast execution across many things. Singh jokes that the Transformer paper was titled "Attention Is All You Need."
The disappointing redesign contest
Singh offered $2,500 for the best NeetCode redesign. He hadn't finished evaluating the results, but so far he was disappointed. Nearly all submissions were obviously made with AI, which he says is fine. The problem is that when he asks designers why they moved, removed, or added elements, they can't answer or give vague answers. After five minutes with their design, he can articulate its choices better than they can. He doesn't think this is about intelligence. He attributes it to effort, caring, and perhaps design skill. Entrants focus on how pretty the design looks, while he wants a design that explains what the site is about and its value, which he considers the real point of UX.
The host points out that the contest structure flips incentives. If only the winner gets paid, the rational effort is a fraction of the prize, which encourages low-effort AI entries. Singh agrees that in hindsight he should have paid a small pool of designers up front and chosen among them. He adds that someone could sketch the key decisions on pen and paper and hand them to an AI. On his own site, even for AI-built parts, he can explain why each element is placed where it is, for example making the most-used features prominent based on metrics. He had also told entrants his criteria, which some didn't follow.
The future of software engineers
Revisiting a Tim O'Reilly article from about a year earlier on "the end of programming as we know it," Singh finds it surprising how little has changed in business terms despite how much coding has changed. His big-tech friends code completely differently, but most still have jobs and are doing more work than before. He thinks some companies went too far toward AI and are rebalancing. He expects programming may become a completely different field. But he doesn't think knowing what value to produce or making engineering trade-offs will go away, because weighing what matters is, in his view, a very human thing.
The host adds that even a simple "report a bug" button hides edge cases, state, user tiers, and business context. That knowledge used to live in code and in the programmer's head, and someone still has to hold it when prompting. Singh says change itself is the constant. He mentions reports that Microsoft is offering voluntary buyouts. A friend confirmed the buyouts but not the reported criterion that they target people of a certain age with 10 to 15 years at the company. Singh speculates that Microsoft may see those people as less willing to change, and compares it to the 2014 layoffs after Satya Nadella took over, which the host notes were not voluntary. His takeaway is that willingness to change will matter, even when it means doing things in ways you don't enjoy.
He doesn't foresee the extinction of programmers: "my guess is as good as anybody else's," but thinking and problem solving won't disappear. Fewer programmers may be needed, yet cloud computing and higher-level languages didn't reduce demand, which surprised him. He wonders whether tools like Replit and Lovable will make everyone a programmer. The host raises DHH and 37signals leaving AWS to save money, suggesting that at scale it may always pay to build lower in the stack. Singh adds that engineering isn't a science and culture drives adoption. He suggests MongoDB's growth was probably due more to sales, marketing, and snowballing adoption than to the technology. He also thinks cloud services have become very complicated, and that AI's cost could become a big issue once subsidies run out. That might lead companies that embraced AI programming to cut back.
AGI, skill erosion, and agency
On AGI, Singh offers a philosophical take. Chasing it feels like approaching infinity, where you stay the same distance away however close you get. Technology has brought us near abundance, yet human nature keeps people competing at ever-higher levels, and new problems appear in marketing, edge cases, and elsewhere. If AI really replaced every job, he argues, that would in some sense be good, as the decline of farm labor was a net positive. The danger is that people's livelihoods depend on those jobs, which he frames as a political problem more than a technological one. The host says he's still waiting for software that lets a normal person file simple taxes or find a plumber, with little progress in 15 years. Singh says we shouldn't assume progress is preordained. Civilizations have peaked and lost technology before, and policy decisions will shape what actually improves people's lives.
On skill erosion, Singh says many students now "learn" everything through LLMs, which is often just cheating, and experienced programmers are affected too. A friend preparing for interviews hadn't handwritten much code in months and struggled to get back into it. The host speculates that this may push more companies toward in-person interviews, where you can tell who freezes without AI. Singh admits he might freeze himself. He was always a copy-and-paste programmer, weak from scratch but good once he could see a file's imports and structure. His own hot take is that companies may stop caring whether you can handwrite code, as long as you understand it. In some AI-assisted assessments, you can implement everything with AI, but you must explain things like what the integers in an array represent in context. He admits he has no firm answer.
On his claim that personality traits now matter more than coding skills, he concedes "personality traits" may be the wrong phrase. He describes a hire from a few months earlier who hasn't yet finished a CS degree but is better than practically anyone he has hired, including experienced people and candidates with big-tech résumés. What sets them apart is what startups call agency. They never say "that's not my job," and when given a task in a completely new domain, they've learned everything about it within a week. Since information is now a prompt away, he says, what matters is knowing which questions to ask, and that comes from effort.
Authenticity, attention, and the personal brand
The host notes that AI startup founders can build faster than ever yet still struggle for product-market fit. In-person customer conversations, meetups, and a charismatic founder matter more than code. Singh draws a parallel from YouTube. Nobody cares how correct or clever you are if you can't explain it. In his videos he emphasized and repeated key points to make them digestible. Any LLM can produce a correct DFS or sliding-window solution, but understanding what people are looking for is the human part.
On capturing attention, he says packaging matters: how you present things and yourself. But authenticity matters most, because people "can smell the fakeness" and stop listening. He points to Codex team members at OpenAI engaging on Twitter, including with critics. The host suggests Claude Code's success is tied partly to Boris Cherny's visible, humble presence and bug-fixing in people's mentions, and that Codex now has a similar figure in Tibo. Singh dislikes the word "influencer" but thinks companies increasingly need to be approachable and relatable, like people. He mentions Meta's internal culture of promoting what you ship as a skill, and encourages engineers to put themselves out there, whether on YouTube, LinkedIn, or Twitter.
"Maybe some people should just give up"
Singh addresses his most controversial video. He stresses he doesn't encourage people to give up. His point was that if you don't want to try hard, do things yourself, or dig into details, you should know what you're getting into. Many people cheat through degrees and expect a job at the end. Many viewers were angry. But he says the majority, while wishing he'd been nicer, which he accepts, agreed with his points. Some wrote that they had leaned too heavily on prompting, gotten worse, produced worse work, enjoyed it less, and now wanted to refocus on learning. He recorded it on his laptop without expecting it to blow up, and he left it up despite a possible reputational hit.
How to stand out
Asked what makes an engineer stand out, Singh doesn't claim universal advice but returns to effort and knowing your audience. In interviews, watch how the interviewer reacts. On a team, learn what people care about, ask questions, meet with them, and avoid needless assumptions. Then go very hard in the direction you think is right, and expect to recalibrate. He describes this as an iterative feedback loop that requires constant course correction, which few people enjoy. One practice he always followed was asking managers to tell him any feedback, promising not to be offended. Managers were surprised and read it as a sign that he cared, and it meant they didn't have to guess what he was thinking.
He admits this is harder in practice than on paper. He hates change and takes years to adapt; the host teases that NeetCode still runs on Angular. He learned soft skills slowly and is still learning them, but credits them for his promotion and for his team liking him, adding that it's important to be likable.
For inspiration, he names Martin Fowler, whose book he loves because it goes deep and still ends each chapter with a hundred references for follow-up questions. He relates more to scientists and researchers than to engineers. He draws on YouTubers, technical people, and former colleagues, deliberately identifying qualities he admires and trying to imitate them.
In closing, the host highlights what stood out to him. Singh, who runs one of the largest coding-prep sites, hires for motivation, the ability to explain one's own reasoning, and above all agency. The LeetCode-style interview survives not because it predicts performance but because nothing better has been found that scales. And effort is becoming a differentiator precisely because AI has made everything else cheap. Anyone can prompt a design, a feature, or an answer, but no one can prompt caring, or the ability to explain their choices when asked, "Why did you do it this way?"
There's been so many predictions that coding interviews will be dead.
There's been cheating tools for interviews. Google has pretty much gone to on-sites at this point, back to the traditional whiteboard. Somebody's going to be watching you code, and you're probably not going to be able to cheat your way through that.
One of your hot takes is 2026. It's never been easier to build things, but I would say that it just makes 10 times harder to actually build value. You said that personality traits are now more important than coding skills.
I hired somebody a few months ago. They still haven't even graduated. Anytime I give this person a task, even if they have no idea how to start it, a week later, they'll have learned everything about it. That matters the most.
You've had a pretty contentious hot take, which was some people should just give up on tech careers.
You should know what you're getting yourself into because
What separates strong engineers from everyone else?
Navdeep Singh, or as many call him Neet, he created NeetCode, the coding preparation platform that helped countless devs get hired at Big Tech. In today's episode, we cover what preparing for data structures and algorithms interviews teaches you that's useful on the job, and how it's more about mindset than the algorithms. The growing difference between engineers who can still think without AI at their fingertips and those who freeze without it. Neet's contentious hot take that some people should just give up on tech careers, and many more. If you want to understand which engineering skills compound over a career and the ones that AI is quietly eroding, this episode is for you.
This episode is presented by Antithesis. Antithesis runs your whole system in a hostile simulation and finds every bug before your users do. It sounds like science fiction, but it's actually hardcore engineering. Understand how at antithesis.com/pragmatic.
This episode is brought to you by Sentry. Sentry is a tool I used for application monitoring back when I worked at Uber, and I now use it on all my projects, including the Pragmatic Engineer backend. One new feature I'm really liking about Sentry is their Seer AI agent, which helps investigate production errors. For example, here's an actual error I had in my application. I can just ask Seer what might be the root cause and it brings context and it can also make a plan to fix it all from the web interface. Oh, and it also works in Slack as well, not just the web. One place that I find even more handy to use Sentry is from Codex or Claude Code using Sentry MCP. After you hook up the MCP server, you can do some very useful things. For example, when an already resolved Sentry issue resurfaces, you can kick off an agent to investigate the regression, read the relevant code, and open a PR with a suggested fix. There's a little work involved to get all of this going: to connect Sentry to your code repository, add Sentry MCP to Cursor, define the instruction for Cursor's agent to investigate, configure the trigger that launches the automation, and test that it all works. But once you have it up and running, you can get regressions fixed faster while still reviewing every and all fixes. I'm not a fan of using AI tools just for the sake of it, but I really like the practical integrations where I can fix errors faster and with more context. Check out Sentry at sentry.io/pragmatic and start monitoring and fixing regressions today.
Neet, welcome to the podcast.
Yeah, I'm happy to be here.
It's awesome to have you here. Let's start with something that I've been thinking about. So, there's been so many predictions that if and when AI will be good enough to write code, you know, coding interviews will be dead because on the day-to-day we will not be writing code. Now, most engineers are not writing code, they're prompting at work and yet at the same companies coding interviews are still not dead. What is your take on this?
Yeah, I think it's really funny with how much coding has changed the last few years and especially the last few months that coding interviews are the one area that have surprisingly stayed pretty consistent. I know some people talk about them changing a lot and so far they're kind of changing a bit with AI-assisted coding interviews, companies are trying that. But surprisingly, the coding interview format of data structures and algorithms is really, really sticky and it's confusing to a lot of people, myself included, because we've gotten to a point where you can ask an AI bot any question about a code base. It can give you a pretty good answer. You can ask it to implement some feature. You can do anything pretty much. And it might not get 100% of the way there. Even humans can't write bug-free code, but it can get at least 90% of the way there. Pretty close. So, it's confusing to a lot of people. And I think that it goes back to how do you even evaluate if somebody's a good hire or not?
There's one aspect of it which is do they have the hard skills? Do they have the technical skills? Can they think? And DSA interviews were never the best for that. Well, thinking, sure. But in terms of does that skill translate to what you're doing on the job? It never really translated to that. It was more about evaluating does somebody think? So, I think that's one of the reasons. And the second reason that it's stayed sticky is that companies just have no idea how to evaluate. And they probably never did. I was talking to a friend of mine, Steve from Amazon. And he mentioned that they've run some studies. And it's very hard to know, when you hire somebody, no matter how much data you have, no matter how you've run the interview process, it's just very hard to know how somebody's actually going to perform on the job. So,
If they're going to work out, right?
It's a very hard problem. Because even if somebody is good, how do you know they're going to be motivated? How do you know they're going to enjoy the team environment, the vibe, and all that stuff? So, I think it's just really complicated.
And could another reason be that it has been so sticky and it's still sticky that maybe it's just as simple as it's kind of like an "if it ain't broken, don't fix it" type of mentality?
I think so because anytime you try to change something, you risk making it worse. And so, first of all, it's a lot of work to change that process at big companies. It's very bureaucratic. There's going to be a lot of retraining. And we're already kind of seeing that with companies like Meta trying to run AI coding interviews. The training is really hard to get down because interviewers are just not good. Most interviewers do not like interviewing. They hate it.
When you're saying training, you mean interviewer training, like training your interviewers at a large company, like a thousand of them, to be similar.
Exactly, yeah. Because at a big company, you want the process to be standardized. You want it to be the same for everybody. And that's very hard to get right in general. And it's even harder to get right when you have more variables introduced like a new evaluation process, training interviewers differently. Now you've got to check the AI prompts, all these variables. And so it's not an exact science. It's hard to measure these things. It's practically impossible. So I think we're definitely going to see companies trying different things. I think we probably will see different interview formats introduced. I just think it is going to be a slower transition than most people think.
I want to rewind a lot back into your early days. How did you get into tech? What was your first introduction to programming, coding?
Yeah, I was actually studying electrical engineering when I was in college. Because I really liked math. I really liked physics. I know a lot of programmers don't. Some of them obviously do, but a lot of programmers don't. But they really like programming. And so when I got into programming, I was just taking our intro to C class. It was required for electrical engineering. I didn't really want to take it. And I was not very good at it initially. I remember trying to learn printf and the, you know, percent S, percent C, like, I don't know why. I looked around. Everybody around me was learning it so quickly. And to me it was just a very different way of thinking. Even though it's kind of related to math, you'd think it'd be easy to pick up, but it really wasn't initially for me. But then I think a couple months went by and we learned about variables, conditions, loops, functions, and all these kinds of concepts. And then something just kind of clicked where initially programming felt kind of boring. You just have variables and numbers. But then when you introduce all these things, you realize there's this infinite complexity that can be introduced. And you see that with all the software that is built today, where you took these simple primitive things, these zeros and ones, and all of a sudden you just have this enormous universe of software solving insane problems. You have databases like Google Spanner, which not only take programming, but they take physics, they take atomic clocks and GPS systems and all these things, and they solve these really hard problems.
And so I guess to go back to my story, well, once I really started enjoying programming, I just fell in love with it and I was like, "Okay, I'm going to do this for the rest of my life. I'm going to love it." And then I went through a transition where once I got into the real world, I realized that programming is not something you can just kind of do the way you enjoy. It's a business at the end of the day, and so that in a lot of ways took some of the fun out of it for me, where you don't get to work on the languages that you like, the problems that you enjoy solving. You have to focus on the business problems. And so yeah, I have a love-hate relationship with programming because of that reason. And I think a lot of people do.
It's interesting how, you know, it was boring and then you got really excited about the complexity and the possibilities, and you kind of came back down to earth. One thing we were just talking about before we started the podcast is the CAP theorem, and how you also had a similarly weird relationship with it. Can we talk about it, and also for those of us listening who don't know exactly what the CAP theorem is, let's start with that.
Yeah, of course. So it's a pretty simple theorem. It's kind of described awkwardly sometimes, where you have three choices and you can pick two of three. There's consistency, and that's data consistency, so in a distributed system where you have data that's partitioned in different regions or something, it can go out of sync. One database might be more up-to-date than the other. And then there's availability: are both of these servers or databases available to read, or maybe one went down. And then the third one is partition, or partition tolerance. And so that basically means in a distributed system, if there's a partition, if maybe the system becomes disconnected, one thing goes down, how is it going to behave? And so the two out of three framing is used a lot. It's not super accurate. And the entire theorem is very incomplete.
And so when I was learning it for the first time, I thought, you know, I like to go deep into things. I like to really, really understand things. That's what I love about programming. It's deterministic. If you really want to, you can go down to the exact line of code, the line of assembly, the zeros and ones to know exactly what was happening. And so CAP theorem felt hand-wavy to me. And I didn't really like that. And that goes back to why I don't like certain things about working on the job, because you don't get to go as deep as you like. You have to solve the business problem even if it means you don't really understand some of the technical details. But that's fine. But later on, I felt so validated when I saw a blog post from Martin Kleppmann talking about how much he didn't like CAP theorem. And it was actually a little bit controversial where I think there were plenty of smart people in the comments of that blog post that said that, you know, maybe he's technically right, but maybe he's being a little bit nitpicky. And I think that's a personal preference, but I just felt very validated that somebody like him agreed with me. And I think it's kind of funny because I never saw anybody mention that about CAP theorem before. I saw posts on Stack Overflow. Nobody really mentioned it's kind of incomplete.
And so the thing that came after it is PACELC, which is if there's a partition, you can choose either availability or consistency, but if there's not, then there's still a trade-off to be made, which is latency and consistency. So it's much more complete. I don't understand why anybody would learn the CAP theorem when that theorem exists because it's just more complete. It's not that much more complicated. I think it's simpler to understand.
I wonder if it's only a smaller subset of people who actually go deep. You know, CAP theorem, you actually go, all right, let me understand the whole thing, and then you realize it's incomplete. But most people might have just looked at it, you know, took it: okay, it's the law, two out of three, simple enough, move on. And I guess in most parts of their lives, it's enough, or they might not even use it, or they think they know, but they don't know it exactly. So, it's interesting because we're talking about software engineers and you would think that most software engineers go into the details, but I guess maybe not.
Yeah, I think it goes to solving the business problems, and this is what I didn't like when I started working professionally because, okay, so you go through documentation, right? You're going through onboarding. At Google, there's so much documentation, there's so many internal tools. And I want to go deep. I want to do depth-first search on all the document links. You know, you have one blog or you have one site and it references five others. That one is going to reference five others. I want to go through every single one, have a complete understanding of everything. But that's just not how it works at jobs. Even a code base, no one person is going to understand this massive code base unless you write all of it by yourself, which is just not how companies work. And now we're kind of seeing a similar transition I think a lot of people are going through now with agentic coding because it's kind of a similar concept where now you might not even be looking at the code that you're actually producing yourself. So, it's kind of similar and I think this whole transition kind of reminds me of that, where you don't get to do some of the things that you used to enjoy, but it's still, you know, that's life, that's business.
So, you graduated from University of Washington and you started work at the most obvious choice in Seattle. I guess in Seattle the two obvious choices are Amazon or Microsoft, and you got into Amazon and it should have been a smooth ride. You made it into Big Tech, into the big leagues, and then you quit after 2 months. What happened there?
Yeah, first I want to say I actually went to Washington State University because, yeah, I was actually not accepted to University of Washington. I wanted to go there, but I was not the best student in high school. So, I was fortunate enough that I grinded super hard for
interviews, had a pretty good GPA. So, I got some interviews at Amazon, and it was DSA related, so I was able to, you know, crank that out. And then once I actually got into the world, and this is something I was self-aware about where I knew I was not a well-rounded person in that like working with people, people skills, and just anything of that. Like I could sit by myself, go through like documentation, work on things, but like working with other people was very, very like difficult for me.
At Amazon, the org I was in, Alexa, which is kind of been gutted from what I hear nowadays with LLMs, but the team I was specifically in, and I think Alexa the org in general, was not the best place. It was not a well-oiled machine, a lot of manual stuff going on. It was a really stressful environment. I think when I joined I saw a message on the internal thing. I think they used Chime at the time, but he said, "This feels like a thankless job." And I was going through the history of the team channel. This was like a week before I joined. I was like, "Whoa, okay. So, this is like clearly not like a positive team environment right now." I think they were all like decent people. I don't blame any of the individuals. I don't even hold a grudge against Amazon. It was just a crappy situation.
And so, I think in hindsight, like if I had to do it over again, I'd probably be able to survive. Like I kind of know things. It would have been stressful and crappy either way, but I would have been able to get through it. But at the time, I just didn't really know. And like I had a lot of like personal issues at the time. And so, for whatever reason, I just made a very like impulse decision to just leave the job. Afterwards, I kind of regretted it because like, you know, I felt a little bit of a relief, but then I just felt a lot worse because I was like, okay, now what do I do?
And then can you talk me through on like what it felt joining, you know, like the first impressions, what the onboarding was like, and what were the things that just were like not adding up?
It was very intense. So, we had a meeting cuz there were like five or six new grads who joined like within a one to two-week period.
For the same team?
Yeah, and I think there were like four experienced engineers already, and so like they over doubled the team and mostly new people. So, you'd think, okay, well, if you introduce a bunch of new people, you're going to obviously onboard them, like get them up to speed. But they had a lot of deadlines that they were dealing with, so it was kind of like the experienced people were just working, and the rest of us were kind of just like on our own.
And so we had a meeting where it was like one of those where you're just kind of like introducing the new people, right? And like again, I don't blame any of the people, but nobody said anything. The experienced people, like they did not like say anything. The manager had to like kind of keep like prompting them to like talk and to be friendly and stuff. I think they just wanted the meeting to end so they could go back and like finish their work because they had deadlines to meet.
I saw people, and I'm not saying one person, every one of the experienced engineers was committing at 3:00 a.m. and we have like an 8:00 a.m. or 9:00 a.m. meeting in the morning tomorrow. And some people are reviewing the PRs at the same time. So, I don't know if it's this culture where like I don't think the manager told them you have to do this. I think it's like implicit where it's like, you know, you kind of know that it's a stressful environment right now. If you're one person who's not doing it at 3:00 a.m., you're going to be the first in line to maybe get kicked out of the company.
Yeah, and also I mean, Amazon at the time, they had a target of 6% unregretted attrition every year, which meant that managers or like directors at their level had to have 6% of people leave the company and marked as unregretted, which meant that either people quit on their own and you said like, oh, actually this person was not great, unregretted, or you need to put people on performance improvement plans, and then have them leave and say like, yep, that was unregretted attrition. So, it's somewhat cutthroat in some of the orgs, or most of the orgs.
Yeah, I almost have like some conspiracy theories about that, because I think I gave my resignation actually three times before they finally like accepted it in a way, which was surprising to me. I was like, why don't they accept the resignation even after like the second time? And I was thinking like maybe this is because like it looks bad because it's regretted attrition, where it's like you didn't let them go, they chose to leave. And since it was so early, I think it was too early for me to even be on PIP. I think you get that like within 3 to 6 months or something. I left like 2 months in.
And again, I don't blame any of the people. I have no grudges against any of the managers, even the skip manager, because I remember when I was quitting they told me like, yeah, like sometimes we do get let people go and stuff like that, but I don't see it that way. I just see it as like a bad culture fit. And so, they were trying to be nice about it, but again, they weren't even trying to hide it. Like it was obvious that the culture is like intense. And some people would say toxic. I'll use the word intense to be more generous, but yeah.
Later on, you were able to get into Google many months later. How did joining Google feel compared to Amazon?
It was the opposite experience. And they're kind of opposite companies in a lot of ways. Like the business culture, even the tech culture, and all that. But I was kind of in like Amazon PTSD mode, where I was like, okay, like that was my first kind of like real professional experience. I extrapolated that to be like everywhere in big tech, or even just professionally in general. So, I was like, okay, you're supposed to not ask questions, you're supposed to not talk to people, you're supposed to not even be friendly, you're supposed to just like work, and just be as intense as possible. But people were very friendly to me, and so I kind of reciprocated that. But I didn't ask questions, I was very scared to. So, I worked on my own for the most part.
And I was given a project from my manager that turned out to be more difficult than it was supposed to be. But I was still in the mode where I was like I just got to get it done. Like this is my project. Like I have to do it independently. And so I was very fortunate in that where I did have like a very supportive manager, a very supportive team. And because I chose to do pretty much all the work by myself, the manager and team saw me as like independent, which is what you need to do to get promoted from like junior to mid-level. I was very lucky to get promoted like very quickly because of that. And that helped me build my confidence a lot. That made me realize like okay, like I can start asking questions now, which is funny. Where like after I got promoted is when I was like more comfortable like asking questions when like you'd expect that from a junior engineer more.
This is so interesting because you've only at that point had maybe 2 months of professional experience working at Amazon when you join Google another 6 months or so later. And how you can have a lot of reflexes ingrained in you coming into a company. So you can almost imagine like another engineer who had like two or three jobs before, you know, they might have built up all these onset things that are coming from other companies' cultures or what they've learned and when they join, it can be hard for them to adapt to the company. I'm not sure we think about this in the industry.
Yeah, I think it's kind of funny you mentioned that because I was in Google Cloud where a lot of the leadership was from other companies like Amazon and we had a VP or GM. He joined it from Amazon for a few months and he actually left shortly after that as well. Like I don't know the exact stories behind that, but I think there is a lot of like in the industry a lot of culture can get like mapped. A lot of people at Google didn't like the Amazon managers because it's like oh, they're going to be less likely to like take us on a trip or pay for us because they know that Amazon has like the frugality and Google doesn't. But slowly like while I was there, it slowly started to get going that direction, especially with the layoffs and all that.
Getting promoted at Google, what does it take? What does it mean? I know there's promotion packets. I know there's committees. What did you see from your perspective?
Pretty straightforward, I think. Like going from junior to mid-level is probably easier, I think, than from mid-level to senior and as you get higher and higher. In my case, it was mostly just about like working independently. And then once like I was lucky to get promoted, I think, in about a year, almost exactly a year, which is very uncommon at Google. And I could sit here and probably humble brag and act like I'm just like this super genius.
But I think it was really, I think there's like you have to one, put in the work, two, be reasonably smart, but I think the vast majority of people are reasonably smart enough. I think it goes into the other things where it's just right team, right project, cuz if you don't get the right project, there's no way you can prove yourself. You could be a 10x, 100x engineer, and if you're working on relatively easy stuff, you can't really say that you solved like a really hard problem. So, I think it takes a lot of that.
Google has a lot of like documentation where it's like every single thing needs to be supported with like some metrics or some artifact, like some design doc. And so, they have like this culture of probably producing too many design docs for really simple things. Some people don't love that, but I think in terms of like processes, it's just a necessary evil at Google, because otherwise, some engineers might just like work on stuff that they just feel like working on, there's no impact to the business, and so it's hard to kind of like quantify that.
And then on the side, even before Google, you started what is now known as NeetCode, and a lot of people watching or listening will know you or even your voice from there. Can you tell me how that all started and how it continued as you were working at Google?
Yeah, so I initially started after I quit Amazon, I think, like 6 years ago. And I was doing it really just for fun and for the love of the game, because I
You were recording videos, right?
Yeah, I was making these like tutorial videos. I was like, I'm studying this right now. I got nothing better to do. I might as well like help some other people. And I found it very difficult, because there weren't really tutorials at the time. There was just a lot of like forum posts of these really like complex solutions. And I'm like sitting there banging my head against the wall trying to understand it. And I think most people didn't understand the solutions because it's very hard to. Like I think most people just looked at the algorithm, kind of had a high-level understanding of it, didn't quite know why it worked, but it was good enough usually to, if you saw that question in an interview, you could probably pass the interview.
And this goes back to like deep thinking, which I think was a skill that, it's more of a personality trait for me, but I think it helped me a lot with like the LeetCode stuff. I went really deep into things that at the time felt kind of meaningless, where it's like you make this video for 50 people watching. And you did a great job, but it like clearly like it's not worth the several hours it takes to do that. But I kept doing it cuz I enjoyed it.
About a year after I started making the videos consistently, I think I did get into Google. Very fortunate to do that. Interview process was pretty easy at that point, thankfully. So I kind of backed off the videos. I was like this is kind of a like, like it was fun, but I'm at Google now for the rest of my
have your Yes.
Yeah. And then I saw that actually, like I made a video telling people like, "Hey guys, I got into Google, by the way. You might not see me as much anymore." And funny enough after that, the channel like went exponential because I think it added like so much credibility. It's like, "Okay, this guy didn't make these videos after he got into Google. He actually made it before." And so like this is what he did, and then he got in. So it's like the best sales pitch in the world. Like I proved it. Like I went from zero to one. And so it was I guess a really good selling point. And it kind of bothers me personally because it's like the videos didn't change, right? Like the branding changed, but that made like a really big difference.
Yeah, and so after it went exponential, I was like, "Okay, maybe I'll make like a website." And then the website was completely free at the time, which is really a catalog of the videos to make it easy to use. And that went viral as well. And then so pretty shortly after I got promoted, I was like, "Huh, like maybe I can like try this full-time." cuz I really loved it. I couldn't go as deep as I wanted to at Google. I had to solve business problems, but with algorithms and data structures, I can go super deep, more deep than most people would ever want to go into those things, but I had a reason to because it's like, "Okay, I can explain these things to people." And so yeah, I think it was just, it was like the right timing for me. And then afterwards, thankfully it's like worked out so far. But
You were at Google. You just got promoted to L4, which is still mid-level, but you now had a path to L5, which I mean, it used to be the terminal level at the time. Now L4 is a terminal level, but you know, in Google you go to L6, L7, L8, principal scientist. You had that path of like staying inside Google, do this stuff, or start your business or turn this into a business and go deep into algo coding. How were you thinking of the two options and what you would give up or what kind of, you know, how much risk would one or the other have?
Yeah, I thought about that a lot because even though I didn't love certain things about Google, I actually really liked the company. I liked the people and it wasn't this super stressful environment. And when I was leaving, my TL, who was basically my manager at the time because my manager had
TL being tech lead, right?
Yeah, tech lead. And he kind of asked me. He said, "I'm a bit perplexed that you're leaving because you got promoted very quickly and you could probably get promoted again." And like, I did think about that a lot because it seemed like, because that was what I was going to do the rest of my life. I was going to work at Google. I was going to, you know, get promoted. I was going to be like the best engineer I could be, but I just felt like the timing of it, like I had a chance to try something by myself. Maybe that opportunity isn't going to be there forever.
Google does make it easy for people even to this day, if you leave, you can usually come back within a year if you're in like good standing with your team and stuff like that, which thankfully I was. So that kind of made it a little bit easier. I have friends all the time that are making like the same decision. They're asking me like, "Should I leave Google?" I just had a friend last week. She wanted to like do content creation full-time. I think it's like a trend almost these days where everybody's quitting their job to do their own thing, but
Well, I mean, I think it turned that in like we always live in bubbles, right? But in like certain bubbles it is. How was the switch? Can you tell me like you actually went from like okay, well, you made the decision, you went from like having a really structured work day, a team, everything was figured out. Google has amazing internal infra. You can just focus on okay, the business problem is still coding.
And now you're like okay, you have the website, you have a Git repository. What was the switch like? And what was interesting about it, or like good and fun? What was difficult?
I had a tough time with the learning curve at Google, but once I left, I had a tough time like transitioning away from some of the tools because you get used to it very quickly. Like they have like GitHub, I'm just not a huge fan of it. I know a lot of people are hating on it nowadays with like the uptime issues and stuff like that. But I have other issues with it around like UX and stuff. I think Google has certain internal tools that aren't so great, but they have some that are just like super super good. And there's been a lot of companies that have been started just because like Google built something and then they're like, "Hey, we could make this public." So, then they leave and then they start like Cockroach Labs or something crazy.
What about like you went from working on a team and now you just had to do everything by yourself? Was that an issue or was that kind of natural to you?
Yeah, that was actually a huge thing for me where it was hard to build a team. It was hard to like work with people. Like I kind of said at the beginning. And I've only just recently, I would say within the last like 6 months, gotten used to it where now I finally feel comfortable like delegating things and like managing people. And finally, like it took a long time for me, but once it finally does click, you know, you go through like so many experiences, you hire some people, you have to let them go, you figure out what works, what's a good fit, and even just how to like motivate people. It's a very different thing like working with people cuz everybody's different. They're not like agents where you just give them the task and they're a machine. They're just going to spit out the code. Like people are people.
And so those types of things, there was a huge learning curve for me. But now, and I hated it before, but now I actually really love it. Because it's like when it does work, when you find somebody and they're a good fit and you feel like you can contribute to their growth. You can like guide them a little bit. Like you can steer the ship a little bit and you see like how much of a difference that makes to them. Like now I finally understand what leadership means when it works. Like when you're an effective leader, you can make a magnitude of difference even like in a small team, but I imagine like as you get to higher and higher levels, it can make a huge difference. And you see that with CEOs sometimes when a new CEO takes over, the entire company either can go like up or maybe it goes in the other direction.
When you started, so like you quit Google, you had a website that listed your videos, I guess very simple HTML, CSS, maybe a bit of JavaScript. What did you build then? What was the tech stack behind it?
Yeah, so initially when I made the free site, I was still working at Google. So I just chose some like random Google tools. I was using Google Cloud Firebase because it was so easy to use. I regret that one because now I meet so many people. I'm like, oh maybe I should do Convex now. I should have done, you know, something different. But I also did Angular at the time, which is what I used at Google. So I was like it makes sense. Maybe I can just learn it at the same time. Regret that one as well. But thankfully we've gotten to a point now with LLMs where migrating things has become relatively trivial. So like maybe that's something I'll do.
But in terms of like building the application itself, for whatever reason, I just didn't find that super interesting because there's usually not that many deep problems. I think the interesting things came from like innovating and like doing things in a way that like people care about. Like nobody's going to care that much about like the performance of my site or the tech stack I use or like any of these like little things. They're going to care about like the UX, like how well did I explain something in a video? Cuz if the explanation sucks, nobody cares like how pretty the site looks.
The video is the product, or most of the product, right?
Yeah, because it's education. So, it's like if the education is bad, then nobody really cares. And I was very bad at building, but I think the idea, the concept, the value was good enough that no matter how crappy the site looked and like how bad the tech choices I made, the business value like exceeded everything else. Like that mattered more. And so, that taught me a lot about like prioritizing things that actually matter, and then you can take shortcuts on the things that don't matter.
I think I saw Elon Musk has like this four-step or five-step process for optimizing like a workflow and like a process where, you know, you start cutting things out. And sometimes you cut too much out and you realize you made a mistake and then you can like slowly introduce that back in. And so, I took that kind of approach because I was mostly working by myself. I probably should have hired people to move faster, but I didn't. And so, because of that, I took a lot of shortcuts. And I still take shortcuts today because there's just so much value in it. And like I have a story I can tell that people probably get mad about, but it's worked so far for me. So, I stick with that.
What's the story?
So, I have this service that I was paying like 3,000 a month for. And then I think late last year, early this year, when like the AI vibe coding stuff went really crazy, I was like, I knew I could probably write my own version of this service.
What service was it?
It was like for code execution. And so, I thought like probably I could write my own version of this within like a month or two. But the 3,000 a month opportunity of that versus like other things I could be working on, there were other more impactful things that I could be doing. But I thought, okay, with vibe coding like maybe I could get this done in less time, maybe a couple weeks if I'm lucky. And so, I actually got it done in like two or three days. And it did take coding skills. Like if I didn't know how to code, I would not have been able to do it. But I got it done in like three days. And then so I deployed the service. And so now that I'm managing it, it costs me like 200 a month versus like 3,000.
But there's a bug in the service. I think there's a memory leak or something. And so what happens is I have this service deployed. Every couple days, like one or two instances will crash, right? So there's clearly an issue, there's a production issue. I could spend the time to go into that and fix it. This is like one of those things where it's like you get into vibe coding and you run into an issue and it's like, okay, now you're going to have to actually dig into the details to really understand like where the issue is coming from. So I think it would actually take me much longer than three days probably to find the issue. So I haven't even bothered with that because I'm like, well, okay, if one instance goes down, like I'll just have several instances running at the same time, right? I'll have like four. So if one goes down, and it doesn't happen that frequently.
Neet was just talking about operating a service when you have to manage your own infra and taking care of spinning up new instances when one crashes. This is a perfect time to talk about this episode's sponsor, Google Cloud Run. As software engineers, we really just want to write code, not manage servers or wrestle complex scale and configurations. Google Cloud Run is a fully managed platform built to let you run any code on Google's world-class infrastructure with zero management overhead. Whether you're running web services, batch jobs, agents, or fine-tuned LLMs, deploying is as simple as typing gcloud run deploy or connecting your GitHub repository.
One thing that makes Google Cloud Run stand out is auto scaling and built-in redundancy. Cloud Run scales up instantly to handle massive traffic spikes and scales down to zero when idle, all with no manual intervention. This means you pay absolutely nothing for quiet projects. Personally, my favorite feature is how Cloud Run handles zonal redundancy and automated failover for you out of the box. And before you dismiss this as something you might not need, I just recently covered how Coinbase was down for 10 hours because they did not have zonal redundancy in place for their global trading service. And the reason they most likely did not have it is because it's a ton of work to build automatic failover even for a zone level. And I personally cannot name many other infra services where you get this kind of failover out of the box. All these capabilities let you focus on your code while Google manages the infrastructure and operations. Stop worrying about infrastructure and start deploying. Try Google Cloud Run today at cloud.run.
I also want to mention our presenting sponsor Antithesis. Neet talked about memory leaks in a service that he knows about but just doesn't have the time to chase down. If you work on distributed systems, you've been there. You know there are deep bugs there. You have no way to root cause them, so you can only hope there's nothing really catastrophic. With Antithesis, you no longer have to rely on hope. Antithesis lets you fix and find all sorts of bugs easily and efficiently so you no longer have to choose between shipping quality and shipping fast. Let me explain how.
Antithesis runs your whole system in a hostile simulation. By doing so, it finds every bug before your users do. And because the simulation is fully deterministic, Antithesis doesn't only find bugs, it gives you a perfect reproduction of every issue. I know this sounds closer to science fiction, but it's actually hardcore engineering under the hood. Jane Street, Flight Data IO, and the etcd community ship agent-written code with full confidence because they know it's been verified by Antithesis. To see more case studies and details, head to antithesis.com/pragmatic. That's antithesis.com/pragmatic.
And with this, back to Neet and his story on why he's happy leaving a production bug unfixed.
It's an interesting trade-off where like the engineer in me hates that because it's like there's an issue. Like fix it. But the business value makes no difference. Like there has been practically zero outages. I have less outages than LeetCode, and I'm like a couple people doing it. So it's like, I just think it's like a trade-off. And people could argue one way or the other, but I think it just makes so much sense right now for me to not like fix it.
But it's still interesting. So, you paid for an engine or licensed it that, if I understand it, was executing code, right? So, when people like type out stuff in your editor, it runs it and you can check it, it can like run your problems against other solutions. You used AI assistance, you knew what you wanted to build. You built this engine in a way that, you know, you think it should work. You tested it. It seems to work everywhere. So, you deployed it and it took you 2 or 3 days. And now you have this... There's a quality regression, but it doesn't make a huge difference to the thing. But I want to push you on this. Like do you not think this is a little bit typical of what we're seeing with AI-assisted coding or AI coding, of like a lot of people are like, again, like oh, there's this SaaS that my company is paying for. I'm a founder. I'm paying for it. I can replace it. And you build up something that is subpar and you kind of get by. And then again, it makes no business sense to fix it, or it's now too difficult cuz you didn't write all of it, but of course it was faster.
So, the way I think about it is like if I did fix the issue, I could probably allocate like a smaller pool of servers. So, maybe I could save like a hundred bucks more. And I do think about like okay, does this actually make a difference? Like I've actually thought about it a lot. I'm like, should I just fix it because like is it going to be an issue later on? And like I initially tested it. I was only sending like a small amount of traffic to this service and I still had most of it going to the original one. So, I just ran it for a couple weeks and I was like, I vibe coded this. Like I'm pretty sure there's going to be issues. And I saw like literally no issues. Like it's just up. Like okay, once in a while one of the service's servers will go down, but then it just gets replaced in like a couple minutes. That's just how I think about it. It's like it just doesn't matter. Like my service is technically faster because I run it on like better hardware. Yeah, I just see that like nobody cares. Like, no user has mentioned anything about that to me. It's better now.
So yeah, so I guess maybe to look at it a bit better, it's overall like better because it's cheaper, it's faster, and yeah, of course there's trade-offs. Like, within engineering there is now a regression that crashes one of the servers, so you run an additional one. You have like replication, if you will. And it's still cheaper overall. So like, overall as you package it, it's better than before. Boom. Like, it is kind of an obvious business decision. And like I guess in engineering there's a question of like how perfectionist you need to go when a problem is already solved and is good enough.
Yeah, that's right. I mentioned at the beginning that it like bothers me that you can't go super deep. And so even for this, it actually does bother me. But I guess I've gotten used to it in the sense of like prioritizing the business and just thinking about like the actual value, what do people care about, what's actually going to make a difference, like not just in the short term but also in the long term.
Let's talk about this, the how, like especially as a founder but even as a software engineer, like at some point you need to start to think about the business. But the interviews that people are taking with NeetCode in order to get into big tech, you know, first you need to jump the hoop of coding interviews. What do you think preparing for these data structures and algorithms coding interviews gives to people that is actually useful on the job? And I'm not talking about the algorithms, but the other things that you gain by preparation.
Yeah, I think so. From my perspective at least, I like went through this four-year degree. I didn't cheat through it, so I made sure I understood like all the fundamentals and things like that. And then I got in Amazon, and then I left, and then so for that like year before I got into Google, I was really just doing NeetCode. I was making the explanation videos, and that kind of taught me about like speaking and communicating and like thinking deeply about like a problem and maybe like the trade-offs between like algorithms and data structures and stuff like that. But I didn't really do much development.
And then so when I did get into Google, I was still able to get promoted even though I think like in terms of just regular like raw coding and coding experience, I was probably subpar compared to most people. But I was still able to, like for a hard problem that I had no idea how to solve, like using internal tools I've never used before, I had the skill of okay, I can sit down, I can go through this stuff, I can kind of make a plan of how I'm going to try things. And I worked a lot on my communication so that I could go to my manager and say, "Okay, so this is what I'm thinking." Kind of like you do in an interview, right? Like okay, this is the approach I'm thinking. Like this is what I'm thinking. Like I'm going to go ahead and do it just so you're on the same page. Like maybe you have time to like look into it and give me feedback or maybe you don't, but just so you're on the same page. Like this is
what I'm going to be doing. So funny enough, I do think I've gained a lot from algorithms and data structures in terms of just thinking. Also on the communication side and also on the trade-off side, which I think is really what engineering is about, and it goes back to what people are experiencing with agentic coding and stuff. Everything is a trade-off. In engineering, there's no correct answer like there is in math or science. Engineering is about the best solution at the time. Like we're talking about the memory leak issue with my service, right? It's a trade-off. There's no correct answer, especially in business. There's no correct answer. And so I think that's what a lot of people are maybe missing nowadays, where they're focusing maybe too much on the hard skills of, okay, can I write this loop? Do I know this particular data structure? Do I know all these little things? When I think they're forgetting to zoom out and look at the bigger picture of what engineering is even about in general.
Because what you see in the real world is you'll see a really good engineer going from one domain to another, a really smart person going from one to another. And you see that and you think, what do they have that other people don't? It's usually not some very specific skill, that they know this programming language super well. It's usually something related to that. It could be data structures and algorithms or some hard skill. It's what you gain from that in general. And I think that's education in general as well, where you go through 20 years of your life learning about all sorts of subjects and that molds you in a way that's very hard to articulate. It's very hard to be precise about what exactly you gained by learning math and physics and speaking and writing and history. But clearly there's a lot there.
Sounds like you're saying that the effort of learning, the effort of going through doing hard things that might be pointless at the time, or solving problems that are maybe abstract or not for a specific thing, they add up over time.
I think so, a lot, and this actually reminds me of a conversation I was having with Chip Huyen. I think you've also had her on the podcast, and she was... 'cause nobody knows what's happening with AI. So we were talking about it and she mentioned that in her opinion it's very hard to know what hard skills are going to be important, right? Which programming language should you learn today? How high level should you go? Do you even need to know how to code, right? But as she mentioned, okay, those are impossible questions to answer. But the one thing that she did understand is systems thinking, this broad concept that applies to engineering and computer science but also to many other disciplines as well.
And the way I kind of understand it, to use an example, is maybe in construction, right? You walk around, you see all these buildings being built. You see the workers. And whenever I look at that, I see this big complex thing and all these people doing all these little things. And then at the end you have this big building built that's so complex no one person could probably do that themselves. But it goes back to: you have the workers working on the individual thing, but then you have this entire system. And somebody set up that system. Somebody set up those rules that, okay, a worker is going to do this, there's going to be this procedure. This is what we're going to check to make sure that there's no issues. We're going to verify things. We're going to have this big process, this system of making buildings, making sure that you don't have issues with that.
And I think that is a skill that there's no course for, right? That's a hard thing. Most people aren't building the system. They're the worker bees. They're not the ones architecting this whole system. But I think that's the skill that is so important, because that's where all the value comes from. You have these worker bees, but without the system nothing's going to get done. And so I think that type of thing is not going away. And it's impossible to learn, but I think it takes a lot of things to get there.
But I'm going to push you a bit on that. Is it really systems thinking, or is it learning a domain? Because systems don't exist in a vacuum. You will have agricultural systems that are very specific to how the agriculture industry works. If you're in the legal industry, it is based on whatever country you're operating in, if you're in a legal tech startup. And health care: a health care startup looks very different in the US versus the UK versus in Romania, etc. The people who are great systems thinkers in one domain often just really understand the domain. And payments is one example where I worked, which is very interesting and complex. Once you get into it, people start to move around in it because you go there. So I wonder if there's abstract-level systems thinking, but there is also becoming a domain expert, and somehow they kind of overlap as well, because if you are a domain expert, you must understand the system of that domain. And maybe if you understand multiple domains, you can get better at abstract-level systems thinking as well.
Yeah, no, I completely agree with that. And I think for me it's definitely hard to quantify and articulate because it's very kind of vague. And I think you're definitely right, though, that the hard skills, the knowledge and the details of certain industries and things like that, that definitely matters. But I don't know. I guess when I think about it, maybe you know people like this as well. There's certain engineers that could go from one domain to another and you just trust them. You just know from working with them they're smart. They think in a certain way where they could go from payments to some completely other industry, real estate or something. And there will be that learning curve for them. But some people, for whatever reason, just learn faster, they just get it faster, they just perform better.
And I don't think that this is something that was innate, that this was just handed down by God, that some people are just smarter than others. I think there's a lot that goes into it. I can't probably articulate it super well, but I think a lot of the things that people might say, like, oh, it was a waste of time to learn this subject 'cause I didn't actually use those details on the job, I think that's a very wrong way to think about it. And I think that's what a lot of people are doing now with AI. Like, hey, what if I'm not going to be writing for loops a couple years from now? I don't think those things are a waste of time.
It sounds like you're saying that you don't think it's a waste of time to go deep and understand things.
Yeah, absolutely.
Especially when it's hard to do so.
Absolutely, yeah.
Let's talk about the hiring bar at FAANG and companies, the big tech companies. A lot of people are using NeetCode to prepare for these interviews. You're getting feedback from them. They will write to you when they succeed, or they will write in frustration after many months when they haven't. So you get a bunch of signal here. What are you seeing in terms of just the algorithmic part, the coding interview? Are things staying the same, getting harder, getting easier?
In terms of the format, especially at the early levels like juniors and stuff, it's still a lot of algorithms and data structures, the format itself. I've definitely seen, anecdotally, people mentioning that it's getting harder. At the same time, from the people who do pass the interviews, at least at big tech companies like Google and stuff, I'd say the difficulty is not that different from what it was before, at least in the US. I think it varies by country. You'll see some countries, like India, it's very different. Everything's pretty much algorithms there. It's LeetCode hards and super hards and stuff like that. But in the US, I don't think it's that crazy. Yeah, it's not too crazy.
Yeah, but I guess going without any support, like in a whiteboard, it's so hard to prepare for that. It's never been easy.
Yeah, absolutely. And I think the one thing that's happened a lot is there's been cheating tools for interviews. And so we've had mostly remote interviews for the last 5-6 years. And that's been changing a bit. I think Google has pretty much gone to on-sites at this point, back to the traditional whiteboard format. And they'll let you code on a laptop if you want to as well, but it's going to be in person. Somebody's going to be watching you code, and you're probably not going to be able to cheat your way through that.
What are interview formats that you're seeing, where we're talking about other companies, especially smaller ones, experimenting? What are interview formats you're seeing or you think are actually kind of promising? If you were running a smaller mid-size company, you might actually consider instead of the... And you're talking against yourself here. But if you had to throw away the DSA interviews, what is showing promise, especially with AI as a tool?
Any process that you have that's going to be standardized and super scalable, there's always going to be ways to game that. And the best way to get around that would be to hire somebody who's an intern and you saw how they performed. And what I've heard from a lot of companies I've spoken to in the last week is that a lot of small companies that can get away with it are doing trial periods. It could be a few days. It could be a month. It could be even a couple of months, kind of like an internship. And I've spoken to other companies that say that that's difficult for them because if you're trying to hire somebody who already has a job, that's not going to be feasible. You can't really do that.
But I have, believe it or not, leaned in that direction, where I can get a sense of somebody's LeetCode abilities pretty quickly. I'm not going to spend four interviews going through and asking somebody data structures and algorithms stuff. I just have them do work that might be similar to something I'd give them on the job, or even just have a conversation with them. See how they think. Can they think through trade-offs? I don't even care about what answer they give me to a problem. I care about why they said that. What can they say? Is it just something that they saw in a ChatGPT prompt and are just regurgitating it, or can they actually talk through it? And then when you look at the work that they're doing, same thing. I ask them about it. Why did you do it this way? What's good about this? What's bad about this? What could be improved?
And I think it's a hard format to scale for big companies. That's why I don't think that that's what's going to happen in terms of big tech. But it's worked for me. It works for smaller companies. But once you get to a certain size, it's harder to do.
Yeah, 'cause basically people are doing the work and it doesn't matter what tools they use. In fact, if now everyone's using AI agents, then yeah, they're using it as well and you actually get the signal of how they're doing compared to others. Interesting, because one type of company that doesn't really have trouble hiring is the ones who are working in open source. And they will often end up hiring the people who are contributing to their repos and adding all the features already. And the conversation will probably be more of a soft skills conversation, 'cause, yeah, we're seeing your work. You've been selflessly pushing features to our product. Awesome. And I guess that's kind of the upside of open source.
I think Dax mentioned this, because I was speaking to a bunch of people that work with him, that they were either contributing to OpenCode already, or Dax knew of them from open source work that they had done on projects of their own, and they just got a DM from him, and he's like, "Hey, would you be interested in working?" So they already had this work that they could showcase, and if you're doing things in public, people can get a pretty good understanding of how you work.
Speaking of how you work at NeetCode with your business, you and your team, how do you work? What tools do you use, and how much code do you actually manually write these days, if any?
Yeah, so I would say over the last 6 months, actually, we've been cranking a lot of features out, a lot of code out. Most of it has been written by AI at this point. And before that, that really wasn't the case. I was actually a really big AI hater for a long time, and people still sometimes think I am, and sometimes if I'm pro AI they're like, "NeetCode, you changed. What happened? Now you're an AI shill." But I just try to be pragmatic about it, because before I was still using the tools but they just weren't as good, and now they've gotten to a point where they can handle the work that I'm doing, which is mostly CRUD. Usually there's not that much crazy interesting stuff other than the code execution service. That's probably the most interesting one.
But I'm using pretty outdated tech, even. I'm using Angular on the front end, a Google tool that nobody likes, and I'm using Firebase, which isn't horrible. It gets the job done, but it's a little bit outdated at this point. I'm using Google Cloud and TypeScript.
But I would say initially, the first few years when I was writing most of the code, very, very bad code quality. I used TypeScript, but I was not using real TypeScript. I had a lot of any. Yeah, I had a lot of bad code. I was putting inline CSS. I was just doing all sorts of stupid stuff just to get stuff done as quickly as possible, because I knew the entire code base. I knew this certain tech that I can just deal with, and so that was a trade-off for me just to move quicker.
But with AI now, actually, I've gone back and I realized that that trade-off was so worth it, because I cleaned all of that up with AI, because that's what it's for. It can clean up a lot of sloppy code, it can refactor a lot of things, and if I really wanted to now, I could probably migrate to other tools very quickly with AI. So just to go back to the trade-offs, I think it's just about thinking: you might make the wrong decision, but even if you make a decision, you can go back and then try to correct it, just kind of by thinking about it.
You also post a bunch of hot takes on social media as well. I don't know if it's a 2:00 a.m. thing or... But one of them you said, and I'm quoting you: "Now in 2026 it's never been easier to build things, but I would say that it just makes it 10 times harder to actually build value."
Yeah, I think because it's so easy now to implement a lot of things, and people weren't implementing those things before because they just weren't worth doing. In my case, I went to the code quality example. I think that was worth doing because it matters, it can help you go faster, it's more maintainable. But in terms of features, a website, you can just throw features in there nowadays
that nobody really cares about and you can do it so quickly. Like a new feature every single day, but do people actually care about that? Is that making it better? It could be making things worse. It could be making things more confusing. You have like things that are cluttered, you're maybe making the site perform really slowly now with all these features you're adding that nobody's even using and so I think speed matters in business, but I think decisions matter as well. If you're going so fast, you're not measuring the impact of the changes that you're making, you don't have time to do that cuz you're just focused on shipping and then things regress and things get worse and we've seen that at Anthropic recently the last like month or maybe more than that where things have regressed. And I think just a couple days ago, they put out like a blog post acknowledging that finally.
But like for them, they were just moving so fast that they did not notice. Like I saw Boris saying like he was replying to a lot of comments asking like we haven't really noticed this. Like why is everybody else noticing it? And now they have and I think it's again just goes back to trade-offs. Like now that maybe they've realized like okay, maybe they should slow down a little bit, focus more on quality and stuff like that or maybe not. But
I guess it does give a little bit of relief that you know, like we knew like pre-AI it was pretty clear that if you move fast, you typically you often break things. You know, Facebook even had this famous motto and so or you can be more deliberate and break fewer things. But there's almost like this slider, like how fast you move or how reckless you are versus how stable things are. And it was kind of true. And now with AI, we for a while thought like well, you know, maybe this is not true. Maybe you can move fast with quality. But we're seeing with Anthropic like they're moving fast and they're breaking things. And I mean their business is growing, don't get me wrong, but still like I guess this truth did not change because of AI.
Yeah, it's funny because even OpenAI, they did like Sora and now they're shutting it down because they realized like okay, so Sora is the social network. Yeah, yeah, yeah. The AI videos like these cat videos that you're seeing all over the place. And so they realized like actually like they're doing too much. Like doing less things now and now they're kind of refocusing on like coding in a smaller set of things. That's actually producing more value. Now they're kind of going the Anthropic route where Anthropic is going like pretty quickly, but they were focusing mostly on coding. And so I think that's interesting as well to see that like actually playing out at the highest of scales. That like the fastest growing companies in the world, like OpenAI, are even doing this. Like they are not like trying to do everything. They're refocusing now and trying to maybe slow down a bit.
This is a bit contradictory though. Like we're almost saying that well, maybe one thing we're learning observing AI that focus is more important than executing quickly on a lot of things. Wow.
Yeah, it's funny. It's like I think even the paper that started it all like the Transformers paper was titled like Attention Is All You Need where it was funny it was like focusing on like the certain tokens, the relevant tokens like mattered the most.
Yeah. Well, one interesting experiment you did is you did a redesign contest for NeetCode or I think the site. You offered $2,500 for whoever submits a redesign. Can you tell me how that went?
Yeah, so I'm still going to evaluate the results, but so far from what I've seen it's been a little bit disappointing. I'm going to try not to get like too mad at anybody or make it personal with anybody, but it's very obvious to me that practically all of the submissions are created with AI, which is fine. Like if you're going to use AI, that's completely fine. But again, like with the few people so far that I've spoken to and asked them questions about okay, like your design like it looks like you made certain choices, right? You moved some buttons around, you removed some buttons, you removed some content, you added certain content. Why did you do it? Like what's the pros and cons of like maybe doing it this way? They can't answer it. And if they do answer it, it's clearly like a very vague answer where they didn't think about it. Like me looking at their site for 5 minutes, I can articulate things about their design better than they can.
And it's just disappointing. It's like I don't think that's like a matter of intelligence. I don't think it is. I think it's a matter of like effort and caring and probably skill set as well. Like if you just have the skill set of like designing things. But I don't. I'm certainly not a designer. But like in terms of a site, whatever like the business is, you should be able to say that okay, so like this is about coding interviews and we're trying to maybe show people that this is interesting or trying to explain it in a very clear way. Nobody can say that. They're just focused on like how pretty the design looks. They're like, "Oh, the colors on this like the styling looks crazy." But, that's not what I care about. That's not what most people care about. Like nobody cares how pretty a site is if they don't really understand what it's for or like what value it's going to give to them. I think that's what like UX is about. It's not about like how pretty something is.
But, I guess in all fairness, right? Like this was a contest where you're like, "Okay, if the winning design will get $2,500." I guess it kind of flips the incentives a little bit because this doesn't mean that you are paid $2,500 to create a redesign. It means that if you win, you could get that. And of course, the more people submit something, the lower the chance. Therefore, if I'm just being logical here, like the effort that's worth me putting into it is let's say maybe if it's like 10 contestants, it's like maybe $250 or like if it's $125. So, in the end, of course, you just do a prompt, you give it to AI, and I guess what you're seeing is you're getting a lot of low effort submissions. And you're seeing there's like not up to par.
Yeah, I thought that a contest would have been the right way to do it because then I don't have to like hire, I don't have to like filter people and stuff like that. But, in hindsight, I think it probably wasn't. I probably should have just found like and maybe even just a small pool of people and then just paid them up front and then just saw the work and then maybe chosen based off that because I think there has been like a lot of low effort. It's been disappointing to be honest with
Well, you live and learn. But, I guess it does prove that just giving a prompt to an AI which is low effort, low cost, it will not result in magical effort, especially not with design.
Yeah, I think so. And I think it's funny because I think somebody could just use pen and paper, just kind of describe like what they're trying to do, like the main choices that make something better. Like on my site, even the parts that I've used AI to code, I can articulate exactly like why everything is positioned in a certain way. I can go back to like, "Okay, like metrics, like this is used the most, so I want to make this prominent. I want to make this like a little bit different than you've seen on other sites so it doesn't look boring," stuff like that. But, the people like submitting the designs, they can't really articulate a lot of these things to me. And I think like I said, if you just do it on pen and paper and then give it to an AI, then the AI can just do it. Like I don't care how pretty something looks. I told them like what criteria I actually cared about, and I think, you know, some people just didn't follow the directions or whatever, and that's fine, I guess.
One of your hot takes from a few months ago, the end of coding as we know it. Let's talk about it. Tim O'Reilly wrote a blog article about a year ago where he predicted that things would change, and you were reflecting on that.
Yeah, I think it's been really interesting because a lot of people don't really go back to actually look at things. They're just like forward-looking, but I think it's important to like go back and see how like things played out, cuz that can help you like see how things are going to play out in the future as well. And it's been interesting like with how much coding has changed, with how good the models have gotten. At the same time, it's kind of surprising to me that we're still in like a very wait-and-see mode. Like companies are still doing layoffs and things like that. But, in many ways, things have not changed as much as I would have expected. Like a lot of my big tech friends, they're coding completely differently now. But, in terms of like the way the business is working, they're kind of doing like similar stuff. Like most people are not getting laid off. Most people are still employed. They're still doing work. They're doing more work than before. And I think companies are sometimes realizing that they maybe moved too far in the direction of AI, so they try to rebalance. It's still like a game of tradeoffs. It's still a game of like move fast and break things.
I think programming is definitely going to continue to change definitively, and you know, maybe become a completely different field. But, I think a lot of stuff around like the business, knowing like the value to produce, and just like engineering decisions in terms of tradeoffs, that stuff is absolutely not going away. I don't think ever. Because how can you have an LLM weigh like the trade-offs for you? I think that's a very like human thing to evaluate what's even important in engineering in general.
Yeah, and also like for example, things like you know, in programming like when you think of like what is it that we code, you need to build a feature. You need to you know, the task is add a button where I don't know when the user hits it it files a complaint. Something, you know, like so they can report a bug. That's a simple one. You know, like that is not just a simple behind the scenes of like if button hit file a bug, it will have a bunch of like edge cases. It will check the state. You will need to know what the context is. Like and what to say, what kind of users are free user, paid user? Like there's all these edge cases, conditions, the domain, the business domain, all of these things. And they were all captured in code, which means it's captured in your head. But now that you're prompting it, the context is still there. And someone needs to know how important it is like
Yeah, I think like change is the one thing that's not changing. Because change just keeps happening. And I didn't mean to make that a pun, but like I just saw I think yesterday or today Microsoft is doing I think voluntary layoffs where they are Yeah, buyouts. Yeah, so basically if somebody chooses to they can leave the company and get like some severance. And I saw I haven't confirmed this, but I asked a friend and they said it's true. The buyouts are true, but not like the age thing yet. But basically they're only offering this to a subset of people at like a certain age and certain amount of experience in the company, which is kind of funny. Like if you're like a certain age, I don't know the exact age, and you have like 10 to 15 years at Microsoft, they're only offering it to those people.
Which I think to speculate, I think it's because maybe those people are less prone to like changing, they're less willing to maybe learn a completely new way of doing things. And so Microsoft is offering it to them because like now they have to move in a new direction. I think they did something very similar when Satya originally took over. I think they did I don't know if it was voluntary at the time, but they did a lot of layoffs. That was mostly to people
That was not voluntary in 2014, yeah.
Yeah, and so that was to a lot of experienced people specifically and not to the new people. So I think just being willing to change, being willing to do things in a way that you don't maybe enjoy kind of like when I joined Google like having to do things not going as deep as I would have liked. I think that's going to be pretty important.
Yeah, and you did say that you don't think there will be an extinction of programmers or programming even if programming changes, right?
Yeah, I think even to this point again it's like it's impossible to guess. Like my guess is as good as anybody else's, but I just don't see like thinking going away. I don't see problem solving going away. I think it'll change dramatically. It is possible like we might need like less programmers, but even to this point that hasn't been the case. Like every single time there's just like the big innovation like cloud computing, like higher level programming languages, for whatever reason it doesn't lead to fewer programmers. And I would have expected it would have. Like when you have cloud services that can just solve these huge problems that were so difficult to solve. Like Google had to work so hard to solve like certain distributed system problems and now you can just use AWS or GCP and just have that taken care of for you. So you would think that we just have infinite software where we're just doing everything and everything is easy and now we don't need as many programmers, but it just hasn't happened. And so based on that I don't know. Like you see things like Replit and Lovable where anybody can be a programmer now. And so I don't know if that's the direction we're going to go in where it's just very very high level, but
But it's very interesting because on one end of course we have these primitives that are getting more and more capable like the cloud. You would think there's competition between AWS, Azure, and GCP, Oracle, and so on. And so, you know, the prices will obviously be as low as possible. But then, you have someone like DHH who is like, "Okay, well, we're in AWS. We're spending a few million dollars per year. You know, like get rid of the Amazon services and just do it locally." Which everyone thinks is going to be expensive and so on. And they do it, and they're now doing a massive saving. So, it's almost like these abstractions are often becoming a lot more expensive to run. Which is fine for most people. But when you get to a certain scale, you might start to invest in software engineers and building your own software and maintaining it to just reduce costs, which 37signals has done. So, I wonder if anything, there might always be a value in at certain scale, you know, like rolling your own stack or go a level lower than what you're getting from whatever pre-built stuff.
Yeah, I think so. I think it's always interesting to see how things play out like in the longer term. Engineering is not a science. Like there's a lot of culture that goes into it, and you have companies that like in the cloud, like why did a company like MongoDB get as big as it did? I think like the tech might be like a small part of it, but I think a lot of it is just sales and marketing and culture. And if like one company's using it, it can snowball, and then like you have an entire industry using a certain tool. And then maybe they realize like actually like we went too far in the direction like we don't need to have everything in the cloud. Like it's not better. It's not saving us that much money. And some ways like we've seen cloud services get really, really complicated. Now it's like cloud-driven development. And like you have all these things, and it's like, "Okay, you solved one problem, and now you got a new one." With LLMs, it's like
kind of the same thing. And even the cost issue with AI is probably going to be like once the subsidies start running out, which we're starting to see, I think that's going to be a really big issue where maybe all these companies that embraced AI programming are now going to like cut back on it.
Yeah. You had a wacky train of thought which I'd like to talk about. It involved AGI. I'm not a huge fan of talking about AGI cuz I feel it's very like, you know, hard to talk about, hard to define. But let's talk about it. You were saying like, let's assume that there would be an AGI or a god-like singularity. These models would be amazing, which I think we can see they have limitations, but let's just jump forward. What was this thought on how we were chasing it?
Yeah, I think on a philosophical level it feels like you're trying to get to infinity, and it's like the closer you get, you're the same distance away from it, right? And that's where I feel like, as technology has gotten better, you would think that we've solved life at this point. Like we have abundant resources, and if we don't, we're not that far away from having enough food, water, and shelter for everybody. But something about life, maybe it's human nature or something, it just doesn't change. It's like you want more. Okay, now there's higher levels of programming. So now people are competing at the higher level, and as it gets higher and higher, people are still going to be competing on some level. Maybe it's easy to build an app now, but there's going to be a new problem to solve on marketing and edge cases and things like that.
But I also think maybe this is like a politics thing, because I think there's technology, and we should all be happy that technology is improving. If AI keeps getting better, if it really does replace every job, in some ways that has to be a good thing because now you could do something you couldn't do before. Like farming: a lot of people were sad about that when that went away, I'm sure, but it's been a net positive. And I think the only reason it wouldn't be a positive is if your livelihood depends on it and, like, politics, you know, you can't make money and then the government isn't going to take care of you. I think that's where it becomes an issue. It's more of a politics problem than a technology problem.
Yeah, but I think, you know, an interesting observation is, as we're seeing AI could make things better, I'm still waiting for the software to file taxes to be accessible to a normal person. Why, in every country I live, do I have to hire an accountant to file my taxes even though I don't have very complicated taxes? And that's one. And we're talking utilities, when your pipe is broken, when you want to find a plumber. So there's some everyday things where I would welcome software making things easier, but I haven't seen much progress in the past like 15-plus years. And not even right now with AI. So I'm like, it could be a nice trigger to see those things improving.
Yeah, I think it's funny because you look at history, and one thing that I always take for granted is that progress always happens and that things always get better. But if you look at most of history, for thousands of years, things didn't always get better. Sometimes you saw civilizations get really great and then they kind of collapsed, and a lot of the technology from that was lost. I don't think it's preordained that things are just going to continuously keep getting better. I think there's going to be a lot of decisions, probably on the politics and government side, where policies are going to get created, and I think that's going to have a really big impact on what actually matters to people and their lives and stuff like that.
Another one of your hot takes is how overhyping AI tools just creates slop and erodes people's skills.
Yeah, I think a lot of people, especially students, are unfortunately learning everything through LLMs. So a lot of that isn't really learning; they're just kind of cheating and they're just doing everything like that. And then they lose a lot of their skills, and I think long term that's going to be really interesting, because we're seeing that with even experienced programmers. I had a friend tell me that he's preparing for interviews now and he hasn't handwritten much code in several months. So it's very hard for him now to get back into that.
Yeah, this will be a longer time frame, but I do wonder if one side effect of this could be that a lot more companies will be doing in-person interviews, because you eliminate any AI assistance, you can actually talk with a person. And then in person, you can actually tell the difference between someone who has put in the effort and can think and is sharp and can put things together, versus someone who gets frozen without the AI being there at their fingertips.
I think it's really interesting because maybe companies won't care. I think I'm probably one of those people that would get frozen. Even when I was working, I was very bad at writing code from scratch, but if I'm looking at a file, I see all the imports, I see the decorators and stuff like that, I'm pretty good at coding that. I was kind of a copy-and-paste programmer where I'm just copying and pasting a lot of snippets and then just replacing the variables and things like that.
I guess maybe my hot take is that maybe certain things actually will be less tested. Like maybe people just won't care that much if you can actually handwrite the code, as long as you can understand. That's what I'm seeing with some of the AI-assisted assessments. It's like, "Okay, you can actually just go ahead and implement this with AI, all of it if you want to, if you're able to do that." But then the interviewer asks you, "Okay, this array of integers, what do the integers actually represent in the context of this code? Maybe it's data points on something, or it's the shortest distance between something, or whatever, right?" You have to be able to articulate that and figure that out. So I think it's interesting. Maybe I'm giving the same answer where I have no idea, but it's interesting to see the anecdotes that are happening.
Well, one other take you have is you said that personality traits you think are now more important than coding skills, or actually most skills.
Yeah, maybe personality traits isn't the best way to phrase it, but I think there's something about a person that you're hiring. They're not a machine, right? You look at the resume, like, okay, Java programmer or whatever. They're not that. I think people, especially in fields like software development, which are very open-ended, decisions matter, trade-offs matter, communication, all that stuff matters.
When I'm hiring people... I hired somebody a few months ago and they had certain skills. Obviously they were going through their CS degree; they still haven't even graduated yet. But they are far better than practically anybody I've ever hired before, including people that are experienced, including people that I probably could have hired that are working at big tech and have these really big resumes. And then I ask myself, what is it that makes this person good and another person bad, or less effective? It just goes back to the person.
I think in startups the term is agency. Somebody who's high agency, who's just going to get things done, who's never going to say no to something. I think that attitude is really important of, okay, if I don't know something, I'll just learn it. I'm not going to say that's not my job, or I'm not going to dig deep into that. Anytime I give this person a task, even if they have no idea how to start it, a week later they'll have learned everything about it. It's a completely new domain to them; they just learn everything. And I think those types of personality traits, it's hard to describe that. Maybe agency is the best term for it, but I think that matters the most, because any information that you need at this point, you can kind of just prompt, right? Like, okay, I have this programming-specific question. You can just get it out of a prompt if you know the questions to ask. And knowing the questions to ask is just a matter of, I think, putting in the effort.
Yeah, so I like agency. I'm also sensing, you didn't mention it, but it's like energy, focus, wanting to solve something specific. And this is something interesting. I've been talking to a few people who are building startups right now. Obviously, a lot of them are to do with AI, or they're building AI infra, and how they're struggling to find that product-market fit. Even though, you know, they can build faster than ever, it has not gotten any faster to get teams to adopt, and simple things start to matter. For example, talking to a potential customer in person, like going to a tech meetup, living in a tech hub or where you can go more regularly, getting feedback, getting your first customer inside of a big company. And none of these have to do with the code itself.
And of course, they created something that they think is cool and innovative and different, but there's now so many things that are similar. By the way, they all have competitors. They now need to convince them why they are more trustworthy, they're worth betting on, and so on. And a lot of it does have to do with a charismatic founder who is good at convincing people, all right, try my stuff. It actually helps.
Yeah, that's one of the things I actually learned from YouTube as well, because if you're making a video trying to explain something, nobody cares how correct you are. Nobody cares how smart you are. Nobody cares, like in the LeetCode forums, if you have this super crazy solution that's really impressive and really performant, if you can't explain it. Because what they care about is the value you can give to them, if you can speak in a way that they can understand. When I was making those videos, I would enunciate certain things more, I'd emphasize certain points, I'd repeat certain things. I just tried to make the video very digestible. Whether it's a DFS or sliding window or whatever algorithm, anybody can technically get it correct. You can at this point have an LLM just kind of spit it out to you. But I think the human part of it, just knowing people, figuring out what exactly they're actually looking for, what they actually care about, I think that's pretty important.
So YouTube is interesting because YouTube today, at least, I would hope it's mostly watched by humans, people. So every single view I would hope is a human. I'm sure there's some bots there, but Google is fighting them. And it's a real attention economy, right? Like MrBeast, who's the most subscribed or watched YouTuber, he captures more eyeballs, more people's attention, which is the currency. There's 8 billion or so, or a bit more, people, maybe fewer of them having access to online videos, but it's kind of almost a game. If it's a game, you've been pretty good at it in this niche, which is software engineering. What is something that you've learned on what works in becoming successful on YouTube, where people pay attention to you, they give you their time, which is an important, valuable currency, that might be relevant for tech companies, startups especially?
I think a lot of companies struggle with that. I was speaking to a couple dev relations people that are working on the same thing, where it's kind of a game sometimes, where it's a little bit of politicking, where, you know, it's about packaging, right? How you say things, how you present things, how you kind of present yourself. And it's also about, I think, being authentic. I think that's a big thing that companies maybe don't always get right. Even with the AI labs, like you're saying, nowadays OpenAI and the Codex people, they're on Twitter all the time. They're interacting with people. They're even interacting with people that sometimes criticize them. And I think that matters. That authenticity usually matters a lot. People can smell the fakeness. They can tell. Even for me, if I'm saying something I don't quite believe, I think it's so obvious, and people can tell. Then they just get turned off. They're not going to listen to a word you say at that point. And so it doesn't really matter what you say. You have to build their trust in a way that it's hard to build. It takes time to get there. But once you have it, it matters a lot.
It's interesting because I do wonder if Claude Code would have become as big as it has if it was not created by Boris. Boris, the engineer who you can see on YouTube channels; he was on this channel as well. He's a very relatable and, I think, humble person. At least that's how I got to meet him. He is on social media. He shares how he uses Claude Code. There's a lot of Boris. This is not just a tool by some corporation called Anthropic. No, it's actually Boris who created it, and he's working on it, and he's fixing your bugs, and you say, oh, it had this bug, and he replies; he's in your mentions. And I now notice with OpenAI, Codex used to be this thing built by OpenAI, but now it's Tibo, who is the head of Codex, and he replies and he does similar things as Boris. So I do wonder about the personal angle. And Claude Code is one of the biggest businesses in the software world in terms of revenue. I think they cost multiple billions; it's hard to track how much. So it's a huge business tied to a person.
Yeah, I hate the word influencer, but it does seem like everything is going in the direction of, even for companies, they have to be a person now. They have to be a personality. They have to...
Approachable, maybe?
Yeah, like approachable.
Relatable?
Yeah, relatable. Like a human, right? Not just a corporate figure. Even for CEOs sometimes, you know, it helps. Sometimes it does; sometimes it can backfire, but I won't name any names. Yeah, I think it's funny, and I think even some companies have that a lot. I think Meta, you probably know more about this than I do, but Meta has internal Facebook or something where, when you ship, you have to kind of...
Yeah.
Yeah, you have to show it off. You have to mention it. You have to try to brag about it. Yeah, exactly, promote it. That's a skill. I didn't expect that I'd ever be, you know, an influencer or a YouTuber, but it's a skill, and I think it's something that everybody should lean in towards. Not everybody has to do YouTube, but whether it's LinkedIn or Twitter, I think it's worth, you know, putting yourself out there and slowly forming opinions and interacting with people and things like that.
Yeah, well, you said maybe not everyone has to do it, but really, you've had a pretty contentious hot take, which was some people should just give up on tech careers. Let's talk about that. It's a pretty big statement.
It's a... It's a very strongly worded statement, and I definitely don't encourage people to give up. So I want to make that clear. The only reason I suggested that, even in the title, was that I think if you have an attitude of, you don't want to try hard, or you don't
want to do things yourself, and you don't want to dig deeper into things, like you need to do that. You need to do certain things. And if you're not willing to do that, I think you should know what you're getting yourself into, 'cause a lot of people don't know. Like they go through these college degrees, they kind of just cheat their way through it, and then they expect to have a job at the end of it. And I think you have to evaluate that if you're going to be one of those people that does that, because it might not be the best for you. People have unfortunately just gotten into the habit of doing it.
But when I made that video, I had a lot of people that were pissed off at me. But surprisingly, the vast majority of people, they said that maybe I could have been a little nicer, and I think that's true. But they actually agreed with a lot of my points. A lot of people said that, you know what, you're right. I realized I was going too far in the direction of just prompting things. I got a lot worse at it. The products, the things that I'm doing are worse now, and I'm not enjoying it as much. And it made me want to refocus on learning and being the best that I can be.
So, I think, you know, I'm not trying to offend anybody when I did that, but I saw nobody else talking about it, so I just felt like I had to do it. And I recorded it on my laptop. I didn't think it was going to blow up the way that it did. I didn't think most people are going to see it. But yeah, I left that video up even though maybe I took a reputation hit from that, I'm not sure, but I left that video up.
Yeah, but I think it goes back to effort, right? Yeah. And as advice, what would you advise for software engineers, early career, mid career, maybe even later, who are either working at a company and they just want to be seen as this awesome engineer, when you think of the standout engineers that you work with either at Google or the people who you know, or they're working at a startup. What do you think it takes today to actually increasingly stand out from a crowded space, to have your work speak for itself? What does that mean?
Yeah, I think it's a really, really good question. I think there probably is some general advice that would apply to most cases. I don't know if I can think of that. So, what I'm going to say is I think, like you said, the effort matters. Even in an interview setting, knowing your audience. It's not like you're just living in your own head taking this standardized test. You're talking to somebody. You're seeing how they're reacting to what you're saying. Maybe they're not on the same page. There's certain shortcuts you can't take. If you're in a team, you're at a company, know the people around you. Know what they care about. Ask them questions. Have meetings with them. Don't just make assumptions if you don't have to. Talk to them, figure out what's important, get a sense of things, and then go very hard in the direction that you think is correct. Maybe you'll have to recalibrate things. Maybe you'll go too far. Maybe you'll make some mistakes. But I think it's just kind of that iterative process of that feedback loop of, okay, figure out what you're supposed to be doing, and then work very intensely to do that, and then just keep doing that. It requires a lot of changing. It requires a lot of course correction. And that's difficult. Nobody wants to do that.
One thing I always did with my manager, I always asked them, if you have feedback for me, please tell me. I will not get offended. I want to know. I want to know what I could be doing better. And the way all my managers ever reacted to that is they were very surprised. They're like, well, first of all, if you just joined the company and you're asking this, that's a very good question to be asking because that tells me that you actually care and you actually want to get ahead. So, I think that aspect of it matters a lot, 'cause then people know you're on the same page. They kind of know about you. They don't have to guess what you're thinking in your head. You're kind of communicating that with people.
Yeah, so I felt coming through our conversation is we just keep coming back to it: effort. And don't take the shortcuts. I mean, take the shortcuts when you have a business outcome, especially when you're building your business or you have a goal that you're going to achieve, but otherwise just put in the work.
It sounds simple. It sounds really easy on paper, but it's hard to put into practice. Sometimes, especially for me, I am not a person that likes change, actually. I am very resistant to change. I hate change. It takes me years to change. But
You still have Angular on your website?
Yeah. But it's so important and it's so worthwhile when you actually do it. And I think it just matters a lot and it becomes a way of life. I put in a lot of effort on the coding side and then in professional life I realized, okay, the soft skills matter a lot. Took me a long time to learn them. I'm still learning them to this day, but that's the reason why I probably got promoted. That's the reason why my team liked me. And it's important to be likable. You don't want to be hated.
And as closing, what are places that you get inspiration from? This could be books, this could be videos, this could be YouTube channels.
Yeah, I think you just had Martin Fowler on. I'm a huge fan of him, huge fan of his book because he goes deep. And even as deep as he goes, then you'll have a hundred references at the end of every chapter. And I just love that because I'm the type of person, I just always have a follow-up question. I always want to go a little bit deeper to understand things. And so, seeing people like him, I relate more to scientists, people like PhDs, researchers more than I do to engineers. So, I just really like that. I think it's important to have people that you can look up to and aspire to be like. And I think there's plenty of people I take inspiration from, including other YouTubers, including technical people, including people I've worked with in the past. And I always look at a person and I try to see qualities about them that I really like and then I try to replicate them and imitate them as well.
Neet, it was awesome to have you here, especially in person.
Yeah, it was great. Great meeting you.
I'm glad we finally got to record this episode with Neet. I love how honest he is and I hope this came across as well. I found it interesting how Neet hires these days. He runs one of the biggest coding preparation sites and then he hires for skills outside of coding. He cares about motivation, whether the person can explain their own thinking, and most importantly, for agency or for getting things done. It was also nice to talk with him about how he believes that companies have no idea how to evaluate candidates and they probably never did. The LeetCode style interview survived not because it predicts job performance, it just doesn't, but because nobody has found anything better that scales. And finally, I appreciated Neet's observation that the effort is becoming a differentiator exactly because AI has made everything else cheap. Anyone can prompt a design, a feature, or an answer, but what you cannot prompt is caring and your ability to defend your choices when someone asks, "Why did you do it this way?"
Do check out the show notes below for the related Pragmatic Engineer deep dives that go even deeper into tech interview related topics. If you've enjoyed this podcast, please do subscribe in your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and see you in the next one.
Article published