There's been so many predictions that

coding interviews will be dead.

>> There's been cheating tools for

interviews. Google has pretty much gone

to on-sites at this point, back to the

traditional whiteboard. Somebody's going

to be watching you code, and you're

probably not going to be able to cheat

your way through that.

>> One of your hot takes is 2026. It's

never been easier to build things, but I

would say that it just makes 10 times

harder to actually build value. You said

that personality traits are now more

important than coding skills. [music]

>> I hired somebody a few months ago. They

still haven't even graduated. Anytime I

give this person a task, even if they

have no idea how to start it, a week

later, they'll have learned everything

about it. That matters the most.

>> You've had a pretty contentious hot

take, which was some people should just

give up on tech careers.

>> You should know what you're getting

yourself into because

>> What separates strong engineers from

everyone else?

Neet Dhiman Singh, [music] or as many

call him Neet, he created NeetCode, the

coding preparation platform that helps

countless devs get hired [music] at big

tech. In today's episode, we cover what

preparing for data structures and

algorithms interviews that's [music]

useful on the job, and how it's more

about mindset than the algorithms. The

growing difference between engineers who

can still think without AI at their

fingertips

>> [music]

>> and those who freeze without it. Neet's

contentious hot take that some people

should just give up on tech careers,

>> [music]

>> and many more. If you want to understand

which entering skills compound over a

career and the ones that AI is quietly

eroding, this episode is for you. This

episode is presented by [music]

Antithesis. Antithesis runs your whole

system in a hostile simulation and finds

every bug before [music] your users do.

It sounds like science fiction, but it's

actually hardcore engineering.

Understand how at

antithesis.com/pragmatic.

This episode is brought to you by

Sentry.

Sentry is a tool I used for application

monitoring back when I worked at Uber,

and I now use it on all my projects,

including the Pragmatic Engineer

backend. One new feature I'm really

liking about Sentry is their Sear AI

agent, which helps investigate

production errors. For example, here's

an actual error I had in my application.

I can just ask Sear what might be the

root cause and it brings context and it

can also make a plan to fix it all from

the web interface. Oh, and it also works

in Slack as well, not just the web. One

place that I find even more handy to use

Sentry is from code X or cloud code

using Sentry MCP. After you hook up the

MCP server, you can do some very useful

things. For example, when an already

resolved Sentry issue resurfaces, you

can kick off an agent to investigate the

regression, read the relevant code, and

open a PR with a suggested fix. There's

a little work involved to get all of

this going. to connect Sentry to your

code repository, add Sentry MCP as a

cursor, define the instruction for

cursor's agent to investigate, configure

the trigger that launches the

automation, and test that it all works.

But once you have it up and running, you

can get regressions fixed faster while

still reviewing every and all fixes. I'm

not a fan of using AI tools just for the

sake of it, but I really like the

practical integrations where I can fix

errors faster and with more context.

Check out Sentry at sentry.io/pragmatic

and start monitoring and fixing

regressions today.

>> Neat. Welcome to the podcast.

>> Yeah, I'm happy to be here.

>> It's awesome to have you here. Let's

start with something that I've been

thinking about. So,

there's been so many predictions that if

if and when AI will be good enough to

like write code, you know, coding

interviews will be dead because

uh on the day-to-day we will not be

writing code. Now, most engineers are

not writing code, they're prompting at

work. And yet at the same companies,

coding interviews are still not dead.

What is your take on this?

>> Yeah, I think it's really funny with how

much coding has changed the last few

years and especially the last few months

that coding interviews are the one area

that have surprisingly stayed pretty

consistent. I know some people like talk

about them changing a lot and so far

they're kind of like changing a bit with

like AI-assisted coding interviews,

companies are trying that. But

surprisingly, the coding interview

format of data structures and algorithms

is really really sticky. And it's

confusing to a lot of people, myself

included, because like we've gotten to a

point where you can ask like an AI bot

any question about a code base it can

give you a pretty good answer. You can

ask it to implement some feature, you

can uh do anything pretty much. And it

might not get 100% of the way there like

even humans can't write bug-free code

but it can get at least 90% of the way

there like pretty close. So it's

confusing to a lot of people and I think

that it goes back to like how do you

even evaluate if somebody's a good hire

or not

there's one aspect of it which is like

do they have the hard skills do they

have the technical skills can they think

and DSA interviews were never the best

for that.

Well, thinking sure but in terms of like

does that skill translate to what you're

doing on the job? It never really

translated to that. It was more about

evaluating like does somebody think? So

I think that's one of the reasons and

the second reason that's stayed sticky

is that

companies just have no idea how to

evaluate like and they probably never

did. I think I was talking to a friend

of mine Steve from Amazon and he he

mentioned that like they've ran some

studies and it's like very hard to know

like whether somebody like when you hire

somebody no matter how much data you

have no matter how like you've run the

interview process that it's just very

hard to know like how somebody's

actually going to perform on the job. So

>> If if if they're going to work out

right?

>> It's a very hard problem because even if

somebody is good how do you know they're

going to be motivated? How do you know

they're going to enjoy the team

environment the vibe and all that stuff.

So I think it's just really complicated.

>> And could another reason be that it has

been so sticky and it's still a sticky

that maybe it's just simple as there

it's kind of like if it if it ain't

broken don't fix it type of mentality?

>> I think so because anytime you try to

change something you risk making it

worse and so it's like first of all it's

a lot of work to change that process at

big companies like it's very

bureaucratic. There's going to be a lot

of like retraining and we're already

kind of seeing that with companies like

meta trying to run AI coding interviews.

The training is really hard to get get

down cuz it's like Interviewers are just

not good. Like the most Interviewers do

not like interviewing. They hate it.

>> when you're saying training, you mean

interviewer training, like training your

interviewers like at a large company

like a thousand of them to like be

similar.

>> Exactly, yeah. Because

at a big company, you want the process

to be standardized. You want it to be

the same for everybody. And that's very

hard to get right in general. And it's

even harder to get right when you have

like more variables introduced, like a

new evaluation process, training

interviewers differently. Now you got to

check the AI prompts, like all these

variables. And so, it's not like an

exact science. It's hard to measure

these things. It's It's practically

impossible. So, I think

we're definitely going to see, I think,

companies trying different things. I

think we probably will see different

interview formats introduced. I just

think it is going to be a slower

transition than most people think.

>> I want to rewind a lot back into into

your early days. Like how did you get

into tech?

What was your first introduction with

programming coding?

>> Yeah, I was actually studying electrical

engineering when I was in college.

Because I really liked math. I really

liked physics. I know a lot of

programmers don't. Some Some of them

obviously do, but a lot of programmers

don't. But they really like programming.

And so, when I got into our programming,

I was just taking our intro to C class.

It was required for electrical

engineering. I didn't really want to

take it. And I was not very good at it

initially. I remember trying to learn

printf and the you know, percent S,

percent C, like

I don't know why. Like I looked around.

Everybody around me was learning it so

quickly. And to me, it was just a very

