Speaker A: 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.

Speaker B: 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.

Speaker A: 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.

Speaker B: You've had a pretty contentious hot take, which was some people should just give up on tech careers.

Speaker A: You should know what you're getting yourself into because...

Speaker B: What separates strong engineers from everyone else? Neet Dhiman Singh, or as many call him Neet, he created NeetCode, the coding preparation platform that helps countless devs get hired at big tech. In today's episode, we cover what preparing for data structures and algorithms interviews 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...

Speaker A: If you want to understand which entering 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.

Speaker B: 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 Sear AI agent, which helps investigate production errors. For example, here's an actual error I had in my application. I can just ask Sear 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.

Speaker A: One place that I find even more handy to use Sentry is from code X or cloud 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 as a 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.

Speaker B: Neat. 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 if and when AI will be good enough to like write code, you know, coding interviews will be dead because uh 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?

Speaker A: 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 like talk about them changing a lot and so far they're kind of like changing a bit with like 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 like we've gotten to a point where you can ask like 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 uh do anything pretty much. And it might not get 100% of the way there like even humans can't write bug-free code but it can get at least 90% of the way there like pretty close. So it's confusing to a lot of people and I think that it goes back to like how do you even evaluate if somebody's a good hire or not there's one aspect of it which is like 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 like does that skill translate to what you're doing on the job? It never really translated to that. It was more about evaluating like does somebody think? So I think that's one of the reasons and the second reason that's stayed sticky is that companies just have no idea how to evaluate like and they probably never did. I think I was talking to a friend of mine Steve from Amazon and he mentioned that like they've run some studies and it's like very hard to know like whether somebody like when you hire somebody no matter how much data you have no matter how like you've run the interview process that it's just very hard to know like how somebody's actually going to perform on the job.

Speaker B: If if if they're going to work out right?

Speaker A: 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.

Speaker B: And could another reason be that it has been so sticky and it's still a sticky that maybe it's just simple as there it's kind of like if it if it ain't broken don't fix it type of mentality?

Speaker A: I think so because anytime you try to change something you risk making it worse and so it's like first of all it's a lot of work to change that process at big companies like 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 cuz it's like Interviewers are just not good. Like the most Interviewers do not like interviewing. They hate it.

Speaker B: When you're saying training, you mean interviewer training, like training your interviewers like at a large company like a thousand of them to like be similar.

Speaker A: 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 like more variables introduced, like a new evaluation process, training interviewers differently. Now you got to check the AI prompts, like all these variables. And so, it's not like an exact science. It's hard to measure these things. It's It's practically impossible. So, I think we're definitely going to see, I think, 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.

Speaker B: I want to rewind a lot back into your early days. Like how did you get into tech? What was your first introduction with programming coding?

Speaker A: 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 Some of them obviously do, but a lot of programmers don't. But they really like programming. And so, when I got into our 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. Like 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 kind of concepts. And then it really like something just kind of clicked where it's like initially, programming felt kind of boring. It's like you just have variables and numbers. But then when you introduce all these things, then you realize there's like this infinite complexity that can be introduced. And and you see that with like all the software that is built today, where it's like you took these like simple primitive things, these zeros and ones, and all of a sudden you just have this enormous like universe of software solving insane problems. You have databases like Google Spanner, which not only take programming, but they take physics, they take like atomic clocks and GPS systems and all these things, and they solve like these really hard problems. And so, I guess to go back to my story and well once I really started enjoying programming, I just fell in love with it and I was like, "Okay, I'm going to 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. Like 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 it's like you don't get to work on the languages that you like, the problems that you enjoy solving. You have to focus on like the business problems. And so, yeah, I I 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, you got really excited it was boring, and then you got excited about the complexity and the possibilities, and you kind of came back to down to earth. One thing we were just talking about before we started the podcast is the CAP theorem. On how you also had a similarly weird relationship with it. Can we talk about it? And also for those of us those listening who who don't know exactly what the CAP theorem is. Let's start with that.

Yeah, of course. Uh so, it's a pretty simple theorem. It's kind of described awkwardly sometimes, where it's you have like three choices, and you can pick two of three. There's consistency, uh and that's data consistency, so in like a distributed system where you have data that's like partitioned in different regions or something. It can go out of sync. Like one database might be more up-to-date than the other. And then there's availability, where are both of these uh you know servers or databases available to read or maybe one went down. And then the third one is a 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 the 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 like 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. Like 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 like what was happening. And so CAP theorem felt like hand-wavy to me and I didn't really like that and that that goes back to why I don't like certain things about working on the job because I think like 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 like technically right but maybe he's you know being a little little bit nitpicky and I think that's like a personal preference but I just felt very validated that somebody like him agreed with me and I think it's it's kind of funny because I think I never saw anybody mention that about CAP theorem before like I saw like posts on Stack Overflow nobody really mentioned it's kind of incomplete. And so the thing that came after it is like PAC else which is like 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 more simple to understand.

