Your Company Wants You to Use AI All Day and Then Bans It in the Interview

A developer emailed me two weeks ago with a story that I have not been able to stop thinking about. He had made it to the final round at a company that, in his words, "would not shut up about being AI-first." Every job posting they wrote mentioned agentic workflows. The recruiter told him they expected engineers to use Claude and Cursor for most of their daily work. The whole pitch was about velocity, about shipping faster with AI doing the heavy lifting.

Then he got to the technical interview. No AI allowed. Whiteboard. Invert a binary tree from memory while three engineers watched. He had not written a sorting algorithm by hand in six years because, like every working engineer, he had spent those six years solving actual problems in actual codebases with actual tools. He froze. He did not get the offer.

Here is what bothers me about that story. The company rejected him for lacking a skill they had already told him they did not want him to use on the job. They interviewed for skill A, memorization of algorithms under pressure, while explicitly hiring for skill B, orchestrating AI systems and reviewing their output. Those are not the same skill. They are barely related skills. And the gap between what companies test for and what they actually want has become the single most dishonest thing in JavaScript hiring right now.

I run jsgurujobs.com. I read job postings all day. And I am watching this contradiction get worse, not better, as more companies rush to call themselves AI-native without changing a single thing about how they evaluate the humans they hire.

The Split Personality Every Developer Is Being Asked to Perform

The pattern shows up in the postings on my board constantly now. A company writes a job description that reads like an AI manifesto. Mandatory use of coding agents. Experience with prompt orchestration. Comfort reviewing large volumes of machine-generated code. Then the interview process is a museum piece from 2018. LeetCode hard. Live coding with no documentation, no autocomplete, and certainly no AI.

The developer is being asked to be two completely different people. On the job, they are a conductor who directs AI, verifies output, and makes architectural decisions. In the interview, they are a competitive programmer performing recall of data structures they will never hand-implement again. Both personalities are supposedly required. Only one of them will ever be used after the offer letter is signed.

I think this is the clearest sign that most companies have no idea what they actually hired AI to do. They adopted the tools because their competitors did. They put "AI-native" in the posting because it sounded current. But they never sat down and asked the harder question, which is what does competence look like now, and how do we test for it. So they kept the old interview, the one that measures a skill nobody uses, and bolted an AI-first job description on top of it.

The result is a hiring process that systematically selects for the wrong people. The developers who ace the whiteboard are often the ones who spent the last month grinding LeetCode instead of building things. The developers who would actually thrive in an AI-orchestration role, the ones with strong judgment and system-level thinking, are getting filtered out because they cannot recall the exact syntax of a heap under stress. I wrote about this filtering problem in a different context around ghost job postings, but this version is worse because the filter is actively selecting against the stated requirements of the job.

What This Does to a Developer's Head

There is a psychological cost to this that nobody talks about, and I want to talk about it because I hear it in my inbox every week.

When you are told that your daily job is to work with AI, and then punished in the interview for not being able to work without it, you end up doubting both versions of yourself. You are not sure if you are a real engineer, because a real engineer in the interview's definition can invert the binary tree cold. And you are also not sure if you are keeping up with the AI-native future, because the same company that demanded algorithmic recall also implied you were behind if you were not orchestrating agents all day.

This is impostor syndrome squared. Not the normal kind where you doubt your skills. The kind where the job market itself has given you two contradictory definitions of competence and told you that you need both, immediately, and that failing at either one disqualifies you. I have talked to senior developers with a decade of shipped production work who came out of these processes genuinely unsure whether they were good at their jobs. That is not a them problem. That is a broken evaluation system doing exactly what a broken system does.

The onboarding cost is real too. When a company hires the person who won the whiteboard performance rather than the person who thinks well about systems, they often discover in the first ninety days that those are different people. The new hire can pass an algorithm quiz but struggles to reason about the messy, context-heavy, AI-augmented reality of the actual codebase. I wrote about what actually happens in the first ninety days, and the mismatch between interview performance and job performance is one of the most common ways that period goes wrong.

Why Companies Keep Doing This Even Though It Obviously Fails

I want to be fair to the companies for a moment, because the reason they keep the old interview is not pure stupidity. It is fear.

The old technical interview, whatever its flaws, felt objective. You either inverted the tree or you did not. It gave hiring managers a number they could defend. When you move to evaluating judgment, system design, and the ability to review AI output well, you are evaluating something fuzzier. It is harder to score. It is harder to defend to a skeptical VP who asks why you passed on the candidate who aced the coding test. So companies cling to the algorithm quiz because it feels safe, even as they write job descriptions that describe a completely different job.