different way of thinking. Even though

it's kind of related to math, you'd

think it'd be easy to pick up, but it

really wasn't initially for me. But

then, I think a couple months went by

and we learned about variables,

conditions, loops, functions, and all

these kind of concepts. And then it

really like something just kind of

clicked where it's like

initially, programming felt kind of

boring. It's like you just have

variables and numbers. But then when you

introduce all these things, then you

realize there's like this infinite

complexity that can be introduced. And

and you see that with like all the

software that is built today, where it's

like you took these like simple

primitive things, these zeros and ones,

and all of a sudden you just have this

enormous like universe of software

solving insane problems. You have

databases like Google Spanner, which not

only take programming, but they take

physics, they take like atomic clocks

and GPS systems and all these things,

and they solve like these really hard

problems. And so,

I I I guess to go back to my story and

well once I really started enjoying

programming, I just fell in love with it

and I was like, "Okay, I'm going to I'm

going to do this for the rest of my

life. I'm going to love it." And then I

went through a transition where once I

got into the real world, I realized that

programming is not something you can

just kind of do the way you enjoy. Like

it's a business at the end of the day,

and so that in a lot of ways took some

of the fun out of it for me, where it's

like you don't get to work on the

languages that you like, the problems

that you enjoy solving. You have to

focus on like the business problems. And

so, yeah, I I I 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 you

got really excited it was boring, and

then you got excited about the

complexity and the possibilities, and

you kind of came back to down to earth.

One thing we were just talking about

before we started the podcast is the CAP

theorem. On how you also had a similarly

weird relationship with it. Can we talk

about it? And also for those of us those

listening who who don't know exactly

what the CAP theorem is. Let's start

with that.

>> Yeah, of course. Uh so, it's a pretty

simple theorem. It's kind of described

awkwardly sometimes, where it's you have

like three choices, and you can pick two

of three. There's consistency,

uh and that's data consistency, so in

like a distributed system where you have

data that's like partitioned in

different regions or something. It can

go out of sync. Like one database might

be more up-to-date than the other. And

then there's availability, where are

both of these uh you know servers or

databases available to read or maybe one

went down. And then the third one is a

partition or partition tolerance. And so

that basically means in a distributed

system if there's a partition if maybe

the system becomes disconnected one

thing goes down the how is it going to

behave? And so the two out of three

framing is used a lot. It's not super

accurate. And the entire theorem is very

like incomplete. And so when I was

learning it for the first time I thought

you know

I like to go deep into things I like to

really really understand things. That's

what I love about programming it's

deterministic. Like if you really want

to you can go down to the to the exact

line of code the line of assembly the

zeros and ones to know exactly like what

was happening. And so CAP theorem felt

like hand-wavy to me and I didn't really

like that and that that goes back to why

I don't like certain things about

working on the job because I think like

you don't get to go as deep as you like

you have to solve the business problem

even if it means you don't really

understand some of the technical

details. But that's fine. But later on I

felt so validated when I saw a blog post

from Martin Kleppmann talking about how

much he didn't like CAP theorem. And it

was actually a little bit controversial

where

I think there were plenty of smart

people in the comments of that blog post

that said that you know maybe he's like

technically right but maybe he's you

know being a little little bit nitpicky

and I think that's like a personal

preference but I just felt very

validated that somebody like him

agreed with me and I think it's it's

kind of funny because I think I never

saw anybody mention that about CAP

theorem before like I saw like posts on

Stack Overflow nobody really mentioned

it's kind of incomplete. And so the the

thing that came after it is like PAC

else which is like if there's a

partition you can choose either

availability or consistency but if

there's not

then

there's still a trade-off to be made

which is latency and consistency. So

it's much more complete. I don't

understand why anybody would learn the

CAP theorem when that theorem exists

because it's just more complete. It's

not that much more complicated. I think

it's more simple to understand.

>> I wonder if it's only a smaller subset

of people who actually go deep. You

know, CAP theorem, you actually like,

all right, let me understand the whole

thing and then you realize it's

incomplete. But most people might have

just like looked at it, you know, took

it, okay, it's the law, two out of

three, simple enough, move on. And I

guess in in most part of their lives,

it's enough or they might not even use

it or if when they they think they know,

but they don't know it exactly. So, it's

interesting cuz we're talking about

software engineers and you would think

that most software engineers go into the

details, but I guess maybe not.

>> Yeah, I think it goes to like solving

the business problems and just like this

is what I didn't like when I started

working professionally because okay, so

you go through like documentation,

right? You're going through onboarding.

Like at Google, there's so much

documentation, there's so many internal

tools. And I want to go deep. Like I

want to do depth-first search on all the

document links. Like, you know, you have

one blog or you have one site and it has

it references like five others. That one

is going to reference five others. Like

I want to go through every single one,

have like a complete understanding of

everything. But that's just not how it

works at jobs. Even a code base, no one

person is going to understand this

massive code base unless you like write

all of it by yourself, which is just not

how companies work. And now we're kind

of seeing a similar transition I think a

lot of people are going through now with

like agentic coding because it's kind of

a similar concept where it's like now

you might not even be looking at the

code that you're actually producing

yourself. So, it's it's kind of similar

and I think this whole transition kind

of reminds me of that where it's like

you don't get to do some of the things

that you used to enjoy, but it's it's

still you know, that's that's life,

[snorts] that's business.

>> So, you graduated from University of

Washington and you started work at the

most obvious choice in Seattle. I guess

the in Seattle the two obvious choices

are Amazon or Microsoft and you got into

Amazon and it should have been a smooth

ride. Like you you made it into big tech

into the big leagues and then you quit

after 2 months. What happened there?

>> Yeah, first I want to say I actually

went to Washington State University

because I

Yeah, I was actually not accepted to

University of Washington. I wanted to go

there, but I was not the best student in

high school. So, I was fortunate enough

that I grinded super hard for

interviews, had a pretty good GPA. So, I

got some interviews at Amazon, and it

was DSA related, so I was able to, you

know, crank that out. And then once I

actually got into the world, and this is

something I was self-aware about where I

knew I was not a well-rounded person in

that like working with people, people

skills, and just

anything of that. Like I could sit by

myself, go through like documentation,

work on things, but like working with

other people was very very like

difficult for me. At Amazon, the org I

was in Alexa, which is kind of been

gutted from what I hear nowadays with

LLMs, but the team I was specifically in

and I think Alexa the org in general was

not the best place. It was not a

well-oiled machine, a lot of manual

stuff going on. It was a really

stressful environment. I think when I

joined I saw a message on the internal

thing. I think it was I think they use

chime at the time, but he said, "This

feels like a thankless job." And I was

like I was going through the history of

the the team channel. This was like a

week before I joined. I was like, "Whoa,

okay. So, this is like clearly not like

a positive team environment right now."

I think they were all like decent

people. I don't blame any of the

individuals. I don't even hold a grudge

against Amazon. It was just a crappy

situation. And so, I think in hindsight,