I wonder if it's only a smaller subset of people who actually go deep. You know, CAP theorem, you actually like, all right, let me understand the whole thing and then you realize it's incomplete. But most people might have just like looked at it, you know, took it, okay, it's the law, two out of three, simple enough, move on. And I guess in in most part of their lives, it's enough or they might not even use it or if when they they think they know, but they don't know it exactly. So, it's interesting cuz 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 like solving the business problems and just like this is what I didn't like when I started working professionally because okay, so you go through like documentation, right? You're going through onboarding. Like at Google, there's so much documentation, there's so many internal tools. And I want to go deep. Like I want to do depth-first search on all of the document links. Like, you know, you have one blog or you have one site and it has it references like five others. That one is going to reference five others. Like I want to go through every single one, have like a complete understanding of everything. But that's just not how it works at jobs. Even a code base, no one is going to understand this massive code base unless you like 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 like agentic coding because it's kind of a similar concept where it's like now you might not even be looking at the code that you're actually producing yourself. So, it's it's kind of similar and I think this whole transition kind of reminds me of that where it's like you don't get to do some of the things that you used to enjoy, but it's it's still you know, that's that's life, [snorts] that's business.

So, you graduated from University of Washington and you started work at the most obvious choice in Seattle. I guess the in Seattle the two obvious choices are Amazon or Microsoft and you got into Amazon and it should have been a smooth ride. Like you 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 I 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

Speaker A: 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 it was I think they use chime at the time, but he said, "This feels like a thankless job." And I was like 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 a positive team environment right now."

Speaker A: 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 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 like a little bit of a relief, but then I just felt a lot worse because I was like, okay, now what do I do?

Speaker B: And then can you tell 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 were just were like not adding up?

Speaker A: 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?

Speaker A: Yeah, and 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 unmarked 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.

Speaker B: 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 like they accept the resignation even after like the second time?" I was thinking like maybe this is like 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 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, it was it was 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.

Speaker A: Later on, you were able to get into Google many months later. How did joining Google feel compared to Amazon?

Speaker A: 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 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 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 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 uh 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 that 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.

Speaker B: This is so interesting because you've only at that point had maybe 2 months of professional experience working at Amazon when you joined 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 they when they join, it it can be hard for them to adapt to the company. Yeah, I'm not sure we think about this in the industry.

Speaker A: 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 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

Speaker A: 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. Uh but slowly like while I was there, it slowly started to get going that direction, especially with the layoffs and all that.

Speaker B: 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?

Speaker A: 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 vast majority of people are reasonably smart enough. I think it's 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.

Speaker B: 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 for you or even your voice from there. Can Can you tell me how that all started and how it continued as you were working at Google?

Speaker A: Yeah, so I initially started after I quit Amazon, I think, in like 6 years ago. And I was doing it really just for fun and for the love of the game because

Speaker B: You were recording videos, right?

Speaker A: 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 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 uh 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 you you 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 a like I'm at Google now for the rest of my

Speaker B: You didn't have your yes.

Speaker A: Yeah. And then I 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 and funny enough, after that, the channel like went exponential because I 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 it's like the best sales pitch in the world. Like I 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 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 um 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 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, uh thankfully it's like worked out so far.

Speaker B: 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 could 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 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?

Speaker A: Yeah, I thought about that a lot because even though I 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

Speaker B: Well, I mean, I think a trend that in like we always live in bubbles, right? But but but in in like certain bubbles it 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 was still coding. And now you're like okay, you have the website, you have Git repository. What What was the switch like? And and you're like

Speaker A: 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.

Speaker A: 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 have been a lot of companies that have been started just because like some that you had at 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.

Speaker A: What about like you went from from working on a team and now you just had to do everything by yourself. What was that an issue or that was kind of natural to you? >> Yeah, that was actually a huge thing for me where I It was hard to build a team. It was hard to like work with people.

Speaker A: >> Yeah, that was actually a huge thing for me where I 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 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 you like when it works. Like when you're an effective leader like you can make a magnitude of difference in like 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.

Speaker A: >> 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. Uh what did you build and what what was the tech stack behind it?

Speaker A: >> Yeah, so initially when I made the free site I was still working at Google. So I just chose some like random Google tools. Uh I was using Google Cloud Firebase uh 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 um 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. So like 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 like I 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 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.

Speaker A: >> the video was is the product or 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 and I 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 like tech choices I made, the 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. 我认为这个视频是产品本身，还是大部分产品？ >> Yeah, because it's education. So it's like if the education is bad, then nobody really cares. And and I 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 like 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.

Speaker A: 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 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. 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.

Speaker A: >> What what's the story? >> So I have this service that I was paying like 3,000 a month for service and then I think late last year early this year when like the AI vibe coding stuff went really crazy, I was I was new. I could probably write my own version of this service.

Speaker A: >> What service was it? >> It was like for code execution. And so I thought like probably I could write my own version of this for like 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 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 to vibe coding coding uh 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.

Speaker A: 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

Speaker A: 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.

Speaker A: I also want to mention our presenting sponsor Antithesis. Neet talked about memory leaks in a series that he knows about but just doesn't have the time to chase it 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.

Speaker A: 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.

Speaker A: And with this, back to Neet and his story on why he's happy leaving a production bug unfixed.

Speaker B: It's an interesting trade-off where like engineer 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 like a couple people doing it. So it's like I 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.

Speaker A: But this is so interesting. So, you paid for an engine or or licensed it that if I understand it it was executing code, right? So, when people like type out stuff in in your editor, it runs it and you can check it it can like run your problems as as other solutions. You used with 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 and now you have this quality regression, but it it doesn't make a huge difference to the thing. But I want to push you on this. Like do you not think this 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 and then again, it 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.

Speaker B: 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 couple 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 I like I initially tested it. I was only sending like a small amount of like 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 would have 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 the servers will go one one of the services servers will go down, but then it just like 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 I I just see that like nobody cares. Like, no user has mentioned anything about that to me. It's better now.

