Tech interviews with NeetCode

**Gergely Orosz** (0:00)
Let's separate strong engineers from everyone else.
Navdeep Singh, or as many call him, Neet, he created NeetCode, the coding preparation platform that helps countless devs get hired at Big Tech. In today's episode we cover what preparing for data structures in 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. Neet's contentious hot take that some people should just give up on tech careers, and many more. If you want to understand which engineering skills compound over a career, and the ones that AI is quietly eroding, this episode is for you. This episode is presented by Antisysys. 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 at antisysys.com/pragmatic.
This episode is brought to you by Sentry.
Sentry is a tool I used for application monitoring back when I worked at Uber, and I now use it on all my projects, including the Pragmatic Engineer backend. One new feature I'm really liking about Sentry is their Seer AI agent, which helps investigate production errors. For example, here's an actual error I had in my application. I can just ask Seer what might be the root cause, and it brings context, and it can also make a plan to fix it, all from the web interface. Oh, and it also works in Slack as well, not just the web. One place that I find even more handy to use Sentry is from Codex or Clockcode using Sentry MCP. After you hook up the MCP server, you can do some very useful things. For example, when an already resolved Sentry is to resurfaces, you can kick off an agent to investigate the 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 code repository, add Sentry MCP to Cursor, define the instruction for Cursor's agent to investigate, configure the trigger that launches the automation, and test that it all works. But once you have it up and running, you can get regressions fixed faster, while still reviewing every and all fixes. I'm not a fan of using AI tools just for the sake of it, but I really like the practical integrations where I can fix errors faster and with more context. Check out Sentry at sentry.io/pragmatic and start monitoring and fixing regressions today. Neet, welcome to the podcast.

**Navdeep Singh** (2:08)
Yeah, I'm happy to be here.

**Gergely Orosz** (2:09)
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 M1AI will be good enough to write code, coding interviews will be dead because of the day to day, we will not be writing code. While 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?

**Navdeep Singh** (2:32)
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. 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? Because there's one aspect of it, which is like, do they have the hard skills? Do they have the technical skills? Can they think? And DSA interviews were never the best for that.
Well, thinking, sure, but in terms of like, does that skill translate to what you're doing on the job? It never really translated to that. It was more about evaluating, like, does somebody think? So I think that's one of the reasons. And the second reason that's stayed sticky is that companies just have no idea how to evaluate. Like, and they probably never did. I think I was talking to a friend of mine, Steve, from Amazon, and he mentioned that, like, they 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 run the interview process, that it's just very hard to know, like, how somebody's actually going to perform on the job.