like if I had to do it over again, I'd

probably be able to survive. Like I kind

of know things. It would have been

stressful and and crappy either way, but

I would have been able to get through

it. But at the time, I just didn't

really know. And like I had a lot of

like personal issues at the time. And

so, for whatever reason, I just made a

very like impulse decision to just leave

the job. Afterwards, I kind of regretted

it because like, you know, I felt like a

little bit of a relief, but then I just

felt a lot worse because I was like,

okay, now what do I do?

>> And then can can you tell me through on

like what it felt joining, you know,

like the the first impressions, what the

onboarding was like, and what were the

things that were just were like not

adding up?

>> It was very

intense. So, we had a meeting cuz there

were like five or six new grads who

joined like within a one to two-week

period. For the same team?

>> Yeah, and I think there were like four

experienced engineers already. And so,

like they over doubled the team and

mostly new people. So, you'd think,

okay, well, if you introduce a bunch of

new people, you're going to obviously

onboard them, like get them up to speed.

But they had a lot of deadlines that

they were dealing with, so it was kind

of like

the the experienced people were just

working and the rest of us were kind of

just like on our own. And so, we had a

meeting where it was like one of those

where you're just kind of like

introducing the new people, right? And

like again, I don't blame any of the

people, but they were like nobody said

anything. The experienced people, like

they did not like say anything. The

manager had to like kind of keep like

prompting them to like talk and to be

friendly and stuff. And I think they

just wanted the meeting to end so they

could go back and like finish their work

because they had deadlines to meet. I

saw people, and I'm not saying one

person, every one of the experienced

engineers was committing 3:00 a.m. and

we have like 8:00 a.m. or 9:00 a.m.

meeting in the morning tomorrow. And

some people are reviewing the PRs at the

same time. So, I don't know if it's this

culture where like I don't think the

manager told them you have to do this. I

think it's like implicit where it's like

you know, you kind of know that it's a

stressful environment right now. If

you're one person who's not doing it at

3:00 a.m., you're going to be the first

in line to maybe get kicked out of the

company.

>> Yeah, and also, I mean, Amazon

at the time, they had a target of 6%

unregretted attrition every year, which

meant that managers or like directors at

their level had to have 6% of people

leave the company unmarked as

unregretted, which meant that either

people quit on their own and you said

like, oh, actually, this person was not

great, unregretted, or you need to put

people on performance improvement plans,

and then have them leave and say like,

"Yep, that was unregretted attrition."

So, it's somewhat cutthroat in

some of the orgs or most of the orgs.

>> Yeah, I almost have like some conspiracy

theories about that because I think I

gave my resignation actually three times

before they finally like accepted it in

a way, which was surprising to me. I was

like, "Why don't like they accept the

resignation even after like the second

time?" I was thinking like maybe this is

like because like it looks bad because

it's regretted attrition where it's like

you didn't let them go, they chose to

leave. And and since it was so early, I

think it was too early for me to even be

on PIP. I think you get that like within

3 to 6 months or something. I left like

2 months in. And again, I don't blame

any of the people. I have no grudges

against any of the managers, even the

skip manager, because I remember when I

was quitting, they told me like, "Yeah,

like sometimes we do get let people go

and stuff like that, but I don't see it

that way. I just see it as like a bad

culture fit." And so, they were trying

to be nice about it, but again, it was

it was they weren't even trying to hide

it. Like it was obvious that the culture

is like intense. And some people would

say toxic. I'll use the word intense to

be more generous, but yeah.

>> 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 you're

supposed to not ask questions, you're

supposed to not talk to people, you're

supposed to not even be friendly, you're

supposed to just like work, and and just

be as intense as possible." But people

were very friendly to me, and so I kind

of reciprocated that. But I didn't ask

questions. I was very scared to. So, I

worked on my own for the most part. And

I was given a project uh from my manager

that turned out to be

more difficult than it was supposed to

be. But I was still in the mode where I

was like I just got to get it done. Like

this is my project. Like I have to do it

independently. And so that I was very

fortunate in that where I did have like

a very supportive manager, a very

supportive team. And because I chose to

do

pretty much all the work by myself, the

manager and team saw me as like

independent, which is what you need to

do to get promoted from like junior to

mid-level. I was very lucky to get

promoted like very quickly because of

that. And that helped me build my

confidence a lot. That made me realize

like okay, like I can start asking

questions now, which is funny. Where

like after I got promoted is when I was

like more comfortable like asking

questions when like you'd expect that

from a junior engineer more.

>> This is so interesting because you've

only at that point had maybe 2 months of

professional experience working at

Amazon when you joined Google another 6

months or so later.

And how you can have a lot of

reflexes ingrained in you coming into a

company. So you can almost imagine like

another engineer who had like two or

three jobs before, you know, they might

have built up all these onset things

that are coming from other companies'

cultures or what they've learned. And

they when they join, it it can be hard

for them to adapt to to the company.

Yeah, I'm not sure we think about this

in the industry.

>> Yeah, I think it's kind of funny you

mentioned that because I was in Google

Cloud where a lot of the leadership was

from other companies like Amazon. And we

had a VP or or GM. He joined it from

Amazon for a few months. And he actually

left shortly after that as well. Like I

don't know the exact stories behind

that, but I think there is a lot of like

in the industry a lot of culture can get

like mapped. A lot of people at Google

didn't like the Amazon managers because

it's like oh, they're going to be less

likely to like take us on a trip or pay

for us because they know that Amazon has

like the frugality and Google doesn't.

Uh but slowly like while I was there, it

slowly started to get going that

direction, especially with the layoffs

and all that.

>> Getting promoted at Google, what does it

take? What does it mean? I know there's

promotion packets. I know there's

committees. What did you see from your

perspective?

>> Pretty straightforward, I think. Like

going from junior to mid-level is

probably easier, I think, than from

mid-level to senior and as you get

higher and higher. In my case, it was

mostly just about like

working independently. And then once

like

I was lucky to get promoted, I think in

about a year, almost exactly a year,

which is very uncommon at Google. And I

could sit here and probably humble brag

and act like I'm just like this super

genius.

But I think it was really I think

there's like you have to one put in the

work, two be reasonably smart, but I

think vast majority of people are

reasonably smart enough. I think it's it

goes into the other things where it's

just right team, right project, cuz if

you don't get the right project, there's

no way you can prove yourself. You could

be a 10x, 100x engineer, and if you're

working on relatively easy stuff, you

can't really say that you solved like a

really hard problem. So, I think it

takes a lot of that. Google has a lot of

like documentation where it's like every

single thing needs to be supported with

like some metrics or some artifact, like

some design doc. And so, they have like

this culture of probably producing too

many design docs for really simple

things. Some people don't love that, but

I think in terms of like processes, it's

just a necessary evil at Google because

otherwise, some engineers might just

like work on stuff that they just feel

like working on, there's no impact to

the business, and so it's hard to kind

of like quantify that.

>> And then on the side, even before

Google, you started what is now known as

NeetCode, and a lot of people watching