Speaker A: So, so yeah. So, I guess maybe to look at a bit better is is it's overall like better because it's cheaper, it's faster, and yeah, there is of course, there's trade-offs. Like, within engineering, there there is now a regression that crashes one of the servers. So, you run an additional one. You have like replication if if you will. And it's still cheaper overall. So, like overall as as you package it, it's better than before. Boom. Like, it is kind of a obvious business decision. And like I guess in engineering, like you there's a question like how perfectionist you need to go when a problem is already solved and is good enough.

Speaker B: 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.

Speaker A: Let's talk about this, the how like as especial 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 NEET code in order to get into big tech, you know, they you first you need to 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 but but the actual the other things that you you gain by by preparation.

Speaker B: 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 I left. And then so, for that like year before I got into Google, I was really just doing NEET code. I was 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 I think like in terms of just regular like raw coding and coding experience, I was probably sub par 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 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, like I do think I've gained a lot from algorithms and data structures in terms of like just thinking. Also on

communication side. And also on the trade-off side, which I think is really what engineering is about. And it goes back to like what people are experiencing with like agent to coding and stuff. Everything is a trade-off. It's not really 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 like the memory leak issue with my service, right? It's a trade-off. Like, 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 like missing nowadays where they're focusing maybe too much on the hard skills of like, "Okay, like can I write this loop? Do I know this particular data structure? Do I know like all these little things?" When I think they're forgetting to like zoom out and look at the bigger picture of like 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 like one domain to another or really smart person like going from one to another and you you you see that and you think like what do they have that other people don't? It's usually not some like very specific skill that like they know this programming language super well. It's usually something related to that like it could be whether it's a data structures and algorithms or like some hard skill. It's like what you gain from that in general and I think that's like education in in general as well where like you go through like 20 years of your life learning about all sorts of subjects and that like molds you in a way that's very hard to articulate. It's very hard to be precise about like what exactly did you gain by like 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 like solving problems that are maybe abstract or not for a specific thing, they add up over time?

But I I'm going to push you a bit on that. Like is is is it Is it really systems thinking, or is it being learning a domain? Because systems don't exist in a vacuum, you know? You will have agricultural systems that are very specific to how the agriculture industry works. You will You will have If you're in a legal industry, like it is based on whatever country you're operating in. If If you're in a legal tech startup and healthcare, a healthcare tech startup looks very different in the US versus like the UK versus in Romania, etc. The people who are who are great system thinkers in one domain often are are they just really understand the domain. And you know, payments is one example where I worked in, which is very interesting complex Once once you get into it, like people start to move around in it because you go there. So, I wonder if it's There's There's There's abstract level system thinking, but there is also becoming a domain expert. And somehow they kind of overlap as well cuz 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 system thinking as well.

Yeah, no, I completely agree with that. And I think for me it's definitely hard to like quantify and articulate because it's very kind of like vague and I think you're definitely right though that like the skills, the the hard skills, like the knowledge and like the details of like certain industries and things like that that definitely matters. But I don't know. I guess like when I think about it, I think of it maybe you know people like this as well. Like there's certain engineers that are like they could go from one domain to another and you just trust them. Like you just know from working with them they're smart. Like they think in a certain way where like they could go from payments to like some completely other industry, real estate or something. And there will be like that learning curve for them. But some people for whatever reason they 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 like 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 that like oh, it was a waste of time to learn this subject cuz I didn't actually use like those details on the job. I think that's wrong way to think about it. And I think that's what a lot of people are doing now with AI. Like hey, what what if I'm not going to be writing for a loops a couple years from now. Um I don't think those things are a waste of time.

It sounds like it sounds like you're saying that it's 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 at Fang and companies the the big tech companies. A lot of people are using NEET code to prepare for these interviews. You're getting feedback from them of you know like they will they will write to you when they succeed or they will write in frustration after many months they haven't. So you get a bunch of signal here. What are you seeing in terms of the just the algorithmic part, you know, the coding interview? Like are things staying the same, getting harder, getting easier?

In terms of the format, like especially like at the early levels like juniors and stuff, it's still a lot of like algorithms and data structures, the format itself. I've definitely seen, I think, anecdotally, like people are mentioning that it's getting harder. At the same time, from the people who do pass the interviews, they still, like at

Speaker A: 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 countries. Like, you'll see like some some countries, like India, it's very different. Everything's pretty much algorithms there. It's like leak code hards and super hards and stuff like that. But, in the US, I don't think it's that crazy, but it's uh yeah, it's not too crazy.

Speaker B: Yeah, but I I I guess like, you know, going without a without any support like in a whiteboard, it's so it's so hard to prepare for that. It it it's it's never been easy.

Speaker A: Yeah, absolutely. And I think the the one thing that's happened a lot is people like there's been cheating tools for interviews. And so, we've had like yeah, mostly remote interviews for the last like 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.

Speaker B: What are interview formats that you're seeing, you know, where we're talking about other companies, especially smaller ones, experimenting? What are interview formats you're you're seeing or you think it they're actually kind of promising? Like, if you were running a small smaller mid-size company, you might actually consider instead of the And I you're talking about against yourself here.

