[music] Thanks to HubSpot for sponsoring this video. If you're grinding leak code 5 hours a day right now, there's a good chance you're preparing for an interview format your target company doesn't even use anymore. I recently got back from the Pragmatic Summit, a conference with 500 top engineers and hiring managers.
And I sat in a round table with about 20 of those hiring managers. We talked about how they're actually hiring engineers [music] right now. And what I heard should change how a lot of you are preparing.
The interview landscape hasn't just shifted, [music] it's fractured. There is no single playbook anymore. So today, I want to walk you through the main interview modes companies are using right now, what hiring managers are actually looking for, and the single most underrated thing you can do to avoid wasting months of prep.
But first, let's talk about why everything got so confusing in the first place. You've probably seen the takes online. Lead code is dead.
No, leak code is more important than ever. Just build projects. No, projects don't matter.
You need system design. And the list goes on. It's completely contradictory.
But the thing is, it's contradictory for a reason. The industry has no consensus right now. According to Coderpad's 2026 state of tech hiring report, when you ask companies about their AI policy for interviews, about a third ban AI entirely, nearly half allow it in some form, and the rest decide case by [music] case.
And here's where it gets messy. Leit code style algorithmic questions are also still common. 43% of technical assessments still include them.
But at the same time, the hacker rank developer survey found that 78% of developers say these assessments don't reflect real world work. Even more so in the age of AI. 56% say algorithm questions are straight up irrelevant to their jobs.
Meanwhile, pair programming, system design, and real world scenario simulations are all showing up more and more, each at around 30 to 38% of assessments. So, what does this actually mean for you? It means company A might give you a leak code hard and expect you to solve it in 45 minutes with no AI.
Company B might send you a take-home, tell you to use claw or cursor, and then grill you in a live session on what you did and whether you actually understood what the AI implemented. Company C might skip all of that and ask you to walk through one of your past projects. These aren't variations on the same test.
They are fundamentally different exams. And that's the thing most people miss. The landscape didn't shift in one direction.
Different companies are playing completely different games. And if you don't know which game your target company is playing, you're basically studying for the wrong exam. I'm going to break down the four interview modes you need to understand because once you understand them, the whole situation starts to feel a lot more manageable.
And later, I'll show you the simplest trick that can save you months of wasted prep time. Now, one thing that kept coming up at the summit, especially from the companies that do allow AI in interviews, is that they're not just checking whether you use AI. They're watching how you use it, which tools you use, and whether you know what those tools are actually good at.
So, the real question becomes, which AI tools should you actually be using? Right now, the two big ones are OpenAI's Codeex and Claude Code, and they work very differently. HubSpot put together a free guide called the AI coding showdown that compares them side by side.
It's based on real testing where someone built the same apps in both tools and tracked what happened. What I found really useful is the decision framework. It breaks down when to use codecs versus clawed code based on what you're trying to do.
Like if you need to rapid prototype five variations of an idea in 10 minutes, that's a different tool than if you're building something production ready where you need clean, maintainable code. And it comes with 10 example prompts organized by use case. So you can test both tools yourself and figure out your own workflow.
If you're preparing for any of the AI native interview formats I'm about to walk you through. Knowing the difference between these tools is really important. The link to download it for free is in the description.
Now, let's get into the four actual interview modes. Let's start with Mode, the AI arms race. Some companies are still firmly in the no AI period camp.
Google has reportedly told candidates that using AI during interviews can lead to disqualification. Amazon's assessment logs your browser activity, restricts copy paste and lets you use public resources but not anything behind a login which rules out most AI tools. These companies are trying to preserve the old signals.
Can you write correct code from scratch under time pressure? But here's what's interesting. Even the companies holding that line are dealing with chaos on the other side of the table.
At the summit, hiring managers described what they called an AI arms race. And it's not just about candidates cheating. It's the entire funnel.
You've got AI generated résumés being submitted by bots. Those résumés get screened by AI on the company's end. Candidates use AI to pass online assessments.
And then, I am not making this up. One hiring manager described a case where they hired someone through remote interviews and a completely different person showed up to work on the first day. So, now you're seeing companies add these weird verification layers.
Some are asking candidates to record Loom videos to prove they're real people. One company requires you to submit a resume via a post request, which is an obvious filter. If you can't make a simple API call, they don't want to talk to you.
Others are leaning more on referrals and networking, basically routing around the broken application pipeline entirely. If you're targeting these companies, traditional interview prep still matters. You need to be able to solve data structures and algorithms problems without AI assistance.
That hasn't changed. But even these companies know that the model is not long for this world. the proctoring keeps getting more intense specifically because the old system can't keep up.
So that's one game, but there's a very different one being played on the other side. Let's talk about mode B. At the opposite end, you've got companies that don't just allow AI, they expect you to use it.
Meta started piloting AI enabled coding interviews where candidates are given an AI assistant during the session. The reasoning is pretty straightforward. If AI is part of the actual job, why would you evaluate someone without it?
But what I heard at the summit went even further than that. Multiple hiring managers described a two-stage approach that I think is going to become really common in the future. In the first stage, they give you a take-home assignment and explicitly tell you to use AI.
Then in stage two, you come in for a live pair programming session and they ask you to explain and extend what you built, like add a feature or refactor a section. This is where they actually learn about you because now they can see whether you understand what's in that codebase or whether you just accepted whatever the AI spit out. [music] They're looking at prompting quality, spectriven development, code review instincts, testing strategy, and debugging.
And I swear multiple people said this. They're looking at whether the candidate has the patience to actually read everything. Seriously, [music] in a world where AI can generate a thousand lines of code in seconds, the differentiator is whether you'll actually slow down and read [music] it.
Whether you'll be able to catch the subtle bug, notice the security issue, or recognize when you need to push back on what the AI approach has done. They're basically just looking for the person who's not outsourcing their thinking. So AI native doesn't mean let AI do the work while you take a little nap.
It means can you direct AI, verify its output, catch its mistakes, and explain what's happening. And honestly, that's a skill most candidates are not practicing well even in their personal projects, which matters a lot because of this third mode. In some companies, your GitHub has basically become your interview.
Rather than testing your live coding skills, they're asking deep specific questions about your actual projects, like why did you choose this architecture over that one? What would you do differently? Now, similarly, one hiring manager said he looks at commits on open source repos and tries to headunt directly from there.
He's not even posting jobs anymore. So, obviously, this changes the preparation plan entirely. If a company is evaluating you this way, your portfolio is your interview prep, but it also means shallow tutorial copy projects aren't going to cut it.
Not that they ever really would have. And neither will fancy things you vibe coded and don't understand. They want to see real decisions, trade-offs, and your thinking.
If you're aiming for companies like this, the best thing you can do is build projects you genuinely care about, make thoughtful commits, and be able to talk about your choices like an engineer, not like someone who followed a tutorial or had AI do everything for them. You need to demonstrate that you really understand this at a deep level, which is exactly what the last mode tests for, too. This one is specific to my world, machine learning and data science.
Despite everything I just said about interviews becoming more practical and AI enabled, if you're interviewing for ML or data science roles, there's still a decent chance that someone's going to ask you to implement an algorithm from scratch, like logistic regression or C means clustering. This actually hasn't changed as much as the rest of the landscape. And I think the reason is that these roles genuinely do require you to understand what's happening under the hood.
So if you're in this space, classical ML fundamentals still matter. You can't skip them just because the software engineering interview world is evolving. All right, so that's four different things you could be studying for.
You obviously can't prepare for all of them at the same intensity at the same time. So, what should you actually do? Despite all the disagreement on how to interview, there was a surprising amount of agreement on what these hiring managers are actually looking for.
The phrase I kept hearing was T-shaped engineer. This basically means that you have deep expertise in one area, but you're capable across the whole stack. Multiple people said it's no longer considered reasonable to only do frontend or only do backend.
Everyone's expected to have at least a working knowledge of the full stack along with the specialization. They're also all converging on a few things that matter regardless of interview format. The first is product thinking.
Not just can you build it, but do you understand why you're building it? Can you reason about what the user needs? Can you push back on a spec that doesn't make sense?
This is a huge differentiator and most candidates don't practice it at all. Next is comfort with ambiguity and chaos. This is especially relevant for AI adjacent roles where your systems output is probabilistic.
Things will break in weird ways. The people who can operate calmly in that environment are the ones who do better on the job. And as always, communication.
Can you explain your trade-offs? Can you articulate why you made a decision? This shows up in every interview mode.
If you can't communicate your thinking, it doesn't matter how good your thinking is. These skills are kind of format proof. The specific interview structure is just the surface layer.
Underneath it, every hiring manager is asking the same fundamental question. Can this person actually do the job, think clearly, and work effectively with the tools and people around them? So, given all this, four different interview modes, a bunch of underlying skills, and limited time to prepare, how do you actually handle it?
Here's the single most underrated strategy I've found. And honestly, it's almost silly how simple it is. Just ask the recruiter.
I know it's not exactly the secret hack you were expecting, but hear me out because almost nobody actually does this well, and it can really help you out. I'll tell [music] you a story. I was preparing for an interview once and I asked the recruiter what to expect for the coding round.
She said they were testing production level coding skills. Okay, cool. Sounds practical, right?
But I asked what that actually meant and she said leak code. And I was like, oh, so literally the opposite of production level coding. Good to know.
And that right there is the point. If I hadn't pushed past the vague answer, I would have spent my prep time completely wrong. I would have been practicing system design and debugging real world problems, which are great skills, but they're not what that particular company was testing.
There are now so many possible interview formats that blind preparation is the least efficient strategy you can use. But companies know what they're testing. They've designed their process, and most of them will tell you if you ask the [music] right way.
Here's how I'd frame it. I want to come as prepared as possible. Since there are so many different focus areas in interviews right now, I'd really appreciate any guidance on what to prioritize for this role.
That's it. [music] You're not asking them to give you the answers. You're showing that you're thoughtful about your preparation and that you want to make the most of the opportunity.
If the company wants you to succeed, and they should. That's the whole point of hiring. They'll give you direction.
If they refuse to tell you anything about what the interview looks like, honestly, that tells you something about the company. A place that won't help candidates prepare well is probably a place with other communication issues, too. Once you know the format, you can prepare a lot better.
But what if you don't have an interview lined up yet? What should you be doing right now? Here's how I'd think about it.
You can't prepare for every interview format at once, but you can study in a way that covers the most ground. Ideally, build something real with AI and make sure you understand every line. This prepares you for take plus extension formats.
It gives you GitHub projects you can actually talk about. It develops the AI native skills that companies are specifically screening for. And the act of building something endtoend exercises product thinking and system design instincts naturally.
And keep a baseline of data structures and algorithms. You don't need to grind five hours a day, but you should probably stay sharp enough that Elite Code Medium doesn't ruin your day. The point is, default to building stuff.
It's the highest overlap preparation across every mode I described. And when an interview does come up, that's when you get specific and ask the recruiter exactly what to focus on. Coding interviews aren't dead.
They're different. And the people who are going to thrive in this new landscape aren't the ones who memorized the most leak code problems or built the flashiest portfolio. They're the ones who figured out which game they're actually playing and prepared for that.