or listening will know you for you or

even your voice from there. Can Can you

tell me how that all started and how it

continued as you were working at Google?

>> Yeah, so I initially started after I

quit Amazon, I think, in like 6 years

ago. And I was doing it really just for

fun and for the love of the game because

of

>> You were recording videos, right?

>> Yeah, I was making these like tutorial

videos. I was like, "I'm studying this

right now. I got nothing better to do. I

might as well like help some other

people." And I found it very difficult

because there weren't really tutorials

at the time. There was just a lot of

like forum posts of these really like

complex solutions. And I'm like sitting

there banging my head against the wall

trying to understand it. And I think

most people didn't understand the

solutions because it's it's very hard

to. Like I think most people just looked

at the algorithm, kind of had a

high-level understanding of it, didn't

quite know why it worked, but it was

good enough usually to if you saw that

question in an interview, you could

probably pass the interview. And uh this

goes back to like deep thinking, which I

think was a skill that it's more of a

personality trait for me, but I think it

helped me a lot with like the LeetCode

stuff. I went really deep into things

that at the time felt kind of

meaningless, where it's like you make

this video for 50 people watching, and

you you you you did a great job, but it

like clearly like it's not worth the

several hours it takes to do that. But I

kept doing it cuz I enjoyed it. About a

year after I started making the videos

consistently, I think I did get into

Google. Very fortunate to do that.

Interview process was pretty easy at

that point, thankfully. So I kind of

backed off the videos. I was like, this

is kind of a like

like it was fun, but I'm a like I'm at

Google now for the rest of my

>> your You didn't have your yes.

>> Yeah. And then I I saw that actually

like I made a video telling people like,

"Hey guys, I got into Google, by the

way. You might not see me as much

anymore." And and funny enough, after

that, the channel like went exponential

because I I think it added like so much

credibility. It's like, "Okay, this guy

didn't make these videos after he got

into Google. He actually made it

before." And so like this is what he

did, and then he got in. So it's like

it's like the best sales pitch in the

world. Like I I proved it. Like I went

from zero to one. And so it was I guess

a really good selling point. And it kind

of bothers me personally because it's

like the videos didn't change, right?

Like the branding changed, but that made

like a really big difference. Yeah, and

so so after it went exponential, I was

like, "Okay, maybe I'll make like a

website." And then the website was

completely free at the time, which is

really a catalog of the videos to make

it easy to use. And um

that went viral as well. And then so

pretty shortly after I got promoted, I

was like, "Huh, like maybe I can like

try this full-time." cuz I really loved

it. I I couldn't go as deep as I wanted

to at Google. I had to solve business

problems, but with algorithms and data

structures, I can go super deep, more

deep than most people would ever want to

go into those things, but I had a reason

to because it's like, "Okay, I can

explain these things to people." And so

yeah, I think it was just it was like

the right timing for me. And then

afterwards, uh thankfully it's like

worked out so far. But

>> you you were at Google. You just got

promoted to L4, which is still

mid-level, but you now had a path to L5,

which I mean, it used to be the terminal

level at the time. Now L4 is a terminal

level, but you know, in Google you could

go to L6, L7, L8, principal scientist.

You had that path of like staying inside

Google, do this stuff

or start your business or turn this into

business and go deep into algo coding.

How were you thinking of the two options

and what you would give up or what kind

of, you know, how much risk would one or

the other have?

>> Yeah, I thought about that a lot because

even though I I didn't love certain

things about Google. I actually really

liked the company. I liked the people

and it wasn't this super stressful

environment. And when I was leaving, my

TL, who was basically my manager at the

time because my manager had

>> Still being tech lead, right?

>> Yeah, tech lead. And he he kind of asked

me. He said, "I'm a bit perplexed that

you're leaving because you got promoted

very quickly and you could probably get

promoted again." And like, I did think

about that a lot because

it seemed like because that was what I

was going to do the rest of my life. I

was going to work at Google. I was going

to, you know, get promoted. I was going

to be like the best engineer I could be,

but I just felt like the the timing of

it like I had a chance to 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

thankfully I was. So that kind of made

it a little bit easier. I have friends

all the time that are making like the

same decisions. They're asking me like,

"Should I leave Google?" I just had a

friend last week. Uh she wanted to like

do content creation full-time. I think

it's like a trend almost these days

where everybody's quitting their job to

do their own thing, but

>> Well, I mean, I think a trend that in

like we always live in bubbles, right?

But but but in in like certain bubbles

it it is. How was the switch? Can you

tell me like you actually went from like

okay, well, you made the decision, you

went from like having a really

structured work day, a team, everything

was figured out. Google has amazing

internal infra. You can just focus on

okay, the business problem was still

coding.

And now you're like okay, you have the

website, you have Git repository. What

What was the switch like? And and you're

like What was interesting about it or

like good and fun? What was difficult?

>> I had a tough time with the learning

curve at Google, but once I left, I had

a tough time like transitioning away

from some of the tools because you get

used to it very quickly. Like they have

like GitHub, I'm just not a huge fan of

it. I know a lot of people are hating on

it nowadays with like the uptime issues

and stuff like that. But I have other

issues with it around like UX and stuff.

I think Google has certain internal

tools that aren't so great, but they

have some that are just like super super

good. And there's have been a lot of

companies that have been started just

because like some that you had at Google

built something and then they're like,

"Hey, we could make this public." So,

then they leave and then they start like

Cockroach Labs or something crazy.

>> What about like you went from from

working on a team and now you just had

to do everything by yourself. What was

that an issue or that was kind of

natural to you?

>> Yeah, that was actually a huge thing for

me where I It was hard to build a team.

It was hard to like work with people.

Like I kind of said at the beginning.

And I've only just recently, I would say

within the last like 6 months, gotten

used to it where now I finally feel

comfortable like delegating things and

like managing people. And finally like

it it took a long time for me, but once

it finally does click, you know, you go

through like so many experiences. You

hire some people, you have to let them

go. You figure out what works, what's a

good fit. And even just how to like

motivate people. It's a very different

thing like working with people cuz

everybody's different. They're not like

agents where you just give them the task

and they're a machine. They're just

going to spit out the code. Like people

are people. And so

those types of things there was a huge

learning curve for me. But now and I

hated it before, but now I actually

really love it because it's like when it

does work when you find somebody and

they're a good fit

and you feel like you can contribute to

their growth. You can like guide them a

little bit. Like you can steer the ship

a little bit and you see like how much

of a difference that makes to them. Like

now I finally understand what leadership

means when you like when it works. Like

when you're an effective leader like you

can make a magnitude of difference in

like

even like in a small team, but I imagine

like as you get to higher and higher

levels it can make a huge difference.

And you see that with CEOs sometimes

when a new CEO takes over the entire

company either can go like up or maybe

it goes in the other direction. So

>> When you started so like you quit Google

you had a website that listed your

videos I guess very simple HTML CSS

maybe a bit of JavaScript. Uh what did

you build and what what was the tech