Speaker A: 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 like hire somebody who's who's an intern and you saw how they performed. And what I've spoken to a lot of companies about the last week is that there a lot of small companies that can get away with it are doing like trial periods. It could be a few days. It could be like 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 hire 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've, believe it or not, have leaned in that direction where I can get a sense of somebody's lead code abilities pretty quickly. Like I'm not going to spend four interviews going through and asking somebody data structures and algorithm 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. Like can they think through tradeoffs? I don't even care about what answer they give me to a problem. I care about like what's like why did they say that? Like what what can they say? Is it just something that they like saw in like a ChatGPT prompt and are just regurgitating it or can they actually like talk through it? And and then when you look at like the work that they're doing, same thing. Like I ask them about it. Like why did you do it this way? Like what what what's good about this? Like what's bad about this? What could be improved? And I think it's a hard format to like scale for big companies. That's why I don't think that that's what's going to happen in terms of like 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.

Speaker B: Yeah, cuz you're you're basically people are doing the work and it doesn't matter what tools they use. In fact, if if now everyone's using, you know, like 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 one 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 you know, the conversation will probably be more of a soft skills conversation cuz like yeah, we're seeing your work. Like you've been selflessly pushing features to our our product. Awesome. And I guess that's kind of the upside of open source.

Speaker A: I think Dax mentioned this because I was speaking to a bunch of people that like work with him that that they just got that they were either like contributing to open code already or Dax like 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 they're like and he's like, "Hey, would you be interested in working?" And so they already had this work that they could showcase and it's like if you if you're doing things in public uh people can get a pretty good understanding of like how you work.

Speaker B: Speaking of how you work at Neatcode 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?

Speaker A: 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 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 like pro AI they're like, "Neatcode, you changed. Like what happened? Like now you're an AI shill." But it's not. Like I just try to be pragmatic about it because I think before I was still using the tools but they just weren't as good. And now they've gotten to a point where the work that I'm doing which is mostly CRUD, usually there's not that much crazy interesting stuff other than like the code execution service. That's probably the most interesting one. But I'm using like 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 pretty it's a little bit outdated at this point. I'm using Google Cloud and TypeScript. But I would say initially actually like 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 like 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 like this like 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. Like it can clean up a lot of like 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 like you might make the wrong decision, but even if you make the wrong decision, you can go back and then try to correct it just kind of by thinking about it.

Speaker B: He sends a post a bunch of her hot takes on social media as well. I don't know if it's like a 2:00 a.m. thing or But well one of them you said is as I'm quoting you, and now in 2026, it's never been easier to build things, but I would say that it just makes 10 times harder to actually build value.

Speaker A: 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. Like 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 like features, like a website like you can just throw features in there nowadays that nobody really cares about and you can 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

Speaker A: 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 it 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 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

Speaker B: 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 they're just almost at 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 but still like I guess this truth did not change because of AI

Speaker A: Yeah, it's funny because even OpenAI they did like Sora 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 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 this uh 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 they're refocusing now and trying to maybe slow down a bit

Speaker B: This is a bit contradictory though like we're we're 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 like I think even the 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.

Speaker A: 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 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're if you just have the skill set of like designing things. Uh but 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 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 UX is about. It's not about like how pretty something is. But, I guess in all in all fairness, right? Like, this was a contest

Speaker B: Yeah, 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 the more 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 I guess what you're seeing is you're getting a lot of low effort submissions. Uh and you're seeing there's like not not up to par.

Speaker A: 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

Speaker B: Well, you live and learn. But, but I guess it 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, I 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 uh 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 I told them like what criteria I actually cared about. And uh I think, you know, some people just didn't follow the directions or whatever, and that's that's fine, I guess

Speaker A: One of your hot takes from a few months ago, the end of coding as we know it. Let's let's talk about it. Uh Tim O'Reilly wrote a blog article that about a year ago where where he predicted that that things would change, and you were reflecting on that

Speaker B: Yeah, I think it's been really

回顾与未来展望：编程、AI 与商业模式的演变

Speaker A: 有趣的是，很多人真的不常回过头去看实际情况。他们只是向前看。但我认为回顾一下事情是如何发展起来的非常重要，因为这可以帮助你预见未来会如何发展。而且，在代码变化和模型变得越来越好这一点上，这很有意思。但同时，我有点惊讶的是，我们仍然处于一种非常观望的状态。比如，公司仍在进行裁员等等。但在很多方面，情况并没有像我预期的那样发生太多变化。我的许多大科技朋友现在编码的方式完全不同了。但在商业运作方式方面，他们做的事情是相似的。大多数人仍然没有被裁掉。大多数人仍然在工作。他们比以前做了更多的工作。而且我认为公司有时会意识到，他们可能已经朝着人工智能的方向发展得太远了，所以他们试图重新平衡。这仍然是一场权衡的游戏。它仍然是一场“快速行动并打破现有事物”的游戏。

Speaker A: 我认为编程绝对会继续发生根本性的变化，你懂的，可能成为一个完全不同的领域。但对于商业方面的一些事情，了解生产价值以及工程决策中的权衡，这些东西是绝对不会消失的。我从来不这么认为。因为你可以让大型语言模型（LLM）来为你衡量权衡吗？我认为这是一种非常人性化的东西，用来评估工程中真正重要的事情。

