What separates strong engineers from everyone else? Not deep-sink, or as many call them neat. He created Need Code, the coding preparation platform that helps countless devs get tired of 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 the mindset than the algorithms. The growing difference between engineers who can still think without AI at their fingertips and those who freeze without it needs 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 roting, this episode is for you. This episode is presented by Antisys. Antisysys 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 it insists it's a comm slash pragmatic.
This episode is brought to you by Sentry. Sentry is a tool I use for application monitoring back when I work at Uber and I now use it on all my projects, including the pragmatic engineering backend. One new feature I'm really liking about Sentry is their Sierra AI agent, which helps investigate production errors. For example, here's an actual error I had in my application. I can just ask Sierra 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 Code X or Clock Code using Sentry MCP. After you hook up the MCP server, you can do some very useful things, for example. When and already resolved Sentry's for re-services, you can kick off on the agent's investigator regression, read the relevant code, and open a PR with the suggested fix. There's a little work involved to get all this going. You need to connect Sentry to your coder repository, add Sentry MCPs to cursor, define the instruction for cursors agent to investigate, configure the trigger that launches the automation, and test 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 Central.io.com and start monitoring and fixing regressions today. 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 and when AI will be good enough to write code, coding interviews will be dead because of the day today, 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 does 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. It's confusing to a lot of people. And I think that it goes back to how do you evaluate if somebody's a good hire or not? Because 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 State City is that companies just have no idea how to evaluate. And they probably never did. I think I was talking to
a friend of mine, Steve, from Amazon. And he mentioned that they've ran some studies, and it's very hard to know whether somebody, when you hire somebody, no matter how much data you have, no matter how you run the interview process, that it's just very hard to know how somebody's actually going to perform on the job. If they're going to work out, right? It's a very hard problem. Because even if somebody is good, how are you going to be motivated?
How are you going to enjoy the team environment and all that stuff? I think it's just really complicated. Could another reason be that it's so sticky and it's so sticky that maybe it's just simple is there? It's kind of like if it ain't broken, don't fix the type of mentality. 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, that big company. It's very bureaucratic. There's going to be a lot of retraining. And we're already seeing that with companies like Meta trying to run AI coding interviews. The training is really hard to get down because it's like, interviewers are just not good. Like most interviewers do not like interviewing.
And so when you're saying training, you mean interviewer training. Training your interviewers at a large company, like 1000 of them to be similar. Exactly. Yeah. Because that would be a 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 like an exact science. It's hard to measure these things.
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. I want to rewind a lot back into in the early days. Like, how did you get into tech?
What was your first interaction with programming coding? Yeah, I was actually studying electrical engineering when I was in college. I really like math. I really like 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 an intro to C class. It was required for electrical engineering. I didn't really want to take it.
And that was not very good at it initially. I remember trying to learn print F 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 kinds 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 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
they're back to my story. Once I really started enjoying programming, I just fell in love with it. And I was like, okay, I'm gonna do this for the rest of my life. I'm gonna 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 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, is boring. And then you got to have 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 don't know exactly 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 like three choices and you can pick two of three. There's consistency and that's data consistency. So in like a distributed system where you have data that's like partitioned in different regions or something, you can go out of sync, like one database might be more up to date than the other. And then there's availability where both of these, 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, 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 that zeros and wants to know exactly like what was happening. And so that theorem felt like 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 I think like you don't get to go as deep as you like 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 ripe, but maybe he's, you know, being a 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 kind of funny, because I think I never saw anybody mention that about cap theorem before. Like I've saw like post on stack overflow, nobody really mentioned it's kind of incomplete. And so the thing that came after it is like Pac-L's, 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, cafeteria, 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 a law to add a three simple enough move on. And I guess in most part of their lives, it's enough, or they might not even use it or when 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 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 the document links, like, you know, you have one blog or you have one site and it has references like five others. That one is going to reference five others. Like, I want to go through every single one, I have like a complete understanding of everything. But that's just not how it works, that job,
even a code base, no one person is going to understand it, 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 agent 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 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 still, you know, that's life, that's business. So you graduated from University of Washington,
and you started working at the most obvious choice in Seattle, I guess the Seattle two obvious choices are Amazon or Microsoft, and you got into Amazon and it should have been a smooth ride, like you made into big tech into the big leagues. And then you quit after two months. What happened there? Yeah, first I want to say actually went to Washington State University because 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 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 difficult for me. And Amazon, the org I was at, Alexa, which has kind of been gutted from what I hear nowadays with LOMs, but the team I was specifically in, 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, saw a message on the internal thing, I think it was at least 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 like a
positive team environment right now. I think there 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. I kind of know things. It would have been stressful in 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 personal issues at the time. And so for whatever reason, I just made a very impulse decision to just leave
the job afterwards. I kind of regretted it because like, you know, I felt a little bit of relief, but that just felt a lot worse. I was like, okay, now what do I do? And 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 were just like not adding up? It was very intense. So we had a meeting because there were like five or six new grads who joined
like within a one to a two week period for a Zoom 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 think, okay, well, if you introduce a bunch of new people, you're gonna obviously onboard them like at the up to speed, but they have a lot of deadlines that they were dealing with.
So it was kind of like the experience 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 they were like, nobody said anything. They 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 chance 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 3am and we have like 8am or 9am 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 the one person who's not doing it at 3am,
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% un-regarded attrition every year, which meant that managers or like directors at their level had to have 6% of people leave the company and mark it as un-regarded, which meant that either people quit on their own and you said like, actually, this person was not great un-regarded or you need to put people on performance improvement plans and then have them leave. I was like, yep, that was un-regarded attrition. So it's somewhat cut-troll in some of the organ, most of the orcs. Yeah, I almost have like some conspiracy theories about that because I think I gave my resignation,
I have to say three times before they finally like accepted it in a way, which was surprising to me. I was like, well, I don't like they accept the resignation even after like the second time. And I was thinking like maybe this is like, because like it looks bad because it's a 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 three to six months or something. I left
like two 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 cutting, they told me like, yeah, like sometimes we do let people go and stuff like that, but I don't see it that way. I just see it as like a bad culture. And they were trying to be nice about it. But again, 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, 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 or just work and just be as intense as possible. But people were very friendly to me. And so I kind of reciprocated that. I didn't
ask questions. I was very scared to say I worked on my own for the most part. And I was given a project for 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 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. Like after I got promoted is when I was like more comfortable like asking
questions when you'd expect that from a junior engineer more. It's so interesting because you've only at that point had maybe two months of professional experience working at Amazon when you join Google another six 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 a 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 VP or GM. He joined from Amazon for a few months and he actually left for 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 map a lot of people that Google didn't like the Amazon Managers because it's like, oh, they're gonna be less likely to like take us on a trip or pay for us because they know that Amazon has like a frugality and Google doesn't. But slowly like while I was there, slowly started to get going that direction, especially
with the way offs in 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, 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 to be reasonably smart. But I think vast majority of people are reasonably smart. I think it goes into the other things where it's just right team, right project, because if you don't get the right project, there's no way you can prove yourself. You could be a 10x, a 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 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. And people don't love that. But I think in terms of like processes, it's just unnecessary evil, like 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 want to find that. And then on the side, even before Google, you started what is now known as neat code 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, and like six years ago. And I was doing it really just for fun and for the lovely game because 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 is more of a personality trait for me. But I think it helped me a lot with like a leek of stuff. I went really deep into things. But at the time felt kind of meaningless, where it's like you make this video for 50 people watching and you do a great job. But like clearly
like it's not worth the several hours it takes to do that. But I kept doing it because 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 like, it was fun. But I'm like, Google
not have your guess. And then I saw that actually, like, I made a video telling people, like, hey, I got into Google, by the way, you might not see me as much anymore. And funny enough after that, the channel 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 had to make it before. And so
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 proved it. 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 video doesn't change, right? Like the branding change, but that made like a really big difference. Yeah. And so after I went exponential, I was like, okay, maybe I'll make a website. And then the website was completely free at the time, but just really 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. He's like, 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 go from L4, which is still mid level, but you now had a path to L5, which I mean, it used to be determined level of time now, L4 is determined level, but you know, in Google, you go to L6, L7, L8, principle, so you had that path of like, stay inside Google, do this stuff, or start your business or turn this into business and go deep into AlcoCui. How were you thinking of the two options and what you would give up or what kind of 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 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, he's my manager. 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, that was what I was going to do the rest of my life. I was going to work at Google. I was going to 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 on like good standing with your team and stuff like that, which likely 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 like, should I leave Google? I just had a friend last week. She wanted to 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. Well, I mean, I think a trend that like we always have in bubbles, right? But in like certain bubbles, it is how was the switch game? You actually went from,
okay, you made the decision, you went from like having a really structured work, a team, everything was figured out. Google has amazing internal info. You can just focus on, okay, the business problem is still coding. And now you're like, okay, you have the website, you have like, get repository, what was the switch like? And you're like, 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 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. 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 some that you got Google built something that 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? Yeah, it 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 six 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 because everybody's different. They're not like agents where you just give them the task and they're a machine that is 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 CEO, sometimes when you see your takes over the entire company, either can go like up or maybe goes in the other direction. So when you started, so like you had Google, you had a website that listed your videos, I guess very simple HTML, so maybe a bit of JavaScript. What did you build and 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've met so many people. I'm like, oh, maybe I should do convex now, I should have done 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 LOMs. 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 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 with the UX, like how well did I explain something in a video? Because if X mentioned sucks, nobody cares. Like how pretty the site is the video? What is the product or most of the product? 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 like tech choices I made, the business value like exceeded everything else. 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 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. 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.
I still take shortcuts today because there's just so much value in it. I have a story I could 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 3000 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 the 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 3000 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 live coding,
maybe I could get this done in less time, maybe a couple of 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 cost me like 200 a month versus like 3000. 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 to the 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 a bike coding thing and you run into an issue and it's like, okay, now you 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, it doesn't happen that frequently. We was just talking about operating a service when we have to manage our own info and taking care of spinning up new instances with one crashes. This is the perfect time to talk about this episode's sponsor, Google Cloud Run. As software engineers, we really just want to write code not managed servers or wrestle a complex scale on 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 LMs deploying as the simplest typing G Cloud 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 on idle all with no manual intervention. This means you pay absolutely nothing for quiet projects. Personally, my favorite feature is how Cloud Run handles donor redundancy and automated failover for you out of the box. And before you dismiss it as something you might not need, I just recently covered how Coinbase was down for 10 hours because they did not have Zona 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 any other info 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, Antisysysys.
Neat talked about memory-lixing 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 Antisysys, you no longer have to rely on hope. Antisysys 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. Antisysys 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, Antisysysys doesn't only find bugs, it gives you a perfect reduction of every issue. I know this
sounds closer to science fiction but it's actually hardcore engineering under the hood. Chain Street, Fly.io and the FCD community ship Agent Britain Code with all confidence because they know it's been verified by Antisysys. To see more case studies and details, head to Antisysys.com.pragmatic. That's Antisys.com.pragmatic. And with this back to neat and historian 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. There has been practically zero outages. I have less outages than leak code 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 fix it.
That's so 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. You can check it can run your problems as such solutions. With AI assistants you knew what you wanted to build. You built this engine in a way that you think it should work. You tested it. It seems to work everywhere.
If you deployed it and took you two to three 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. Do you not think this is a little bit typical of what we're seeing with AI, assist coding or AI coding of a lot of people are like, again, like, oh there's a sass. 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 it makes no business sense to fix it or it sounds too difficult because you didn't write all of it but of course it was faster. So the way I think about it is if I did fix the issue I could probably allocate a smaller pool of servers. So maybe I could save a couple hundred bucks more and I do think about, okay does this actually make a difference? I've actually thought about it a lot. I'm like, should I just fix it? Because is it going to be an issue later on? And I initially tested it. I was
only sending like a small amount of like traffic to the service and I still had most of it going to the original one. So I just ran it for a couple of weeks and I was 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 service will go, one of the services servers will go down, but then just like replace 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 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 the better is it's overall like better because it's cheaper, it's faster. And yeah, there is of course a trade offs like with engineering. There's now a
regression that crashes one of the servers. So you run an additional one, you have like replication that if you will, and it's still cheaper overall. So like overall, as you package it, it's better than before boom, like it's kind of obvious business decision. And like, I guess an engineering, like you there's a question like how perfection is unique to go when a problem is already solved and it's good enough. Yeah, that's right. I mentioned at the beginning that it like bothers
me that you can't cut 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 as especially as a founder, but even the software engineering, like at some point you need to start to think about the business. But the interviews of that people are taking with neat code in order to get into big tech,
you know, they first you need to jump the hoop of coding interviews. What do you think preparing for these data structures and algorithms, coding interviews, gifts to people that is actually useful on the job? And I'm not talking about the algorithms, but but actually the other things that you gain by preparation. Yeah, I think so from my perspective, at least I 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 an Amazon and then I left and then so for that like year before I got into Google, I was really just doing leak code. I was making the exploration videos and that kind of taught me about like speaking and communicating and like thinking deeply about like a problem and maybe like a 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 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 communications that I could go to my manager and say, okay, so this is what I'm thinking, kind of like you're doing an interview, right? Like 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 around 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 the communications side and also on the trade-offs side, which I think is really what engineering is about. And it goes back to like what like people are experiencing with like agent coding and stuff. Everything is a trade-off. It's not really in engineering, there's no correct answer. Like there is a 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 out days 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 like 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, a really smart person, like going from one to another. And 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 dish 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 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. It 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 or 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 Huynh. I think you've also had her on the podcast and she was because everybody 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 like what hard skills are going to be important, right? Like what programming language should you learn today? Like how high level should you go?
You even need to know how to code, right? But as she mentioned that, okay, like those are like impossible questions to answer. But the one thing that she did understand is that systems thinking this like 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 like maybe a construction, right? Like you walk around, you see like all these buildings being built, you see the workers.
And whenever I look at that, I see like this big complex thing and all these like people doing all these like little things. And then at the end of it, you have like this big building built that's like so complex, no one person could probably do that themselves. But it goes back to you have like the workers working on like 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 like this big process, this system of like making buildings, making sure that you don't have issues with that. And I think that is a skill that there's no like course for that, right? Like there's no like that's a hard thing. Like most
people aren't building the system. They're like the worker bees. They're not like the ones architecting this whole system. But I think that's the skill that is so important because that's where like all the value comes from. You have these worker bees, but without the system, like 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 like a lot of things together. Well, I'm going to push you a bit on that. Like 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 have if you're in the legal industry, like it's based on whatever country you're operating in. If you're on legal tech, startup and healthcare, healthcare tech startup, book's very different in the US versus like UK versus in Romania, etc. The people who are
great system thinkers in one domain often are they just we understand the domain and you'll pay me to one example where I worked in, which is very interesting, clash complex slash what's you get into it? Like people start to move around it because you go there's I wonder if it's there's there's obstacle system thinking, but there is also becoming a domain expert and somehow they kind of overlap as well because if you are 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, I completely agree with that. I think for me, it's definitely hard to like want to find articulate because it's very kind of like vague and I think you're definitely right though that like the skills, the hard skills, like the knowledge and like the details of like certain industries and things like 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 because I didn't actually use like 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. 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, especially when it's hard to do so. Absolutely. Yeah. Let's talk about the
hiring bar at Fang companies, the big tech companies, a lot of people are using Niko to prepare for these interviews. You're getting feedback from them up, you know, like they will write to you when they succeed or they will write a frustration after many months they haven't. So you get a bunch of signal here. What are you seeing in terms of just the algripical part, you know, the coding interview, like, are things saying the same, getting harder, getting easier in terms of the format, like, especially like at the early levels of juniors and stuff, it's still a lot of like algorithms and air 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 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 like some countries like India, it's very different. Everything's pretty much algorithms there. It's like lee
code hards and super hards and stuff like that. But in the US, I don't think it's that crazy, but it's yeah, it's not too crazy. Yeah, but I guess like, you know, 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 people like there's been cheating tools for interviews. And so we've had mostly remote interviews for the last like five, six years, and that's been changing a bit. I think Google is pretty much gone to on sites at this point back to the traditional whiteboard format. 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 that you're actually kind of promising, like if you were running a small small or small size company, you might actually consider instead of the, and you're talking against yourself here, against, but if you have to throw away the the the essay interviews, what is giving promise, especially with AI as it's tools. 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, you saw how they performed. And what I spoke into a lot of companies about last week is that there are a lot of small companies that can get away with it or 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 spoke into other companies that say that that's difficult for them, because if you're hiring, 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 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 that I'd give them on the job, or even just have a conversation with them, see how they think, like, can they think through trade offs? I don't even care about what answer they give me to a problem. I care about like, why did they say that? What can they say? Is it just something that
they saw in a chat GPT prompt or just recursitating it? Or can they actually talk through it? And then you look at a work that they're doing, same thing. I asked 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, because you're 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 they're using it as well. And you actually get a signal of how they're doing compared to others. It's interesting because one type of company doesn't really have trouble hiring is the ones who are working 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 other conversation will probably be more of a soft skills conversation because like, yeah, we're seeing your work. Like you've been selflessly pushing features to our product. Awesome. And I guess that's kind of an upside of all open source.
I think that's mentioned this, because I was speaking to a bunch of people that work with Ham that they just got that they were either contributing to open code already or DAX like new 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, Hey, would you be interested in working? So they already had this work that they could showcase. And it's like, if you're doing things in public, people can get a pretty good understanding of like how you work. Speaking of how you work at Need Code with your business, you and your team, how do you work with tools to use and how much code do you actually manual write these days, if any? Yeah, so I would say over the last six months, actually,
we've been ranking 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, like neat code, you change 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 a first few years when I was writing most of the code, very, very bad code quality. I use TypeScript, but I was not using like real TypeScript. I had a lot of at a lot of bad code. I was putting inline CSS. I was 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 it 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 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 off, 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. It depends on post a bunch of your health takes on social media as well. I don't know if it's like a 2 a.m. thing or but one of them you said is 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.
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. 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 because you're just focused on shipping and then things were gross and things get worse. And we've seen that anthropic recently, the last month or maybe more than that where things have regressed. And I think just a couple of days ago, they put out a blog post acknowledging that finally. But for them, they were just moving so fast that they did not notice. I saw Boris saying he was replying to a lot of comments asking, we haven't really noticed this. Why is
everybody else noticing it? And now they have. And I think it's, again, just goes back to trade-offs. Now maybe they've realized, maybe they just 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 when you pre-ai, it was pretty clear that if you move fast, you typically, you often break things. Facebook even
had this famous model. Or you can be more deliberate and break fewer things. But there's almost a dislider, 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, maybe this is not true. Maybe
you can move fast with quality. But we're seeing with that, like, they are moving fast and they are 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 open AI, they did like Sora and now they're shutting it down because they realized like, okay, 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 a smaller set of things. That's actually producing more value. Now they're going the anthropic route where anthropics 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 this, like the fastest growing companies in the world, like open AI 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 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, like, I think even the paper that started 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 matter the most. Yeah. Well, one interesting experiment you did is you did a redesign contest for meat code. I think the site you offer $2,500 for whoever submits a redesign. Can you tell me how to
want to? 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 the submissions are created with AI, which is fine. If you're going to use AI, that's completely fine. But again,
with the few people so far that I've spoken to and ask them questions about, okay, like your design, like, it looks like you made certain choices, right? You move 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 five 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.
If you just have the skill set of like design 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 color's 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? 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 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 putting into it is let's say maybe if it's like 10 contestants, it's like maybe $250 or like there'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 a part.
Yeah, I thought that a contest would have been the right way to do it because I don't have to like hire or 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 maybe even just a small pool of people and then just paid them upfront and then just saw the work that maybe chosen based off that because I think there has been like a lot of low effort. It's been disappointing to be honest. Well, you'll have to learn but I guess it does prove that just giving a prompt 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, I want to make this prominent. I want to make this like a little bit different than you've seen on other sites where it doesn't like boring stuff like that. But the people like something that
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 they I can just do it. I don't care how pretty something looked. 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 heart 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 that about a year ago where he predicted that things would change and you were reflecting on it. 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 things played out because 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, 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. 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 still like they're coding completely differently now. But in terms of like the way the business is working, they're kind of doing 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 trade-offs. It's still a game of like move fast
and break things. I think programming is definitely going to continue to change definitively and maybe become a completely different field. But I think a lot of stuff around the business knowing the value to produce and just like engineering decisions in terms of trade-offs, that stuff is absolutely not going away. I don't think ever. Because how can you have an LLM way like a trade-off for? You think that's a very human thing to evaluate what's even important in engineering in general?
Yeah. And also like, for example, things like in programming, when you think of like what is it that we code, you need to build a feature. You need to build a task is add a button where when the user hits it, it's a thousand complaint. Something like a report about a report about that's a simple one. That is not just as simple as 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.
What kind of user? What kind of user? For user pages? Are there 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. I think like change is the one thing that's not changing because change is just keeps happening. And I didn't mean to pick that up on. But like I just saw I think yesterday or today, Microsoft is doing I think voluntary layoffs where they are buyouts. So basically, if somebody chooses to they can leave the company and get some severance.
And I saw it. 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. It was mostly to people. That was not voluntary in 2014. Yeah. Yeah. And so that was to a lot of experience 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 this like the big innovation, like cloud computing, like high level programming languages, for whatever reason, things do not like it doesn't lead to fewer programmers. And I would have expected it would have like when you have cloud, like 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 I 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. We're just like just doing everything and everything is easy and
now we don't need as many programs, but it just hasn't happened. And so based on that, I don't know, like you see things like Replet and Lovable where anybody can be a programmer now. And so I don't know if that's a direction we're going to go in where it's just very, very high level. 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 composition between AWS is your 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, where 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, whichever one thing is going to be expensive and so on. And they do it. And they're now doing an massive savings. 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 30-some of the signals has done. So
I wonder if if anything, there might always be a value in a certain scale, you'll like roll 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 is using it, it can snowball and then like you have an entire industry using a certain tool, 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. In some ways like we've seen cloud services get really, really complicated. Now it's like cloud-driven development. You have all these things and it's like, okay, you solve one problem and now you got a new one. And 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 not 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 because I feel it's very like, you know, like hard to talk, hard to define. But let's talk about it. This was
like you were saying like, let's assume that there would be an AGI or a godlike singularity. These models would be amazing, which I think we can see the implementation. But let's just jump like forward. What was this thought on like how we were chasing it? Yeah, I think like on a philosophical level, like it feels like you're trying to get to like infinity and it's like the closer you get, you're the same distance away from it. Right. And it's like, that's what I feel like it feels like
as technology has gotten better, you think that we've solved life at this point. We have like a button at resources and if we don't, like we're not that far away from having enough food, water, and shelter for everybody. But it's like something about life, like maybe it's human nature, something that just doesn't change. It's like you want more like, okay, now there's like higher levels of like programming, so now people are competing at like the higher level. And like as it gets higher and higher, people are still going to be competing like on some level, like maybe it's easy to like build an app now, but there's going to be a new problem to solve like on marketing and like edge cases and things like that. But I also think like maybe this is like a politics thing
because I think there's like technology, we should all we should all be happy that technology is improving. Like if AI keeps getting better, if it really does replace every job in some ways, it 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 because like if your livelihood depends on it and like politics and you know, you can't make money and then the government is going to take care of you, I think that's where it becomes an issue. It's like, it's more of a politics problem than a technology problem. Yeah, but I think you know, my interesting observation is like 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 do I in every country I live, I have to hire an accountant to find 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 when you want to find a plumber. So there's some everyday things where like I would welcome software making things easier. And I but I haven't seen much progress in the past like 15 plus years and not even right now with AI. So like I'm like, could be a nice trigger to like see those things
improving. Yeah, I think it's funny because like you look at history and I think one thing that I was taking for granted is that like progress always happens and things always get better. But if you look at like most of history for thousands of years, things didn't always get better. Sometimes you saw like 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 like preordained that things are just going to continuously keep getting better. I think like there's going to be a lot of decisions probably on like politics
and government side where like policies are going to get created. I think that's going to have like a really big impact on what actually matters to people and like their lives and stuff like that. Another one of your hot takes is how overhipping AI tools just creates slobbing erodes people's skills. Yeah, I think a lot of people, especially students are unfortunately learning everything through LLM's. So a lot of that isn't really learning that is 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 the even experience programmers I had a friend tell me that he's preparing for interviews now and he hasn't like handwritten much code in several months. So it's very hard for now him 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 assistants, you can actually talk with a person. And in person, you can actually tell the difference between someone who has put in the effort and can think and it's sharp and can put things together over to someone who gets like frozen without the AI being there at their fingertips.
I think it's really interesting because I think 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 a 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 just replacing the variables and things like that. I guess maybe my hot take is that maybe certain things actually will be less tested. Maybe people just won't care that much if you can actually hand write 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, like all of it, if you're able to do that.
But then if 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 a shortest distance between something or whatever. You have to be able to articulate that and figure that out. 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. One other take you have is you said the personality traits
you think are now more important than coding skills or actually most skills. 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. You look at the resume, a Java programmer or whatever. They're not that. I think people, especially in fields like software development, which are very
open-ended and decisions matter, trade-offs matter, communication, all that stuff matters. But I'm hiring people. I hired somebody a few months ago and they had certain skills. Obviously, they were going through the C.S. 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 are probably kind of hired that are working at big tech and have these really big resumes. 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 I can start up the term as agency. Somebody who's high-agency, 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. 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. I have this programming specific question. You can just get it out of a prompt if you know the questions to ask.
Knowing the questions to ask is just a matter of putting in the effort. Yeah. I like agency. I'm also sensing you didn't mention that it's 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 like their ability AI info and how they're struggling to find that product market fit, even though they can build faster than ever. But 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 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 have to need to convince them why they are more trustworthy, they were being betting on and so on. And it's a lot of it does have to do with like a charismatic founder who is good at convincing people, all right, try myself. It actually helps. Yeah. That's one of the things I actually learned from YouTube as
well, because if you're making like a video, trying to explain something, nobody cares how correct you are, nobody cares how smart you are, nobody cares like in the lead code forums, if you have this super like crazy like solution that's really impressive and really perform it, if you can't explain it, because what they care about is like a value you can give to them. If you can speak in a way that they can understand, but when I was making those videos, I would enunciate certain things more, I would like emphasize certain points, I repeat certain things and I just try to make the video just 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 like the human part of it, just knowing like people figure out like what exactly they're actually looking for, what they actually care about, I think that's something that's that's pretty important. The YouTube is interesting because YouTube, today
at least it's, 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 boss there, Google is fighting them. And it's a real attention economy, right? Like it's the, you know, like the Mr. Beast who's the most subscriber watch 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 than having access to the online videos, but it's kind of like 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 value of 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 of different people that are working on the same thing where it's kind of a game sometimes where it's a little bit of like politics, where it's like, you know, like it's about packaging, right?
Like how you say things, how you present things, how you kind of like present yourself. And it's also about I think being like authentic. I think that's a big thing that companies maybe don't always get right. Sometimes they try to, even with the AI labs, what you're saying that like nowadays, like OpenAI and like 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, like that authenticity usually matters a lot. People can like smell the fakeness.
They can tell like even for me, if I'm like saying something I don't quite like believe, I think it's so obvious and people can tell then they just get turned off. Like they're not gonna listen to a word you say at that point. And then so it doesn't really matter what you say. You have to like 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 matters a lot. It's interesting because I do wonder if Claude Code had been had 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
cloth code. There's a lot of Boris. Like this is not just a tool that is like some by the corporate called and traffic. No, it's actually Boris created it and he's working on it and fixing your bugs. And you say like, Oh, that had this bug and he's in your mentions. And I now know it's open AI. It's
Codex used to be the same built by open AI. But now it's Tibo who is the head of Codex and he replies and he does the same similar things as Boris. I do wonder if this, you know, like the personal angle where it's here. Oh, and a clock code is one of the biggest businesses in the software world in terms of revenue. I think they cross multiple billions. It's hard to track how much so like 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 like, even for companies, like they have to be a person now, like they have to be a personality. They have to approachable. Yeah, like approach relatable. Yeah, relatable, like a human, right? Like not just a corporate figure, even for CEOs, sometimes like, you know, it helps the
sometimes it does sometimes it can backfire, but I won't name any names. But yeah, I think it's funny. And I think even companies, like some companies have that a lot. I think meta, you probably know more about this than I do, but meta has like an internal like Facebook or something where it's like when you ship, you have like kind of show it all. You have to like mention it. You have to like
drag 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 like not everybody has to do YouTube, but whether it's like LinkedIn or Twitter, I think it's worth, you know, putting yourself out there and slowly forming opinions and like interacting with people and things like that. Yeah, well, you said like maybe not everyone has to do it, but
related to this, you've had a pretty contentious hot take, which was some people should just give up on tech careers. Let's talk about like that. It's a pretty big statement. 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, like you don't want to try hard or you don't like 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 like what you're getting yourself into because a lot of people don't know like they go through these college degrees, like 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. Like when I made that
video, I had a lot of people that were pissed off at me, but surprisingly, like 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 like, you know what, you're right, like I realized I was going too far in the direction of just prompting things. I got a lot worse at it, like 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 like refocus on like learning and being like the best that I can be. So I think, you know,
I'm not trying to offend anybody when I did that. But I think I saw nobody else talking about it. So I just felt like I had to do it. I recorded on my laptop and didn't think it was going to blow up the way that it did. I think most people were going to see it. But yeah, I left that video up,
even though maybe I took a reputation 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, earlier, mid-career, maybe in later who are either working at a company and they just want to be seen as this awesome engineer. When you think of like the standard engineers that you work with, you're 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 recovery 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 like general advice that would apply to like 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,
like the effort matters, like even in an interview setting, knowing your audience, it's not like, you're not just like living in your own head, taking like this standardized test. You're talking to somebody, you're seeing how they're reacting to what you're saying. Like maybe they're not on the same page, like there's certain shortcuts you can't take. Like 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 like if you don't have to, like 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 like that iterative process of like that feedback loop of like, 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 like course correction. And that's difficult. Nobody wants to do that. Like, oh, one thing I always did with my
manager, I was asking them, like, if you have feedback for me, please tell me, like, I will not get offended. I want to know. I want to know what I could be doing better. And the way my, like, all my managers ever reacted to that is they were very surprised. Like, well, first of all, if you just joined the company, you're asking this, like, that's a very good question to be asking, because like, that tells me that you actually care and you actually want to get ahead. So,
I think like that aspect of it matters a lot because 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 like communicating that with people. Yes. So I was trying to, I felt coming through our conversation is we just keep coming back to it as effort, effort, like, and don't take the shortcuts.
I mean, take the shortcuts when you have like 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 like put into practice. Like sometimes, especially for me, I am not a person that likes change, actually. Like I am very resistant to change. I hate change. It takes me years to change, but you still have
anger on the website. Yeah, but, 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's like, it becomes a way of life. Like you start, like, I put a lot of effort on the coding side and then in professional life, I realize, okay, like the soft skills matter a lot. It's gonna be a long time to learn them. I'm still learning them to this day.
But that's the reason I probably got promoted. That's the reason my team liked me. And it's important to be likable. Like, you don't want to be hated. And it's closing. What are places that you get
inspirations from? This could be books. This could be videos. This could be YouTube channels. Yeah, I think you just had Martin Klutman 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 100 references at the end of every chapter. And I just love that because I'm the type of person. Like, 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, like I relate more to like 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, I always look at a person. And I try to see like qualities about them that I really like. And then I
try to like replicate them and imitate them as well. Neat. It was awesome to have you here. Especially in person. Yeah, it was great meeting you. I'm glad we finally got to record this episode with Neat.
I love how honest he is. And I hope this came across as well. I found it interesting how Neat 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 the companies have no idea how to have held a candidate. And they probably never did. The lead co-sell 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 Neat'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 engineering deep dives that go even deeper into tech-interview related topics. If you enjoyed this podcast, please do subscribe to your favorite podcast platform and on YouTube. Special thank you if you also leave a rating on the show. Thanks and see you in the next one.