stack behind it?

>> Yeah, so initially when I made the free

site I was still working at Google. So I

just chose some like random Google

tools. Uh I was using Google Cloud

Firebase

uh because it was so easy to use. I

regret that one because now I meet so

many people. I'm like oh maybe I should

do Convex now. I should have done you

know something different, but um I also

did Angular at the time which is what I

used at Google. So I was like it makes

sense. Maybe I can just learn it at the

same time. Regret that one as well. But

thankfully we've gotten to a point now

with LLMs. So like migrating things has

become relatively trivial. So like maybe

that's something I'll do. But

in terms of like building the

application itself

for whatever reason like I I just didn't

find that super interesting because

there's usually not that many deep

problems. I think the interesting things

came from like innovating and like doing

things in a way that like people care

about. Like nobody's going to care that

much about like the performance of my

site or or the tech stack I use or like

any of these like little things. They're

going to care about like the UX, like

how well did I explain something in a

video? Cuz if the explanation sucks,

nobody cares like how pretty the site

looks.

>> the video was is the product or or most

of the product, right?

>> Yeah, because it's education. So it's

like if the education is bad, then

nobody really cares. And and I I was

very bad at building, but I think the

idea, the concept, the value was good

enough that no matter how crappy the

site looked and like how bad like tech

choices I made, the the business value

like exceeded everything else. Like that

mattered more. And so that taught me a

lot about like prioritizing things that

actually matter and then you can take

shortcuts on the things that don't

matter. I think I saw Elon Musk has like

this four-step or five-step process for

optimizing like a workflow and like a

process where, you know, you start you

start cutting things out and sometimes

you cut too much out and you realize you

made a mistake and then you can like

slowly introduce that back in. And so I

took

that kind of approach because I was

mostly working by myself. I probably

should have hired people to move faster,

but I didn't. And so because of that, I

took a lot of shortcuts and I still take

shortcuts today because there's just so

much value in it.

Like I have a story I can tell that

people probably get mad about, but it's

worked so far for me. So I

I stick with that.

>> What what's the story?

>> So I have this service that I was paying

like 3,000 a month for service and then

I think late last year early this year

when like the AI vibe coding stuff went

really crazy, I was

I was new. I could probably write my own

version of this service.

>> What service was it?

>> It was like for code execution. And so I

thought like probably I could write my

own version of this for like within like

a month or two, but the 3,000 a month

opportunity of that versus like other

things I could be working on, there were

other more impactful things that I could

be doing. But I thought, okay, with vibe

coding like maybe I could get this done

in less time, maybe a couple weeks if

I'm lucky. And so, I actually got it

done in like two or three days. And it

did take coding skills. Like if I didn't

know how to code, I would not have been

able to do it. But I got it done in like

three days. And then so I deployed the

service. And so now that I'm managing

it, it costs me like 200 a month versus

like 3,000. But there's a bug in the

service. I think there's a memory leak

or something. And so so what happens is

I have this service deployed. Every

couple days, like one or two instances

will crash, right? So there's clearly an

issue, there's a production issue. I

could spend the time to go into that and

fix it. This is like one of those things

where it's like you get into to vibe

coding coding uh and you run into an

issue and it's like, okay, now you're

going to have to actually dig into the

details to really understand like where

the issue is coming from. So I think it

would actually take me much longer than

three days probably to find the issue.

So I haven't even bothered with that

because I'm like, well, okay, if one

instance goes down, like I'll just have

several instances running at the same

time, right? I'll have like four. So if

one goes down, and it doesn't happen

that frequently.

>> Neet was just talking about operating a

service when you have to manage your own

infra and taking care of spinning up new

instances when one crashes.

This is a perfect time to talk about

this episode's sponsor, Google Cloud

Run. As software engineers, we really

just want to write code, not manage

servers or wrestle complex scale and

configurations. Google Cloud Run is a

fully managed platform built to let you

run any code on Google's world-class

infrastructure with zero management

overhead. Whether you're running web

services, batch jobs, agents, or

fine-tuned LLMs, deploying is as simple

as typing gcloud run deploy or

connecting your GitHub repository. One

thing that makes Google Cloud Run stand

out is auto scaling and built-in

redundancy. Cloud Run scales up

instantly to handle massive traffic

spikes and scales down to zero when

idle, all with no manual intervention.

This means you pay absolutely nothing

for quiet projects. Personally, my

favorite feature is how Cloud Run

handles zonal redundancy and automated

failover for you out of the box. And

before you dismiss this as something you

might not need, I just recently covered

how Coinbase was down for 10 hours

because they did not have zonal

redundancy in place for their global

trading service. And the reason they

most likely did not have it is because

it's a ton of work to build automatic

failover even for a zone level. And I

personally cannot name many other infra

services where you get this kind of

failover out of the box. All these

capabilities let you focus on your code

while Google manages the infrastructure

and operations. Stop worrying about

infrastructure and start deploying. Try

Google Cloud Run today at cloud.run.

I also want to mention our presenting

sponsor Antithesis. Neet talked about

memory leaks in a series that he knows

about but just doesn't have the time to

chase it down. If you work on

distributed systems, you've been there.

You know there are deep bugs there. You

have no way to root cause them so you

can only hope there's nothing really

catastrophic. With Antithesis, you no

longer have to rely on hope. Antithesis

lets you fix and find all sorts of bugs

easily and efficiently so you no longer

have to choose between shipping quality

and shipping fast. Let me explain how.

Antithesis runs your whole system in a

hostile simulation. By doing so, it

finds every bug before your users do.

And because the simulation is fully

deterministic, Antithesis doesn't only

find bugs, it gives you a perfect

reproduction of every issue. I know this

sounds closer to science fiction but

it's actually hardcore engineering under

the hood. Jane Street, Flight Data IO,

and the etcd community ship agent

written code with full confidence

because they know it's been verified by

Antithesis. To see more case studies and

details, head to

antithesis.com/pragmatic.

That's antithesis.com/pragmatic.

And with this, back to Neet and his

story on why he's happy leaving a

production bug unfixed.

>> It's an interesting trade-off where like

engineer like the engineer in me hates

that because it's like there's an issue.

Like fix it. But the business value

makes no difference. Like there there

has been practically zero outages. I

have less outages than LeetCode and I'm

like like a couple people doing it. So

it's like I I just think it's like a

trade-off. And people could argue one

way or the other, but I think it just

makes so much sense right now for me to

not like fix it.

>> But this is so interesting. So, you paid

for an engine or or licensed it that if

I understand it it it was executing

code, right? So, when people like type

out stuff in in your editor, it runs it

and you can check it it can like run

your problems as as other solutions. You

used with AI assistance, you knew what

you wanted to build. You built this

engine in a way that, you know, you

think it should work. You tested it. It

seems to work everywhere. So, you

deployed it and it took you 2 or 3 days.

And and now you have this There's a

quality regression, but it it doesn't

make a huge difference to the thing. But

I want to push you on this. Like do you

not think this this is a little bit