Speaker B: 是的，还有比如，你知道在编程的时候，当你思考我们写什么代码时，你需要构建一个功能。你需要知道任务是添加一个按钮，我不知道用户点击它的时候会发生什么，它会不会提交投诉之类的。这很简单。但实际上，点击“提交错误报告”这个简单的操作背后有很多边缘情况。它会检查状态。你需要知道上下文是什么，还有要说什么，什么样的用户是免费用户，付费用户？所有这些边缘情况、条件、领域、商业领域的所有这些东西都被捕获在代码里了，这意味着它们被捕获在你脑子里。但现在你正在提示它时，上下文仍然在那里，而且有人需要知道这有多重要。

Speaker A: 是的，我认为变化是唯一没有变化的，因为变化只是不断发生。我不是想用这个词来玩双关语，但我昨天或今天看到微软正在进行自愿裁员，他们是买断协议。基本上，如果有人选择离开公司并获得一些遣散费。我查过，虽然我还没有确认，但我问了一个朋友，他说这是真的。这些买断协议是真的，但还没到年龄限制的时候。但基本上，他们只向特定年龄和特定工作经验的人提供这些优惠，这有点好笑。比如，如果你是某个特定年龄，我不知道确切的年龄，在微软工作了10到15年，他们只向这些人提供，我认为推测是因为那些人不太容易改变，不愿意学习一种完全新的做事方式。所以微软向他们提供，因为现在他们必须朝着新方向发展。我想当萨蒂亚最初接手的时候，他们做过非常类似的事情。我不知道当时是自愿的，但他们做了大量的裁员。主要是针对

Speaker B: 那那不是自愿的，2014年是这样。是的。那主要是针对很多有经验的人，特别是那些新员工不是。所以我想仅仅愿意改变，愿意以你没有享受的方式去做事情，比如我加入谷歌的时候，不得不做一些比我期望的更深入的事情。我认为这会非常重要。

Speaker A: 是的，你确实说过，你认为程序员或编程不会消失，即使编程发生变化也是如此，对吧？是的。我认为甚至到这一点，这就像是无法猜测。我的猜测和任何人的猜测一样好，但我就是看不到去思考消失。我看不到问题解决会消失。我认为它将发生剧变。有可能我们需要更少的程序员，但这种情况还没有发生过。比如每次出现重大的创新，比如云计算、更高层次的编程语言，无论出于什么原因，事情都不会导致程序员减少。而我本来期望是这样的。比如当你拥有可以解决那些非常困难的问题的云服务时，比如谷歌曾经不得不努力解决某些分布式系统问题。现在你可以直接使用AWS或GCP，让它为你处理好一切。所以你会认为我们拥有无限的软件，我们只是在做所有事情，一切都很容易，而且我们不需要那么多程序员，但这种情况还没有发生过。基于这一点，我不知道。比如你看到Replit和Lovable，现在任何人都可以成为程序员了。所以我不知道这是否是我们前进的方向，虽然它非常非常高层次了。

Speaker B: 但这非常有趣，因为一方面我们拥有这些越来越强大的基本组件，比如云计算。你会认为AWS、Azure和GCP、Oracle之间的组合是存在的。所以价格显然会尽可能低。但然后，你可能会遇到像DHH这样的人说：“好吧，我们在AWS上。我们每年花好几个百万美元。你知道，把亚马逊的服务去掉，然后在本地做。”而每个人都认为这会很贵。他们确实这么做了，现在他们正在进行大规模的节省。所以，这些抽象层运行起来几乎变得越来越昂贵了。这对大多数人来说没问题。但当你达到一定的规模时，你可能会开始投资软件工程师，构建自己的软件并维护它来降低成本，就像37 Signals所做的那样。所以我不知道在某些规模下，是否总是有价值，比如自己搭建你的技术栈，或者比你从预构建的东西中获得的东西更低一个级别。

Speaker A: 是的，我想是这样。我一直对事情如何发展感到有趣，比如从长远来看。工程不是一个科学。它有很多文化融入其中，你有一些公司在云方面，为什么MongoDB会变得这么大？我认为技术可能只是其中的一小部分，但我认为销售、营销和文化才是大部分。如果一家公司使用它，它可以滚雪球，然后整个行业开始使用某种工具。然后他们可能会意识到我们朝着不需要所有东西都在云的方向发展太远了。这并不更好。它并没有给我们节省那么多钱。而且有些方面，我们看到云计算服务变得非常复杂。现在是云驱动开发。你拥有所有这些东西，就像“好吧，你解决了这个问题，现在又遇到了一个新的问题。”有了LLM也是一样的。即使是AI的成本问题，一旦补贴开始运行（我们开始看到这种情况），我认为这将是一个非常大的问题，也许所有那些拥抱AI编程的公司现在都将减少它。

Speaker B: 是的。你有一个疯狂的火车（指技术发展）。

关于AGI的讨论与技术进步的哲学思考

Speaker A: 我想谈谈这个话题。它涉及通用人工智能（AGI）。我不是AGI的狂热粉丝，因为我觉得谈论它非常像……你知道，很难定义。但是，让我们来谈谈它。假设存在一个AGI或者一个神一样的奇点。这些模型会非常了不起，我认为我们可以看到它们有局限性，但让我们向前跳跃一下。我们一直在追逐它？

Speaker B: 是的，从哲学层面来说，感觉就像你试图达到无穷大，而你离它越近，你就离它就那么远，对吧？而且我觉得随着技术变得越来越好，你会觉得我们已经解决了生活。比如，我们有大量的资源，如果我们不想要的话，我们离每个人都有足够食物、水和住所的距离并不远。但生活某种东西，也许是人类的本性，或者某些东西就是不会改变。你想要更多，好吧，现在有了更高层次的编程。所以现在人们是在更高的层面竞争，而且随着它越来越高，人们仍然会在某个层面上竞争。比如，现在可能很容易构建一个应用，但营销和边缘情况以及这类事情将是需要解决的新问题。

