I have taken somewhere around 1,000+ developer interviews. First as a tech lead in my first job, then as CTO of MangoCoders. For most of those years the interview was a known thing. You knew what to ask, you knew what a good answer sounded like, and you could tell in forty minutes whether the person would survive on a real project.

That interview is dead. I found out the hard way.

The Hire That Broke My Interview

A few months ago a client came to me with a very specific requirement. They wanted a full-stack developer for a team lead role, and they wanted someone who could code without AI. Not because they hate AI. They just wanted to know the person actually knows the work.

So we ran the interviews. Five years experience, ten years experience, good CVs, good companies. And almost every single one of them used AI. Not occasionally, as the default. Take away the tool and a lot of the "senior" evaporated.

I wasn't angry at the candidates. I was angry at my interview. It had stopped measuring anything.

How We Used to Interview

For a web developer role the old process was long and layered. Start with OOP. Then web-specific questions: HTTP, sessions, cookies, security basics. Then framework-specific questions. Then MySQL: joins, indexes, a slow query to fix. Then some DevOps.

Every layer was really asking the same thing: do you know the syntax and the concepts well enough to produce working code?

That was a fair question in 2015. In 2026 it is a useless one, because producing working code is exactly the part AI made cheap.

Code is now the cheapest thing in software. Logic, understanding, and judgment are the expensive things, and they are the only things worth interviewing for.

Code Is Cheap. Logic Is Not.

Here is one scenario I now ask every candidate:

"I need authentication and authorization for my web app. Walk me through the flow. How would you do it?"

No syntax. No framework. Just the flow.

Most candidates gave their own version without reaching for AI, and that was fine, that is what I wanted. But something else stood out. In the old days, a candidate would take a moment on a hard question. They would think. Now a lot of people filter themselves out in seconds with "I don't know that one." No attempt. No "let me reason about it." The thinking muscle has gone soft because the tool always answers first.

That instant give-up is the biggest red flag I see today, and it is invisible in a syntax interview.

Ask for Flows and Use Cases, Not Syntax

So the new interview is built on scenarios. I describe a real situation and ask the candidate to describe how they would handle it. Some of my regulars:

• "Describe how you'd integrate Stripe." Not the code, the flow. Where does the webhook go, what happens when a payment fails, how do you handle a refund.
• "Describe how you'd implement white-label for this product." This exposes whether they have ever built for more than one customer at a time.
• "You've lost the EC2 key pair for a production server. What do you do?" There is no library for this. Only experience answers it.
• Pick any flow and start pushing on edge cases. What if the token expires mid-request? What if two admins edit the same record? What if the third-party API is down?

I am not grading the answer as right or wrong. I am reading their mind. Two things matter:

• Do they try, or do they give up? A candidate who reasons out loud through a wrong answer is worth more than one who says "I'd ask ChatGPT."
• Do they follow AI, or do they lead it? The senior developer in 2026 is the one who tells the AI what the decision is. The junior is the one who waits for the AI to decide. You can hear the difference within a couple of scenarios.

Stop Running a Q&A. Run a Discussion.

The biggest change is not the questions. It is the format.

The old interview was question, answer, next question. That format is now easy to game: a candidate memorises answers, or worse, has a second screen open. Fixed questions also close people up. They sit there waiting for the next one, giving you the shortest safe answer.

Now I run the interview as a discussion. I put a flow on the table, say authentication, and we talk about it like two developers on the same team. They give their version, I push: "okay, and what if the token expires mid-request?" They answer, I go one level deeper, or I disagree on purpose and see if they hold their ground or fold. Then we drift into a related flow and do it again.

My job in that room is to be an observer, not a quiz master. In a discussion people open up. You see how they think when they are not defending an answer, whether they get curious or defensive, whether they ask you questions, and whether they can say "I'm not sure, but I'd try this." A Q&A tells you what they know. A discussion tells you who they are, and that is the thing you are actually hiring.

This is the same point I made in my last post about not being married to one model: the tool changes, the fundamentals don't. A developer who understands the flow can use any AI. One who doesn't is just forwarding prompts.

Attitude: What Happens When the AI Doesn't Give the Answer

This is the second thing I check, and it is about effort.

Every real project hits a wall where AI gives you a confident, wrong answer three times in a row. What does this person do then? Do they dig into docs, read the source, try a different approach, ask a human? Or do they stop and say "it's not working"?

I ask directly: "Tell me about the last time AI couldn't solve your problem. What did you do?" The answer tells you how far this person will go for you when the easy path is closed.

Ethics: This One Is Non-Negotiable for Me

I put a lot of weight here, more than most people expect in a technical interview.

I am looking for signs of how the person behaves in conflict. When there is a disagreement with a client or a manager, do they take a hyper decision: walk out, break an agreement, hold the project hostage? A developer with that pattern will do it to you too, no matter how good their code is. Avoid that resource.

A very practical test: ask about their current job and their notice period. If they are ready to leave their current employer without serving notice, don't be flattered that they will join you fast. If they walk out on them, they will walk out on you. Someone who won't do the decent thing for their last employer is not going to do anything special for you.

Listen to how they talk about past jobs, past managers, past clients. Respect or resentment, it shows.

Product Sense: Can They Say No?

At MangoCoders we have built 50+ products, which means we have worked with 100+ entrepreneurs. You learn how different kinds of founders think, and you learn that the most dangerous developer for a startup is the "yes sir" developer.

A yes-sir developer builds whatever you say. You say "add this feature," they add it. You never hear "this shouldn't be built," or "this should be built later," or "this will double your support tickets." They are pleasant to work with and they will quietly let you waste six months.

So in the interview I test for input. I describe a feature request and watch whether they push back, ask why, or suggest a smaller version. The developers worth hiring have opinions about the product, not just the code.

The Post-AI Interview, in One List

If you are a founder running your own hiring, here is the shape of it:

• Make it a discussion, not a Q&A. Be an observer, not a quiz master.
• Let them use AI, openly. Then watch how they use it.
• Ask for flows, not syntax. Stripe, auth, white-label, lost server keys, edge cases.
• Watch for the instant give-up. Thinking time is a good sign, not a bad one.
• Check whether they lead the AI or follow it.
• Ask about the last time AI failed them and what they did next.
• Probe conflict behaviour and notice period. Ethics predict everything else.
• Test for "no." A developer who cannot push back will cost you more than one who cannot code.

None of this needs a whiteboard or a coding test. It needs someone on your side of the table who knows what a good answer sounds like.

If You Can't Run This Interview, That's the Real Problem

Here is the honest part. A non-technical founder can read this list and still not be able to tell a great auth flow from a confident-sounding wrong one. That gap is where startups hire the wrong senior developer, pay them for a year, and find out during the first outage.

There is another option, and it is the one most of our clients end up choosing: don't run the interview at all. Work with a team that has already been through it.

Every developer at MangoCoders came through exactly the process above: the flow discussions, the edge cases, the ethics questions, the "can you say no" test. They have shipped 50+ products with us and worked directly with founders, so they don't just write code, they push back when a feature shouldn't be built. You get senior judgment from day one, without spending three months and a bad hire finding out who has it.

If you want a team like that on your project, start with a free product consultation. We will look at what you are building and tell you honestly what it needs. And if you are weighing how AI should fit into your build in the first place, our AI consultation covers that too.

Code is cheap now. Hire for everything that isn't.