typical of what we're seeing with

AI-assisted coding or AI coding of like

a lot of people are like again, like oh,

there's this SaaS that my company is

paying for. I'm a founder. I'm paying

for it. I can replace it. And you build

up something that is subpar and you kind

of get by. And and then again, it it

makes no business sense to fix it or

it's now too difficult cuz you didn't

write all of it, but of course it was

faster.

>> So, the way I think about it is like if

I did fix the issue, I could probably

allocate like a smaller pool of servers.

So, maybe I could save like a couple

like a hundred bucks more. And I do

think about like okay, does this

actually make a difference? Like I've

actually thought about it a lot. I'm

like should I just fix it because like

is it going to be an issue later on? And

I like I initially tested it. I was only

sending like a small amount of like

traffic to this service and I still had

most of it going to the original one.

So, I just ran it for a couple weeks and

I was like I would have coded this. Like

I'm pretty sure there's going to be

issues. And I saw like literally no

issues. Like it's just up like okay,

once in a while the servers will go one

one of the services servers will go

down, but then it just like replaced in

like a couple minutes. That's just how I

think about it. It's like it just

doesn't matter. Like my service is

technically faster because I run it on

like better hardware. Yeah, I I I just

see that like nobody cares. Like, no

user has mentioned anything about that

to me. It's better now.

>> So, so yeah. So, I I guess maybe to look

at a bit better is is it's overall like

better because it's cheaper,

it's faster,

and yeah, there is

of course, there's trade-offs. Like,

within engineering, there there is now a

regression that crashes one of the

servers. So, you run an additional one.

You have like replication if if you

will. And it's still cheaper overall.

So, like overall as as you package it,

it's better than before. Boom. Like, it

is kind of a obvious business decision.

And like I guess in engineering, like

you there's a question like how

perfectionist you need to go when a

problem is already solved and is good

enough.

>> Yeah, that's right. I mentioned at the

beginning that it like bothers me that

you can't go super deep. And so, even

for this, it actually does bother me.

But, I guess I've gotten used to it in

the sense of like prioritizing the

business and just thinking about like

the actual value, what do people care

about, what's actually going to make a

difference, like not just in the

short-term, but also in the long-term.

>> Let's talk about this, the how like

as especial especially as a founder, but

even as a software engineer, like at

some point you need to start to think

about the business. But, the interviews

that people are taking with NEET code in

order to get into big tech, you know,

they you first you need to to jump the

hoop of coding interviews. What do you

think preparing for these data

structures and algorithms coding

interviews gives to people that is

actually useful on the job? And I'm not

talking about the algorithms, but but

but the actual the other things that you

you gain by by preparation.

>> Yeah, I think so. From my perspective at

least, I like went through this

four-year degree.

I I didn't cheat through it. So, I made

sure I understood like all the

fundamentals and things like that. And

then I got in Amazon, and then I I left.

And then so, for that like year before I

got into Google, I was really just doing

NEET code. I was I was making the

explanation videos, and that kind of

taught me about like speaking and

communicating, and like thinking deeply

about like a problem and maybe like the

trade-offs between like algorithms and

data structures and stuff like that.

But, I didn't really do much

development. And then so, when I did get

into Google, I was still able to get

promoted even though I I think like in

terms of just regular like raw coding

and coding experience, I was probably

sub par compared to most people. But, I

was still able to like for a hard

problem that I had no idea how to solve

like using internal tools I've never

used before, I had the skill of okay, I

can sit down, I can go through this

stuff, I can kind of make a plan of how

I'm going to try things. And I worked a

lot on my communication so that I could

go to my manager and say, "Okay, so this

this is what I'm thinking." Kind of like

you do in an interview, right? Like,

"Okay, this is the approach I'm

thinking. Like, this is what I'm

thinking. Like, I'm going to go ahead

and do it just so you're on the same

page. Like, maybe you have time to like

look into it and give me feedback or

maybe you don't. But, just so you're on

the same page, like this is what I'm

going to be doing." So, funny enough,

like I do think I've gained a lot from

algorithms and data structures in terms

of like just thinking. Also on the

communication side. And also on the

trade-off side, which I think is really

what engineering is about. And it goes

back to like what like people are

experiencing with like agent to coding

and stuff. Everything is a trade-off.

It's not really In engineering, there's

no correct answer like there is in math

or science. Engineering is about the

best solution at the time. Like like

we're talking about like the the the

memory leak issue with my service,

right? It's a trade-off. Like, there's

no correct answer, especially in

business. There's no correct answer. And

so, I think that's what a lot of people

are maybe like missing nowadays where

they're focusing maybe too much on the

hard skills of like, "Okay, like can I

write this loop? Do I know this

particular data structure? Do I know

like all these like little things?" When

I think they're they're forgetting to

like zoom out and look at the bigger

picture of like what engineering is even

about in general. Because what you see

in the real world is you'll see a really

good engineer going from like one domain

to another or really smart person like

going from one to another and you you

you see that and you think like what do

they have that other people don't? It's

usually not some like very specific

skill that like they know this

programming language super well. It's

usually something related to that like

it could be whether it's a data

structures and algorithms or like some

hard skill. It it's like what you gain

from that in general and I think that's

like education in in general as well

where like you go through like 20 years

of your life learning about all sorts of

subjects and that like molds you in a

way that's very hard to articulate. It's

very hard to be precise about like what

exactly did you gain by like learning

math and physics and speaking and

writing and history but clearly

there's a lot there.

>> Sounds like you're saying that the

effort of learning, the effort of going

through doing hard things that might be

pointless at the time or like solving

problems that are maybe abstract or not

for a specific thing, they add up over

time?

>> I think so a lot and this actually

reminds me of a conversation I was

having with Chip uh Heath. I think

you've also had her on the podcast and

uh she was

cuz every nobody knows what like 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 which programming language

should you learn today? Like how high

level should you go? Do 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 in 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

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 can You have these worker

bees, but without the system, like

nothing's going to get done. And And so,

I think that type of thing is not going

away. And it it it's impossible to

learn, but I think it takes like a lot

of things to get there.

>> But I I'm going to push you a bit on

that. Like is is is it Is it really

systems thinking, or is it being

learning a domain? Because systems don't

exist in a vacuum, you know? You will

have agricultural systems that are very

specific to how the agriculture industry

works. You You will You will have If

you're in a legal industry, like it is

based on whatever country you're

operating in. If If you're in a legal

tech startup and healthcare, a

healthcare tech startup looks very

different in the US versus like the UK

versus in Romania, etc. The people who

are who are great system thinkers in one

domain often are are they just really

understand the domain. And you know,

payments is one example where I worked

in, which is very interesting complex

Once Once you get into it, like people

start to move around in it because you

go there. So, I wonder if it's There's

There's There's abstract level system

thinking, but there is also becoming a

domain expert. And somehow they kind of

overlap as well cuz if you are a domain

expert, you must understand the system

of that domain. And maybe if you

understand multiple domains, you can get

better at abstract level system thinking