Speaker A: 但我也认为这可能是一个政治问题，因为我认为存在我们都应该为技术进步而高兴的技术。如果人工智能变得越来越好，如果它在某些方面真的取代了所有工作，那将是件好事，因为现在你可以做以前做不了的事情，比如农业。当那些消失的时候，很多人都很伤心，我肯定如此，但这对我们来说是一个净收益。我认为唯一不会是正面的原因是因为如果你生计取决于它，而且政治上你知道你不能赚钱，政府也不会照顾你。我认为问题就在这里。这更像是一个政治问题而不是一个技术问题。

Speaker B: 是的，但我有一个有趣的观察是，当我们看到人工智能可以变得更好时。我仍然在等待软件能够让税务对普通人来说更容易申请。为什么我在我生活的每个国家，我都需要雇一个会计来申报我的税款，即使我的税单并不复杂？还有，我们谈论公用事业，当你的管道坏了，当你需要找水管工的时候。所以有一些日常事情上，我欢迎软件让事情变得更简单，但我过去没有看到太多进步，比如15多年了。而且现在连有了AI也不是。所以，我可能会是一个很好的触发点来看到那些事情的改进。

Speaker A: 是的，这很有趣，因为如果你看看历史，我认为我一直理所当然的一件事是进步总会发生，而且事情总会变得更好。但如果你看看历史上数千年的大部分时间，事情并不总是变得更好。有时你会看到文明变得非常伟大，然后它们就崩溃了，很多技术也随之丢失了。我不认为事情是预先注定会持续不断地变好的。我认为政治和政府方面将会有很多决定，政策将会被制定出来，我认为那将对人们的生活和他们所关心的事情产生非常大的影响。

Speaker B: 你提出的另一个观点是，过度炒作AI工具只会制造垃圾并侵蚀人们的技能。

Speaker A: 是的，我认为很多人，特别是学生们，不幸地通过大型语言模型（LLMs）学习了一切。所以很多东西并不是真正的学习。他们只是在作弊，他们只是在做所有这些事情。然后他们会失去很多技能，我个人认为从长远来看，那将非常有趣，因为我们正在看到这种情况，甚至对于经验丰富的程序员也是如此。我有一个朋友告诉我他现在正在为面试做准备，但他几个月来没有手写太多代码了。所以现在对他来说很难重新投入到那个领域。

Speaker B: 是的，这会是一个更长的时间框架，但我怀疑这是否会是这个副作用之一：更多的公司将进行面对面的面试，因为你消除了任何AI辅助。你可以真正和一个人交谈。然后面对面，你可以真正区分一个投入了努力、能够思考、敏锐并且能够把事情整合起来的人和一个在没有AI在指尖上的情况下变得僵化的人。

Speaker A: 我觉得这真的很有趣，因为我认为也许公司不会在意。我可能就是那些会变得僵化的人之一。即使在我工作的时候，我写代码的能力很差，但我如果看一个文件，我会看到所有的导入、装饰器等等。我在这方面相当擅长编程。我以前有点像一个复制粘贴程序员，我只是复制和粘贴很多代码片段，然后替换变量之类的东西。我想我的观点是，也许某些事情实际上会变得不那么重要了。比如，如果你能写出你理解的长度的代码，人们可能就不太在乎了。就像我在一些AI辅助评估中看到的，他们会说：“好吧，你可以直接用AI去实现这个，如果你愿意的话，如果你有能力做到这一点。”但如果面试官问你，“好的，这个整数数组，这些整数在代码的上下文中代表什么？比如它们是某个东西上的数据点，还是两个东西之间的最短距离，或者其他什么的？” 你必须能够阐述出来并弄清楚。所以我觉得这很有趣。也许我给出的答案和我没有想法是一样的，但看到正在发生的轶事很有意思。

Speaker B: 嗯，你有一个观点是，你认为个性特质现在比编码技能更重要，或者实际上大多数技能都更重要。

Speaker A: 是的，也许用个性特质来表述不是最好的方式，但我认为你正在雇佣的人身上有某些东西。他们不是机器，对吧？他们不是“好吧，你看简历，Java程序员什么的”。他们不是那样。我认为人们，尤其是在软件开发这样的领域，非常开放，而且决策很重要，权衡很重要，沟通等等，所有这些都重要。当我招聘时，我几个月前雇了某个人，他有一些技能。显然，他正在通过他的计算机科学学位。他甚至还没有毕业。但他比我以前雇过的任何人都好得多，包括那些有经验的人，包括那些我可能可以雇佣的、在大型科技公司工作并拥有这些非常大的简历的人。然后我问自己，什么让这个人变好而另一个人变坏或效率低？这都归结于那个人。我认为在初创公司中，“代理”（agency）这个词是“高代理”——一个能把事情做完的人，永远不会拒绝任何事情。我认为这种态度非常重要：如果我不知道某件事，我会去学它。我不会说“这不是我的工作”或者“我不会深入研究这个问题”。每当我给这个人布置任务时，即使他们不知道如何开始，比如一周后他们就会对它所了解的一切都学到。那是一个完全新的领域。他们会学习所有东西。我认为这种类型的个性特质很难用语言描述。也许“代理”（agency）是最好的术语来形容它，但我……

