AI can pass the assessment. You still have to survive the interview.

Spend six, eight or ten years inside one company and you become excellent at its problems. You know the module nobody wants to touch, the API that behaves differently under load, the migration that never ends.

Meanwhile the wider platform keeps moving.

If you are on iOS, another WWDC passes. Swift changes. Concurrency changes. SwiftUI changes. You save three sessions for later and go back to the release.

If you are on Android, Google I/O comes and goes. Kotlin moves. Compose moves. Coroutines, lifecycle, persistence and background work keep evolving while your actual product still needs shipping.

Later rarely comes.

Not because you stopped caring. You have a production incident, a roadmap and a life. You became extremely good at the engineering your company pays you to solve every day.

Then you find the company you actually want. You fix the CV, apply, get the reply and receive the part almost every experienced engineer hates after a full working day: a technical assessment.

You already write software for a living. Now you are being asked to build another small app, call an API, persist data, add tests and prove that after ten years you still know how to code.

AI is sitting right there.

So you use it.

The prompt is good. Very good, actually. The result comes back cleaner than expected. Modern Swift or Kotlin, tests, error handling, concurrency, sensible naming. Maybe an abstraction or two you would not have written yourself, but nothing looks obviously wrong.

You run it, change a few details, submit it and get on with your evening.

Using AI was not the mistake.

The mistake was letting AI understand your assessment better than you did.

Did you go through every important decision afterwards? Why does that layer exist? Who owns the state? What really happens after cancellation? Which assumption depends on the lifecycle behaving exactly as expected? What happens offline? Which abstraction would you delete? Which part would you refuse to merge if this were your production code?

If the answer is yes, good. You used the tool properly.

If the answer is "mostly", that word can become expensive.

The technical meeting starts normally. The interviewer is another Senior or Staff engineer, someone who probably spent yesterday dealing with production failures very similar to yours. Then they start pulling on the code.

On iOS, the conversation may move through Swift concurrency, actor isolation, cancellation, state ownership, lifecycle or the difference between code that is technically safe and behaviour that is actually correct.

On Android, it may surface through coroutines, Flow, Compose state, lifecycle, persistence, background execution or what happens when the process disappears underneath the architecture you just described.

Different APIs. Same interview.

Why does this state live here? What exactly does that concurrency mechanism guarantee? What does it not guarantee? What survives process death? Why does this abstraction exist? What would you remove? Would you ship this?

None of those are trick questions.

That is what makes them dangerous.

At work, nobody asks you to explain concurrency in sixty seconds. They tell you payments occasionally happen twice or local data disappears after reconnecting. You have logs, source code, tools and time. The interview compresses years of that judgment into minutes and asks you to make it visible immediately.

If part of the reasoning in the submitted code was never really yours, the gap appears fast. I have watched candidates start inventing explanations for their own submissions. I have watched connection problems arrive at remarkably convenient moments. I have watched people leave coding sessions once the discussion moved past what they could defend.

The code looked Senior. The conversation did not.

This is the part I think many engineers get wrong.

AI did not suddenly make Senior and Staff engineers less valuable. It made polished implementation less impressive by itself.

Experienced engineers still write code, but the expensive part is the judgment around the implementation.

Can you review code that compiles and still say it is wrong? Can you see that a concurrency model removed one race while leaving the product ordering broken? Can you find the lifecycle assumption hiding inside a clean solution? Can you reject an elegant abstraction because the problem does not deserve it?

Can you look at green tests and say: "I still would not merge this."

Then explain why.

That is the signal.

And this is not only a theoretical argument about where interviews might go. In a 2026 ExperiencedDevs discussion, hiring engineers described take-home assignments being effectively one-shotted with AI, while other interviewers described shifting more evaluation toward reviewing code with candidates, finding defects and asking them to defend choices. The discussion is here.

It makes sense. If a polished artifact can be produced cheaply, the interview has to find out whether the engineer behind it owns the decisions.

The old interview-prep model was heavily about finding the answer.

That is no longer enough.

You need the second question and the third. What happens when the happy path disappears? Where does the guarantee stop? What tradeoff did you accept? What would make you choose the opposite design? What changes when the interviewer is evaluating Senior judgment instead of checking whether you know the definition?

That is the reason I built The iOS Interview Blueprint and The Senior Signal: Android Interview Blueprint.

Not because the internet needs more Swift and Kotlin definitions. It has enough.

The useful part is seeing the current interview surface, the questions, the follow-ups and the expected answer depth in one place so you can find the rusty parts before another engineer finds them for you.

For iOS, that means the modern loop from concurrency and SwiftUI through architecture, persistence and system design. For Android, it means Kotlin, coroutines, Flow, Compose, lifecycle, persistence and the same shift from knowing the API to owning the system.

Different platform. Same uncomfortable moment.

You give the first answer. The interviewer looks at you and asks:

"Why?"

That is the moment you should prepare for.

Because AI can help you get the code through the first door.

You still have to be the engineer when the interview starts.