But here is what I think, and I know some hiring managers will disagree. Clinging to the old interview is not caution. It is cowardice dressed as rigor. If you genuinely believe your engineers should spend their days orchestrating AI and reviewing machine-generated code, then test for that. Give them a pull request full of subtly wrong AI output and ask them to find the problems. Give them a vague requirement and watch how they decompose it into something an agent could execute. Give them a broken system and see how they reason about it. Those tests are harder to build than a LeetCode link. That is exactly why they are worth building.

The companies that figure this out first are going to get the good engineers cheaply, because those engineers are currently being rejected everywhere else for failing a test that measures nothing relevant. I see the beginnings of this on my board. A small number of postings now describe interview processes built around real code review and real system reasoning. Those companies are quietly winning. Most have not caught up, and the ones connected to the rise of the AI-native role without changing their evaluation are the ones producing the most frustrated candidates.

How to Survive the Schizophrenic Interview as a Developer

If you are job hunting right now, you do not have the power to fix the industry's broken interviews. So let me be practical about what you can actually do.

Prepare for both personalities, separately, and do not let one bleed into the other. Yes, you still have to grind some algorithms, because the whiteboard is not dead yet and pretending otherwise will cost you offers. Treat it as a performance you rehearse, not as a measure of your worth. It is a hoop. Jump through it. It says nothing about whether you are a good engineer.

At the same time, build genuine competence in the thing the job actually requires, because more companies are starting to test for it and because it is the skill that keeps you employed after you are hired. Learn to read AI-generated code critically. Practice finding the subtle bug in output that looks correct. Get good at decomposing fuzzy problems into clear specifications. This is the real work now, and the developers who are good at it have a durable advantage that no whiteboard measures.

And when you hit a company whose interview contradicts its job description, ask them about it directly. Not aggressively. Just honestly. Ask how the algorithm round connects to the AI-native work they described. The good companies will have a thoughtful answer. The bad ones will fumble, and their fumbling tells you something important about whether they actually understand the job they are hiring for. I have had developers tell me this single question saved them from taking a role at a company that had no idea what it was doing.

The Real Problem Is Not the Interview

The interview is a symptom. The disease is that most companies adopted AI without deciding what they wanted from the humans who work alongside it.

They know AI is supposed to change everything. They have said so, publicly, in every job posting and every all-hands. But they have not done the harder work of figuring out what human competence looks like in a world where the machine writes the first draft of everything. So they hedge. They demand AI fluency in the description and algorithmic recall in the interview, covering both bets, and in doing so they select for developers who are good at neither the old thing nor the new thing but are simply good at auditioning.

The developers who see through this clearly have an edge. Not because they can fix it, but because they can navigate it without losing their minds. They know the whiteboard is theater and they perform it. They know the real skill is judgment and they build it. They stop trying to reconcile two contradictory definitions of competence and instead treat the interview and the job as the separate games they have become.

The industry will sort this out eventually. The companies testing for the wrong skill will keep hiring the wrong people until the cost becomes impossible to ignore, and then they will change. Until then, the split personality is the price of admission. You do not have to like it. You just have to see it for what it is, which is a broken system asking you to prove you are two people, when the only thing that actually matters is whether you are one good engineer.

FAQ

Why do companies ban AI tools in interviews but require them on the job? Most companies kept their old algorithmic interview because it feels objective and defensible, while adding AI-native language to job descriptions because it sounds current. They never did the harder work of redesigning their evaluation to test the skills they actually want, so the interview measures memorization while the job requires AI orchestration and judgment. The two are barely related.

How do I prepare for an interview that contradicts the job description? Prepare for both skill sets separately. Still practice algorithms because the whiteboard is not dead, but treat it as a performance rather than a measure of your worth. At the same time, build real competence in reading AI-generated code critically and decomposing vague problems, because a growing number of companies are starting to test for that and it is the skill that keeps you employed after hiring.

Is it worth asking a company about the mismatch between their interview and their job? Yes, if you do it honestly rather than aggressively. Asking how the algorithm round connects to the AI-native work they described will get a thoughtful answer from good companies and a fumbling one from companies that do not understand the job they are hiring for. That response is useful signal about whether you want to work there.