关于信息获取与产品市场契合度

Speaker A: 重要的是任何你在这个阶段需要的信息，你可以通过提示来获取，对吧？比如，我有一个特定的编程问题。如果你知道该问什么问题，你就可以从提示中得到答案。而知道该问什么问题，只是付出了努力的问题。

Speaker B: 是的，我也有感觉到你没有提到这一点，但它就像是能量、专注力、想要解决某个特定问题。这很有趣。我一直在和一些正在构建初创公司的人交谈。显然，他们中的许多人都在做人工智能或者构建人工智能基础设施，以及他们如何努力找到产品市场契合度。即使如此，你知道，他们可以比以往任何时候都更快地构建，但要让团队采用也变得没有变得更快了，简单的事情开始变得重要。例如，亲自与潜在客户交谈，比如去参加技术聚会，住在科技中心或者你可以更经常去的地方，获取反馈，在一家大公司内部获得你的第一个客户。而且这些都没有与代码本身有关。当然，他们创造了一些他们认为很酷、很创新、很不同的东西，但现在有太多事情是相似的。顺便说一句，他们都有竞争对手。他们现在需要说服他们为什么他们更值得信赖，他们值得冒险，等等。这很大程度上取决于一个有魅力、擅长说服人的创始人。

内容表达与价值传递的艺术

Speaker A: 是的，这也是我从 YouTube 学到的另一件事，因为如果你在制作视频试图解释某事，没有人关心你有多正确。没有人关心你有多聪明。在代码论坛上，人们并不关心你是否有一个超级疯狂的解决方案，那真的很令人印象深刻和很有效，如果你不能解释它的话。因为他们关心的是你能为他们提供什么价值。如果你能用他们能理解的方式说话。当我制作那些视频时，我会更清晰地表达某些事情，我会重复某些内容。我只是想让视频非常易于消化。无论是一个DFS还是滑动窗口或者任何算法，技术上任何人都可以把它做对。到这个地步，你现在可以让一个LLM直接吐出来给你。但我认为它的人性部分，就是了解人们，弄清楚他们到底在寻找什么，他们真正关心什么，我认为那是一件非常重要的事情。

关注度经济与个人魅力

Speaker B: 所以 YouTube 很有趣，因为今天的 YouTube 至少我希望它大部分是人类观看的。所以，我希望每一个观看都是一个人类。我确信那里有一些机器人，但谷歌正在与之抗争。这是一种真正的注意力经济，对吧？就像那个最订阅或观看最多的 YouTuber Mr. Beast，他捕获了更多的目光，更多人们的注意力，而注意力就是货币。有八十亿或者更多的人，也许在线视频的访问权限的人更少一些，但这有点像一场游戏。如果你在这个领域——也就是软件工程中——做得很好，你已经很厉害了。你在 YouTube 上学到什么能让你成功的地方，让人们关注你，他们会给你时间，而时间是一种重要的有价值的货币，这可能对科技公司、初创公司尤其相关。

真实性与建立信任的难度

Speaker B: 我认为很多公司都在努力解决这个问题。我一直在和一些在做同样事情的开发者关系的人交谈，那里有时有点像一场游戏，有点像政治斗争，就像是包装、对吧？比如你如何表达事情，如何呈现事物，如何呈现自己。而且我认为建立真实性也很重要。我认为这是公司可能没有正确处理的一个大问题。有时候他们甚至会和AI实验室一起做，你是在说现在OpenAI和Codex的人都在Twitter上。他们正在与人互动。他们甚至在与那些有时批评他们的人互动。我认为这很重要。因为这种真实性通常非常重要。人们可以察觉到虚假。他们可以……对我来说，即使我说的有些不相信的东西，我觉得那也很明显。然后人们就会失去兴趣。他们不会听你说的某个词了。所以，你说的内容并不那么重要。你必须以一种很难建立的方式来建立他们的信任。这需要时间才能达到那里。但一旦你有了它，它就非常重要了。

影响力与人格化

Speaker B: 有趣的是，我一直想如果 Claude Code 没有由 Boris 创建，它会像现在这么大吗？Boris 是你在 YouTube 频道上能看到的工程师。他也在这个频道上。他是一个非常容易接近和谦逊的人。至少我是这样认识他的。他在社交媒体上分享他如何使用 Claude Code。有很多关于 Boris 的内容。比如，这不仅仅是一个由 Anthropic 公司这样的公司创建的工具。不，实际上是 Boris 创建了它，他正在致力于它，他修复你的 Bug，你可能会说：“哦，它有这个 Bug。”而他回复：“我在你的提及中。”我现在注意到 OpenAI 是用 Codex 来构建这个东西的，但现在 Tibo 是 Codex 的负责人，他回复，他做和 Boris 类似的事情。所以，我一直在想，这种个人角度——Claude Code 在软件世界中是收入最大的企业之一，我认为它们成本是数十亿美元。很难追踪具体有多少。所以它是一个与一个人紧密相连的巨大企业。

成为有影响力的技能

Speaker B: 我讨厌“网红”这个词，但似乎一切都在朝着让公司也必须成为一个人的方向发展。他们必须有一个个性。他们必须……