as well.

>> Yeah, no, I completely agree with that.

And I think for me it's definitely hard

to like quantify and articulate because

it's very kind of like vague and I think

you're definitely right though that like

the the skills, the the hard skills,

like the knowledge and like the details

of like certain industries and things

like that that definitely matters. But

I don't know. I guess like when I think

about it, I think of it maybe you know

people like this as well. Like there's

certain engineers that are like they

could go from one domain to another and

you just trust them. Like you just know

from working with them they're smart.

Like they think in a certain way where

like they could go from payments to like

some completely other industry, real

estate or something. And

there 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 I can't probably articulate

it super well, but I think a lot of the

things that people might say that like

oh, it was a waste of time to learn this

subject cuz I didn't actually use like

those details on the job. I think that's

wrong way to think about it. And I think

that's what a lot of people are doing

now with AI. Like hey, what what if I'm

not going to be writing for a loops a

couple years from now. Um I don't think

those things are a waste of time.

>> It sounds like it sounds like you're

saying that it's

you don't think it's a waste of time to

go deep and understand things.

>> Yeah, absolutely.

>> Especially when it's hard to do so.

>> Absolutely, yeah.

>> Let's talk about the hiring bar at at

Fang and companies

the the the big tech companies. A lot of

people are using NEET code to prepare

for these interviews. You're getting

feedback from them of you know, like

they will they will write to you when

they succeed or they will write in

frustration after many months they

haven't. So you get a bunch of signal

here. What are you seeing in terms of

the just the algorithmical part, you

know, the coding interview? Like are

things staying the same, getting harder,

getting easier?

>> In terms of the format, like especially

like at the early levels like juniors

and stuff, it's still a lot of like

algorithms and data structures, the

format itself. I've definitely seen, I

think, anecdotally, like people are

mentioning that it's getting harder. At

the same time, from the people who do

pass the interviews, they still, like at

at least at big tech companies like

Google and stuff, I'd say the difficulty

is not that different from what it was

before, at least in the US. I think it

varies by countries. Like, you'll see

like some some countries, like India,

it's very different. Everything's pretty

much algorithms there. It's like leak

code hards and super hards and stuff

like that. But, in the US, I don't think

it's that crazy, but it's

uh

yeah, it's not too crazy.

>> Yeah, but I I I guess like, you know,

going without a without any support like

in a whiteboard, it's so it's so hard to

prepare for that. It it it's it's never

been easy.

>> Yeah, absolutely. And I think the the

one thing that's happened a lot is

people like there's been cheating tools

for interviews. And so, we've had like

yeah, mostly remote interviews for the

last like 5-6 years, and that's been

changing a bit. I think Google has

pretty much gone to on-sites at this

point, back to the traditional

whiteboard format. And they'll let you

code on a laptop if you want to, as

well, but it's going to be in person.

Somebody's going to be watching you

code, and you're probably not going to

be able to cheat your way through that.

>> What are interview formats that you're

seeing, you know, where we're talking

about other companies, especially

smaller ones, experimenting? What are

interview formats you're you're seeing

or you think it they're actually kind of

promising? Like, if you were running a

small smaller mid-size company, you

might actually consider instead of the

And I you're talking about against

yourself here. Like, against but but if

you had to throw away the the the DSA

interviews, what is giving promise,

especially with AI as a as 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 and you saw how they

performed. And what I've spoken to a lot

of companies about the last week is that

there

a lot of small companies that can get

away with it are doing like trial

periods. It could be a few days. It

could be like a month. It could be even

a couple of months, kind of like an

internship. And I've spoken to other

companies that say that that's difficult

for them because if you're hire if

you're trying to hire somebody who

already has a job, that's not going to

be feasible. You can't really do that.

But I've, believe it or not, have leaned

in that direction where I can get a

sense of somebody's lead code abilities

pretty quickly. Like I'm not going to

spend four interviews going through and

asking somebody data structures and

algorithm stuff. I just have them do

work that might be similar to something

I'd give them on the job or even just

have a conversation with them. See how

they think. Like can they think through

tradeoffs? I don't even care about what

answer they give me to a problem. I care

about like what's like why did they say

that? Like what what can they say? Is it

just something that they like saw in

like a ChatGPT prompt and are just

regurgitating it or can they actually

like talk through it? And and then when

you look at like the work that they're

doing, same thing. Like

I ask them about it. Like why did you do

it this way? Like what what what's good

about this? Like what's bad about this?

What could be improved? And I think it's

a hard format to like scale

for big companies. That's why I don't

think that that's what's going to happen

in terms of like big tech. But it's

worked for me. It works for smaller

companies. But once you get to a certain

size, it's harder to do.

>> Yeah, cuz you're you're basically people

are doing the work and it doesn't matter

what tools they use. In fact, if if now

everyone's using, you know, like AI

agents, then yeah, they're using it as

well and you actually get the signal of

how they're doing compared to others.

Interesting because one type of company

that doesn't really have trouble hiring

is the one ones who are working in open

source. And they will often end up

hiring the people who are contributing

to their repos and adding all the

features already. And you know, the

conversation will probably be more of a

soft skills conversation cuz like yeah,

we're seeing your work. Like you've been

selflessly pushing features to our our

product. Awesome.

And I guess that's kind of the upside of

open source.

>> I think Dax mentioned this because I was

speaking to a bunch of people that like

work with him that that they just got

that they were either like contributing

to open code already or Dax like knew of

them from open source work that they had

done on projects of their own and they

just got a DM from him and they're like

and he's like, "Hey, would you be

interested in working?" And so they

already had this work that they could

showcase and it's like if you if you're

doing things in public uh people can get

a pretty good understanding of like how

you work.

>> Speaking of how you work at

at Neatcode with your business, you and

your team, how do you work? What tools

do you use and how much code do you

actually manually write these days if

any?

>> Yeah, so I would say over the last 6

months actually we've been cranking a

lot of features out a lot of uh code

out. Most of it has been written by AI

at this point. And before that really

wasn't the case. I was actually a really

big AI hater for a long time and people

still sometimes think I am and sometimes

if I'm like pro AI they're like,

"Neatcode, you changed. Like what

happened? Like now you're an AI shill."

But it's not. Like I just try to be

pragmatic about it because I think

before I was still using the tools but

they just weren't as good. And now

they've gotten to a point where the work

that I'm doing which is mostly CRUD,

usually there's not that much crazy

interesting stuff other than like the

code execution service. That's probably

the most interesting one. But I'm using

like pretty outdated tech even. I'm

using Angular on the front end, a Google

tool that nobody likes. And I'm using

Firebase which isn't horrible. It gets

the job done but it's pretty it's a

little bit outdated at this point. I'm

using Google Cloud and TypeScript. But I

would say initially actually like the

first few years when I was writing most

of the code very very bad code quality.

I used TypeScript but I was not using

like real TypeScript. I had a lot of

any. Yeah. I had a lot of bad code. I

was putting inline CSS. I was just doing