Speaker A: 是的，是的，像可接近。是的，有亲和力。就像一个人类一样，对吧？不像仅仅是一个企业人物。甚至对于CEO来说，有时这也有帮助。有时它会适得其反，但我不会说任何名字，但嗯，我认为这很有趣，而且我认为有些公司有很多这样的东西。我想你可能比我更了解 Meta，但 Meta 有一个内部的 Facebook 或者类似的地方，当你发布产品时，你必须展示它。你必须提及它。你必须试图吹嘘它。是的，没错。推广它是一种技能。我没有预料到我会成为网红或 YouTuber，但它是一种技能，我认为每个人都应该向这个方向倾斜。就像不是每个人都必须做 YouTube，但无论是在 LinkedIn 还是 Twitter 上，我认为值得把你自己展示出来，慢慢形成观点，并与人们互动和一些事情。

关于自我评估与努力的重要性

Speaker A: 你需要评估自己是否属于那种会做某事的人，因为这可能对你来说不是最好的选择。不幸的是，人们只是習慣去做那些事情。但是，就像我制作那个视频的时候一样，有很多对我感到不爽的人，但出乎意料的是，绝大多数人他们说也许我本可以更友善一点，而且我认为这是真的。但他们实际上同意了我很多观点。很多人说，你知道的，你是对的。我意识到我一直在朝着仅仅是“提示”事物（prompting things）的方向走得太远了。我在这方面变得越来越差了。我现在做的产品和事情现在更糟了，我也没那么享受它了。这让我想要重新专注于学习以及成为我能成为最好的样子。所以，我想你知道，当我做那些事的时候，我不是试图冒犯任何人，但我认为我没有看到其他人谈论它，所以我只是觉得我必须这么做。我把它放在我的笔记本电脑上，而且我认为它会以那种方式爆发。我并不认为大多数人会看到它。嗯，但是是的，即使我可能因此受到了声誉上的打击，我也留下了那个视频。

Speaker B: 是的，但我认为这回到了努力的问题上，对吧？是的。作为建议，你会给软件工程师提供什么建议，无论是早期职业、中期职业，还是更晚期，那些可能在公司工作或者他们只是想成为你所认识的标准工程师——比如你在谷歌工作的那些人，或者你认识的人，或者他们在初创公司工作的人？你认为今天要真正脱颖而出，从一个拥挤的空间中脱颖而出，让你的工作能为自己发声，这需要什么？那意味着什么？

Speaker A: 是的，所以我试着让我们的对话感觉我们一直在重复这一点，就是努力。就像，不要走捷径。我的意思是，当你有一个商业成果时，尤其是在你建立你的业务或者你有你要实现的目标时，但除此之外就投入工作吧。

Speaker B: 这听起来很简单。在纸面上听起来真的很容易，但将其付诸实践是困难的。比如，对我来说，有时我不是一个喜欢改变的人，实际上。我非常抗拒改变。我讨厌改变。需要我好几年才能改变。

Speaker A: 但你网站上仍然有 Angular。

Speaker B: 是的。但是，但当你真正去做它的时候，它非常重要，而且非常有价值。我认为这很重要，它会成为一种生活方式。比如，你开始在编码方面投入很多努力，然后在职业生活中意识到，软技能非常重要。我花了很长时间才学会它们。到今天我还在学习它们，但这正是为什么我可能得到了晋升的原因。这就是为什么我的团队喜欢我。变得受欢迎是很重要的。你不想被讨厌。

Speaker B: 最后，你从哪里获得灵感？这可能是书籍、视频，这可能是 YouTube 频道。是的，我认为你只是听了 Martin Clapton 的节目。我非常喜欢他，非常喜欢他的书，因为他深入探讨。即使他探讨得再深入，在每一章的末尾你也会有上百个参考资料。我喜欢这一点，因为我就是那种总会有一个后续问题的类型的人。我总是想深入了解事情。所以，看到像他这样的人，我比对工程师更喜欢科学家、博士、研究人员。所以我真的很喜欢这一点。我认为拥有你可以学习和向其效仿的人是很重要的。而且我认为有很多我可以从中学到灵感的人，包括其他 YouTuber，包括技术人员，包括我过去合作过的人。我总会观察一个人，并试图看到他们身上我非常喜欢的一些特质，然后我也会试图复制和模仿他们。

Speaker A: 很棒。很高兴能和 Neet 录这个节目，特别是以他本人身份。我喜欢他有多诚实，我希望这传达得很好。我发现 Neet 现在招聘的方式很有趣。他经营着一个最大的代码准备网站，然后他会为编码之外的技能招聘。他关心动机，这个人是否能解释自己的思考过程，最重要的是，对于代理（agency）或者完成任务来说。他还很乐意和我谈论他认为公司根本不知道如何评估候选人，而且他们可能从来没有做过。LeetCode 风格的面试之所以存在，不是因为它预测工作表现，而是因为它只是不预测，但因为没有人找到任何更好的可扩展的东西。最后，我欣赏 Neet 的观察，即随着 AI 让其他一切变得廉价，努力正在成为一个差异化因素。任何人都可以提示一个设计、一个功能或一个答案，但你无法提示的是关心以及当有人问“你为什么这么做”时，你捍卫自己选择的能力。请查看下面的节目笔记，了解与技术面试相关的一些务实的工程师深度探讨，它们会深入到更深层次的技术面试相关主题中。如果你喜欢这个播客，请在你的最喜欢的播客平台上并在 YouTube 上订阅。如果能给我一个评分就特别感谢了。谢谢大家，我们下次再见。