all sorts of stupid stuff just to get

stuff done as quickly as possible

because I I I knew the entire code base.

I knew like this like certain tech that

I can just deal with and so that was a

trade-off for me just to move quicker.

But with AI now actually, I've gone back

and I realized that that trade-off was

so worth it because I cleaned all of

that up with AI because that's what it's

for. Like it can

clean up a lot of like sloppy code, it

can refactor a lot of things and if I

really wanted to now, I could probably

migrate to other tools very quickly with

AI. So just to go back to the

trade-offs, I think it's just about

thinking like you might make the wrong

decision, but even if you make the wrong

decision, you can go back and then try

to correct it just kind of by thinking

about it.

>> He sends a post a bunch of her hot takes

on social media as well. I don't know if

it's like a 2:00 a.m. thing or

But well one of them you said is as I'm

quoting you, and now in 2026, it's never

been easier to build things, but I would

say that it just makes 10 times harder

to actually build value.

>> Yeah, I think

because it's so easy now to implement a

lot of things

and people weren't implementing those

things before because they just weren't

worth doing. Like in my case, I went to

the code quality example. I think that

was worth doing because it matters, it

can help you go faster, it's more

maintainable. But in terms of like

features, like a website like you can

just throw features in there nowadays

that nobody really cares about and you

can and you can do it so quickly. Like a

new feature every single day, but do

people actually care about that? Is that

making it better? It could be making

things worse. It could be making things

more confusing. You have like things

that are cluttered, you're maybe making

the site perform really slowly now with

all these features you're adding that

nobody's even using. And so I think

speed matters in business, but I think

decisions matter as well. If you're

going so fast, you're not measuring the

impact of the changes that you're

making, you don't have time to do that

cuz you're just focused on shipping. And

then things regress and things get worse

and we've seen that at Anthropic

recently, the last like month or maybe

more than that where things have

regressed and I think just a couple days

ago they put out like a blog post

acknowledging that finally but it

for them they were just moving so fast

that

they did not notice like I saw Boris

saying like he was replying to a lot of

comments asking like we haven't really

noticed this like why is everybody else

noticing it and and now they have and I

think it's again just goes back to

trade-offs like now that maybe they've

realized like okay maybe they should

slow down a little bit focus more on

quality and stuff like that or maybe not

but

>> I guess it does give a little bit of

relief that you know like we knew like

pre AI it was pretty clear that if you

move fast you typically you often break

things you know Facebook even had this

famous motto and so or you can be more

deliberate and break fewer things but

they're just almost at this slider like

how fast you move or how reckless you

are versus how stable things are and it

was kind of true and now with AI we for

a while thought like well you know maybe

this is not true maybe you can move fast

with quality but we're seeing with

Anthropic like they're moving fast and

they're breaking things and I mean

their business is growing don't get me

wrong but but still like I guess this

truth did not change because of AI

>> Yeah it's funny because even OpenAI they

did like Sora now they're shutting it

down because they realized like okay so

Sora is the social network yeah yeah

yeah the AI videos like these cat videos

that you're seeing all over the place

and so they realized like actually like

they're doing too much like doing less

things now and now they're kind of

refocusing on like coding in a smaller

set of things that's actually producing

more value now they're kind of going the

Anthropic route where Anthropic is going

like pretty quickly but they they were

focusing mostly on coding and so I think

that's interesting as well to see that

like actually playing out at the highest

of scales that like this uh like the

fastest growing companies in the world

like OpenAI are even doing this like

they are not like trying to do

everything they're they're refocusing

now and trying to maybe slow down a bit

>> This is a bit con contradictory though

like we're we're we're almost saying

that well, maybe one thing we're

learning

observing AI that focus is more

important than executing quickly on a

lot of things.

Wow.

>> Yeah, it's funny. It's like like I think

even the the paper that started it all

like the Transformers paper was titled

like attention is all you need where it

was funny it was like focusing on like

the certain tokens, the relevant tokens

like mattered the most.

>> Yeah. Well, one one interesting

experiment you did is you did a redesign

contest for

neatcode or I think the the site. You

offered $2,500 for whoever submits a

redesign. Can you tell me how that went?

>> Yeah, so I'm still going to evaluate the

results, but so far from what I've seen

it's been a little bit disappointing.

I'm going to try not to get like too mad

at anybody or make it personal with

anybody, but it's very obvious to me

that practically all of the submissions

are created with AI, which is fine. Like

if you're going to use AI that's

completely fine. But again, like with

the few people so far that I've spoken

to and asked them questions about okay,

like your design like it looks like you

made certain choices, right? You you

moved some buttons around, you removed

some buttons, you you removed some

content, you added certain content. Why

did you do it? Like what's the pros and

cons of like maybe doing it this way?

They can't answer it. And if they do

answer it, it's clearly like a very

vague answer where they didn't think

about it. Like me looking at their site

for 5 minutes, I can articulate things

about their design better than they can.

And it's just disappointing. It's like

I don't think that's like a matter of

intelligence. I don't think it is. I

think it's a matter of like effort and

caring and probably skill set as well.

Like if you're if you just have the

skill set of like designing things.

Uh but but I don't. I'm certainly not a

designer. But like in terms of a site,

whatever like the business is, you

should be able to say that okay, so like

this is about coding interviews and

we're trying to maybe

show people that this is interesting or

trying to explain it in a very clear

way. Nobody can say that. They're just

focused on like how pretty the design

looks. They're like, "Oh, the the colors

on this like the styling looks crazy."

But, that's not what I care about.

That's not what most people care about.

Like, nobody cares how pretty a site is

if they don't really understand what

it's for or like what value it's going

to give to them. I think that's what

like UX is about. It's not about like

how pretty something is. But, I guess in

all in all fairness, right? Like, this

was a contest

>> Yeah. Where you're like, "Okay, if the

winning design will get $2,500." I guess

it kind of flips the incentives a little

bit because this doesn't mean that you

are paid $2,500 to create a redesign. It

means that if you win, you could get

that. And of course, the more the more

the more people submit something, the

the lower the chance. Therefore, if I'm

just being logical here, like the effort

that's worth me putting into it is let's

say maybe if it's like 10 contestants,

it's like maybe $250 or like if it's

$125. So, in the end, of course, you

just do a prompt, you give it to AI. And

I I guess what you're seeing is you're

getting a lot of low effort submissions.

Uh

and you're seeing there's like not not

up to par.

>> Yeah, I thought that a contest would

have been the right way to do it because

then I don't have to like hire, I don't

have to like filter people and stuff

like that. But, in hindsight, I think it

probably wasn't. I probably should have

just found like and maybe even just a

small pool of people and then just paid

them up front and then just saw the work

and then maybe chosen based off that

because I think there has been like a

lot of low effort. It's been

disappointing to be honest with

>> Well, you you live and learn. But, but I

guess it it does prove that just giving

a prompt to an AI which is low effort,

low cost, it will not result in magical

effort, especially not with design.

>> Yeah, I think so. And I think it's funny