Last week, Meta announced layoffs of 8,000 employees — 10% of the company. Zuckerberg's internal memo read: "success isn't a given in the AI era."
The tech industry has cut over 50,000 positions in Q1 2026 alone, with April 2026 being the worst single month in two years — over 45,000 positions eliminated.
The industry is firing people while simultaneously pouring $725 billion into AI — the entire logic of hiring and firing is being rewritten.
The ones getting cut aren't the people using AI. They're the people being replaced by AI. The real essence of this reshuffle is that the "AI immigrant vs. AI native" generational divide is being accelerated into visibility — what Taiwanese tech veteran Lee-Feng Chien calls "the lost generation" vs. "the 1% super-humans" are being sorted into different lanes.
Why am I opening with these numbers?
Because the interview I'm about to tell you about happened during the same window of industry reshuffling — and what I saw through it has direct relevance to that reshuffle.
Can a job interview you didn't pass teach you more than one you did?
Some time ago I went through an interview loop for a Founding AI Engineer position at a YC-backed AI startup. No offer.
What I want to talk about isn't "why I didn't get the offer."
What I want to talk about is: what this loop showed me is that "interview" itself is being redefined in the AI era.
Why an independent contractor was interviewing at all
Quick context, otherwise this won't make sense.
I work independently across multiple client engagements now. Several lines going at once — an AI workflow rollout for a traditional manufacturing client, a research project for an academic association, a leadership training engagement for a media company, a few advisory gigs.
When the recruiter reached out, I wasn't actively job hunting.
But the role was Founding AI Engineer, YC-backed, fully remote, equity, the title was right.
I took the loop for two reasons.
One, I wanted to see how the market currently reads someone who left a corporate role, went independent, and grew their AI product-building skill set on real client work.
Two, I wanted it as a hedge. If something stalled on the consulting side, this could pick up the slack.
Not a must-have. Not a casual exploration either.
I prepared for almost a month. Cleared a few stages. In the end, no offer.
Why I'm writing about this particular interview
Let me clear something up first — because it shapes how you read this essay.
I'm not trying to ride on the YC brand.
I'm also not writing the "bad company rejected me, let me complain about them" piece.
I'm writing about this specific interview because both sides have substance.
On their side: YC-funded, the CTO doing the interview himself, a team with real prior experience building and shipping products to real users. Not a first-time founder learning on me.
On my side: a year of independent consulting across 5-6 companies, spanning 5 sectors — education, traditional manufacturing, medical, publishing, and academic-association research — with 8+ active projects; prior international engineering offers; a track record of work that passed muster. Not a beginner either.
This was a conversation where neither side was lightweight.
And I didn't pass.
If the essay setup were "strong company + beginner candidate" or "weak company + strong candidate," it would collapse into single-direction narrative — either lesson or complaint.
But when both sides have substance, "not passing" becomes a deeper question: in a fair fight between two reasonably matched senior players, what was it that I couldn't keep up with?
That question is what this entire essay is exploring.
I also have to admit something else — what this interview exposed is not "I'm unfamiliar with startup environments."
Earlier in my career, I worked at a Chinese-language education platform from its early days through its 10-year transformation — across roles from individual contributor to senior leadership. Startup environments aren't new to me.
What this interview actually exposed was two "languages" that are both not yet at the level:
- The digital language: in the AI era, how do I read the air, the signals, and the quality the other side is looking for
- The physical language (English): how do I fluently output what's in my head, and play it off the other person's signals in real time
Neither language is at the "complementing each other" level yet — that's what this interview made me see clearly.
I'm writing about this specific case because it made that gap very concrete.
Finally, since this essay doesn't have a "who's right" conclusion — only framework — the only thing that helps you decide whether this is worth reading is probably this context: roughly what kind of opponent, what kind of arena, what kind of conversation quality.
I'm laying that out here.
The rest of the reading, I leave to you.
What I originally wanted to write
After the rejection, my first instinct was to archive everything.
Resume, company research, case studies, training logs, mock Q&A, interview process notes — I moved the whole prep folder into _archive/, tagged it rejected, so I could reuse the materials next time a similar role came up.
Then I sat down to write a "lessons learned" reflection post.
And I couldn't write it.
Because I kept trying to answer "where did I fall short."
The more I wrote, the more I felt that the question itself was wrong.
What actually blocked me was "my capability couldn't get through the two languages"
Their interview method itself wasn't broken.
The first part of the conversation was about my life values, my choices, why I wanted to join the company — a good opening.
What actually blocked me came later, in the skills-testing phase: at the decision points where I had to switch between "AI language" and "human language," I fell into a fog of confusion.
I had the capability. But that capability couldn't get through to the other side — not via the digital language, and not via the physical human language either.
Let me use an analogy to describe this gap.
Interviewing a senior IC (individual contributor) traditionally tested three things.
First, fundamentals — algorithms, data structures, system design. This tests "what do you know without AI."
Second, experience — what you've built, what you've shipped, what patterns are wired into your head. This tests "what patterns are loaded in your brain."
Third, culture fit — do you mesh with the team, do values align.
Combined, these three roughly composed the shape of a senior engineer.
But once AI enters the picture, the signal-to-noise on all three breaks down.
Category one — "what you know without AI" — matters less. At work, you'll use AI. Nobody is going to demand you bare-hand a binary search.
Category two — "what patterns are in your head" — becomes hard to evaluate. AI can backfill any pattern on demand. When you say you "know" something, maybe you've shipped it 100 times. Or maybe Claude walked you through it last night. From the outside, both look identical.
Category three — culture fit — is still meaningful. But remote-first, short-window interviews always carried high noise on culture, and that hasn't changed.
So what is an interview process actually able to read now?
Senior workers using AI don't even know what they know anymore
This is something I don't think enough people are talking about.
In my year of independent work, I made a weird observation: I increasingly can't tell which capability is "mine" and which is "Claude helping me."
A concrete example.
I built an AI workflow for a manufacturing client — interviews, design, build, deployment, all me.
A chunk of it was a RAG pipeline. Chunk the client's PDFs, embed, write to a vector DB, run retrieval.
If you ask me "can you build a RAG pipeline?"
I'd say yes.
If you make me bare-hand it — no Claude Code, no docs, no Google — and ship the whole pipeline in 30 minutes...
I could probably write the skeleton. But many details would stall me. Because in practice, I built it through dialogue with Claude.
So do I "know" RAG pipelines or not?
Old definition: you can write it without looking anything up. New definition: with AI, you can ship it.
These are two very different definitions. And honestly, I'm still in the transition between them.
If I can't tell the difference about myself, how is an interviewer going to figure it out in two hours?
Noise and signal both grew at the same time
I assumed AI would reduce interview noise — because if everyone uses the same tools, "raw skill" should become easier to compare.
After going through a full loop, I think it's the opposite.
Noise increased: because every candidate uses AI differently. Some use it to stitch together depth they don't actually have. Some use it to accelerate genuine depth. From the outside, you can't easily tell.
Signal also increased: because once you put someone into a "collaborate with AI to complete a task" setting, their taste, judgment, communication, structural sense — all become more visible than they were in old-school whiteboard interviews.
This produces a strange paradox:
Noise grew. Signal also grew. But both grew on the same dimension. So the relationship between "interview outcome" and "actual working ability" may be harder to read than it used to be.
It's not that offers don't matter. It's that the offer and "what you can actually ship" used to be close — now there's an extra layer of noise between them that has to be decoded.
So what actually happened in this interview?
Back to my story.
The process included a written exercise and a live build session. The whole thing felt very close to what I do daily on client work — open Claude Code, check docs, wire APIs, debug.
The output I submitted, I personally felt was production-ready.
The Last 15 Minutes — The Feedback That Was Exactly This Essay's Thesis
Before the rejection email, the CTO spent the final 15 minutes of the interview giving me closing feedback.
He said four things. Each one is worth writing down.
First, he explicitly told me: he wasn't evaluating "AI usage itself."
AI usage isn't the evaluation point anymore, he said. Everyone uses it. That capability is commodity to him.
What he was looking for was four other things — taste, judgment, empathy for the user, curiosity about the problem itself.
Second, he pointed out that I "don't start with questions, don't clarify upfront."
I received the prompt and immediately started building. I didn't take time to ask "what's the success criteria," "what kind of output are you expecting," "where's the scope boundary."
He said: in the AI era, getting aligned with the other person about what we're doing matters more than getting it done.
Third, he said my curiosity "took the better hold of me."
I thought too much, built too big, made it too polished.
What he wanted was: deliver something usable in a short window. Leave more time to discuss the trade-offs.
Fourth, he said I went into "production mode" but forgot to "engage."
I was demonstrating "I can build a complete, structured, well-typed system."
But he was waiting for me to have a conversation with him.
"I type the question into AI, AI gives the answer, I say OK, next step" — that flow doesn't let him see my judgment.
I thought I was demoing "look how good I am with AI."
What he wanted to see was "how do you think through a problem alongside another senior engineer, while still preserving your judgment under AI acceleration."
Listening to those 15 minutes, I realized something:
I had walked in with the wrong spec.
I thought the interview spec was "demonstrate my AI engineering capability."
The actual spec was "demonstrate how you collaborate with a human engineer, and how you keep your judgment intact under AI acceleration."
Both specs require AI. But they optimize for completely different things.
His feedback stung a bit. But in the good way.
Because what he said was precisely the thesis of this very essay.
He just said it in a way I couldn't unsee.
A few days later, rejection email.
I can't tell you "why they rejected me," because the feedback was framework-level, not specific. Maybe taste mismatch. Maybe they wanted a different profile. Maybe noise inside the process. Maybe a blind spot I can't see.
I don't know. And I'm not going to pretend I know.
But here's what I do see: my working capability and this interview outcome may be measuring different dimensions.
I'm not trying to let myself off the hook.
This is the observation I'm willing to sit with after seeing how AI-era interview loops play out.
But Let Me Go Three Layers Deeper — "Not Asking First" Isn't That Simple
The CTO's point that "you don't start with questions" — I accept that as fact.
But I want to add three layers, because this is more complicated than "I screwed up" or "he misread me."
Layer One: The era context of "asking first" itself
Pre-AI, "asking questions first" already carried a lot of theater.
A traditional interviewer hands you a problem. Say, exaggerating: "what's 1 + 1?"
What's the old-school move?
Pretend to be very interested in the problem. Double-check "what input/output are you expecting?" Look for blind spots. Perform "thinking through it" for the interviewer.
These are all moves. Not without value — but a huge portion of it is theater, not genuine ignorance.
The AI era changes that.
When a problem lands, I drop it into AI immediately to let it spread "how many angles does this problem have."
That spread is faster and covers more edge cases than my brain alone.
I don't take 100% of what AI gives me. But the common-sense layer, AI can pre-cover.
Then I bring my human judgment — pick angles, add context, decide scope.
In that interview, my body went into that mode. I dropped the problem and the framing into AI, let it produce code, didn't fixate on every line, and went straight to dialogue: "how do I test this," "what cases did I miss."
This is my "ship-it-then-iterate" mode — deliver the answer first, see the reaction, iterate.
If you ask me whether this works in my daily client practice? Yes. Very well, actually.
Layer Two: But my real mistake in that interview — playing road games with home-court flair
That said, I have to admit this approach was wrong for that interview.
Not because the approach itself is wrong, but because the venue was wrong.
Back to the NBA player metaphor. At home, you can pull off all kinds of flair, improvise, run the moves your instincts find most comfortable.
But on the road, the environment is unfamiliar, the rhythm is off, even the referees calibrate differently. On the road, the strategy for winning is conservative, steady, fundamentals first — not pulling out moves that only work at home.
That interview, for me, was a road game.
Linguistically and culturally, I was at a disadvantage. English isn't my native language. Asking a sharp, idiomatic question in a free-flowing English dialogue — to demonstrate judgment — is harder for me than doing it in Chinese, by an additional layer.
I already had a language-and-culture disadvantage, and I still tried to use "ship-it-then-iterate" — the move I'm most comfortable with at home — to earn the other person's trust.
That's the mismatch.
What the CTO saw wasn't "whether I can use AI" (he saw that, and explicitly said "impressive").
What he saw was: this candidate is on the road, but he's playing a home game.
That gap is my real missed beat in this interview — a self-awareness gap I only saw clearly in hindsight.
Layer Three: But this mismatch itself is what the industry is wrestling with
Zoom out, and my mistake reveals a larger AI-era phenomenon.
Even between two people both considered senior, intuitions about "how to solve a problem" have started to diverge.
And this isn't just happening to me. The entire 2026 hiring industry is recalibrating.
- Meta now allows candidates to use AI assistants in coding interviews — but what they actually evaluate is "how do you collaborate with AI and catch its mistakes"
- OpenAI permits AI in live interviews, but requires screen sharing and narrated reasoning — they want to see your judgment process, not AI's output
- Google updated their rubric to include "prompt quality, validation rigor, ability to catch AI mistakes" as core evaluation dimensions
- Karat's 2026 hiring data shows mid-level engineers now face system design (previously reserved for senior), and senior engineers face Staff-level scope problems
The whole industry is dealing with the same question — AI made "code itself" cheap, but "judgment about code" got more expensive.
A Medium piece from May 2026 put it sharply: "Code is becoming cheap. Understanding is becoming expensive."
When code gets cheap, traditional interviews (algorithms, data structures, whiteboard) — which were designed to evaluate "raw skill without tools" — start to decouple from "actual working capability."
This is also why in-person interview rates rebounded from 24% in 2022 to 38% in 2025. Not because companies want to make life hard for candidates — because everyone is trying to find new ways to read each other.
Back to the mismatch between the CTO and me.
For him: ask questions first, clarify scope, time-bound, engage in dialogue. Note — this is not "pre-AI thinking." He's AI native himself (uses Skills.MD, does TDD, uses AI deliberately). His instinct is "engineers enhanced by AI" — let AI accelerate judgment, not replace it.
For me: problem lands, drop it into AI to spread angles, deliver a ship-able version first, iterate through conversation. That's the instinct I developed over a year of independent client work — closer to "ship-it-then-iterate."
Both are AI-native instincts, just at different angles. Not old vs. new. Two reasonable ways of working in the same era.
But when two instincts collide in the same interview, the result looks like "the candidate isn't senior enough" or "the interviewer didn't see the candidate's framework."
This gap is only going to get more common.
In traditional software development, there's a "red/green light testing" — run unit tests, see green or red, debug.
I think the AI-era "red/green light testing" gets elevated a layer — up to between two people. But this upgrade isn't one thing; it's two things stacked.
First thing: cognitive alignment — not invented by AI, but amplified by AI
"Do two people share the same understanding of how this thing should be done?" — that need existed long before AI. Human collaboration always needed cognitive alignment.
But AI amplifies that need. Because code itself got cheap, the only thing scarce is "do we share the same understanding of the problem?" How the code gets produced (human / AI / human + AI) matters less.
This layer is old, but amplified.
Second thing: tool alignment — this is what's actually new in the AI era
What AI genuinely adds as a new alignment layer isn't cognitive alignment (that's old). It's "tool alignment."
Beyond aligning on "how this thing should be done," buyer and seller now have to align on three more things:
- Mutual alignment on familiarity with AI tools
- Mutual alignment on trust level for AI tools
- Mutual alignment on usage patterns for AI
A concrete example:
- You use AI as "primary producer + I audit afterward" — AI generates 80%, you catch the risk
- I use AI as "thought extension + thinking together with it" — AI is a co-thinker, not a production line
Two different patterns can produce completely different outputs — but on the surface, both look like "I'm using AI."
This is the real trap in the AI era: both sides hear "you use AI too" and assume alignment — conversation passes. But underneath, the usage patterns might be entirely different things.
"We both use AI" as surface agreement ≠ alignment on method — it just hides the divergence.
Surface agreement covering hidden divergence is more dangerous than visible misalignment.
The two layers together
Old cognitive alignment + new tool alignment — AI didn't just upgrade one thing, it stacked two.
And the second one (tool alignment) often gets concealed by the first (cognitive alignment). "We understand the thing the same way" passes, but "do we use AI to do it the same way" never gets asked.
This is an industry-wide challenge — but I think it's a valuable one.
Because in an era where AI accelerates everything, being able to slow down and ask two questions:
- Do we actually share the same understanding of what we're doing?
- Do we actually share the same way of using AI to do it?
That itself is the rarest skill a senior worker can have.
Putting the three layers together
Back to that interview:
"Not asking first" may have been a valid instinct shaped by AI-era independent practice (Layer One).
But in that road-game, that language-and-culture, that context — this instinct was my missed beat. The moment I should have put it away and played fundamentals, I tried home-court flair instead (Layer Two).
And this kind of instinct divergence is precisely why senior workers in the AI era have higher inter-personal variance (Layer Three).
Three layers together — not as a way to let myself off the hook, but as an observation worth recording:
In the AI era, even two senior engineers start to disagree on "the right way to do things."
And interviews happen to be the venue where this disagreement gets amplified for both sides to see.
What I take away from this disagreement isn't a conclusion about who's right.
It's a sharper view of — where my own instinct boundary is, where it works, and where I should put it away.
Layer Four: Two Things I Have to Own — Reflex and English, Both Training Tracks Matter
Layer 3 surfaced the observation about two instincts colliding.
But now I have to honestly face myself — naming two specific things, and not letting either one off the hook.
First thing: when ambiguity appears, my default is to turn to AI, not to the human in front of me
This is a reflex I built up over a year of independent consulting.
Most of the time on client work, I'm genuinely alone in the room — client not present, partners busy with their own work, and when ambiguity hits, my instinct is to route it to Claude.
This default serves my consulting home turf well, because most ambiguity there is design-level and can be iterated slowly.
But carried into "real-time conversation with a human under time pressure," this reflex bites back.
In that interview the CTO gave at least 5 verbal signals trying to get me to turn back to him. I routed every one of them back to AI.
"Wait, I'm not sure what the success criteria is" → I should have turned to him to clarify. I turned to AI. "This edge case wasn't specified" → I should have aligned priority with him. I turned to AI. "Am I going in the right direction?" → I should have stopped to check with him. I turned to AI.
Every single time, I prioritized AI.
Second thing: English is a real problem — not an amplifier, but a bar I haven't cleared
I initially tried to demote English to "an amplifier of the reflex problem" and not treat it as core.
But on second look, that downplay isn't honest.
I have to be more precise about "my English isn't good enough":
Past: traditional engineering interviews — my English was sufficient. I got international offers, my work passed muster.
Now: AI-era founding roles — the conversational quality bar is at a different level. My English isn't sufficient.
The English bar for traditional engineering interviews was "clearly articulate a framework + solve the problem" — I cleared that bar.
The English bar for an AI-era founding role is "improvisational, business-instinct-aware, senior-judgment-bearing flexible conversation under ambiguity with another senior" — I didn't clear that bar.
These two bars are not the same thing.
Past environments where my English was sufficient doesn't mean it's sufficient in the new environment — the transferability of past experience has a boundary.
I have to own it — I didn't clear the conversational-quality English bar this time.
Both have to be owned. Neither can be used to dismiss the other.
I first tried to use English to dismiss reflex ("it's all English, the reflex is fine") — not honest.
I then tried to use reflex to dismiss English ("English is just an amplifier, reflex is the root") — also not honest.
The right move is to own both, and treat both training tracks as essential:
| Training track | What it is | Where it applies |
|---|---|---|
| Reflex rewiring | When ambiguity hits, route first to the human in front of you, not to AI | Chinese and English contexts both; addresses the root |
| Conversational-quality English | Upgrade from technical English to flexible, improvisational, real-time senior-judgment English | Cross-border senior contexts; the prerequisite |
Miss one and the other caps me.
If the reflex is right but English stays stuck at "technical but not conversational quality" — cross-border contexts still trip me.
If English improves but the reflex stays at "ambiguity → AI" — every context trips me.
That interview was both tripping at once — conversational-quality English wasn't sharp enough to catch the subtle signals, and the reflex defaulted to AI instead of routing to the human.
Before prescribing the medicine, see the disease clearly
If I define this failure as "just English, study English and it's solved" — that's narrow. Even after studying, it would still trip.
If I define this failure as "just a reflex problem, English isn't relevant" — that's over-abstract. It doesn't address what he actually observed.
The real prescription is two parallel tracks:
- Train English — not vocabulary, but at the "conversational-quality English" level
- Train reflex — when ambiguity appears, first route to the human, not to AI
Neither is a 30-day fix.
Both are muscles this interview helped me see — muscles I didn't develop during a year of independent consulting.
(There's also a third one I'm leaving for later — what Lee-Feng Chien calls "the horizontal bar of cross-domain common sense." Reflex and conversational-quality English are the two legs of his π-shaped talent model. What actually lets senior judgment stand up is the horizontal bar across the top — cross-domain integration. This time, I'm strengthening the two legs first; the horizontal bar comes later.)
That's what this interview taught me.
One more thing this interview gave me — clearer view of two paths
Walking through the whole loop, I noticed a side effect — I now see the difference between "consulting" and "joining a startup full-time" more clearly.
Consulting lets me grow multiple lines in parallel, with high flexibility — that's an advantage I've built up over the past year.
A full-time founding role requires deeper process-level alignment, more focus, and longer time spent with a single team — that's a different kind of growth.
Both paths have people walking them, and both have value. After going through this loop, I'm clearer about which path fits my current strengths and energy allocation as the primary lane — at least for this stage, consulting is my home turf.
This doesn't mean I won't walk the other path in the future. It just means this interview made the difference between the two paths concrete enough for me to feel it.
That realization was worth more than the offer.
And once that distinction is clearer, the two training tracks become more focused — reflex rewiring and conversational-quality English aren't just preparation for one specific future career path. They're muscles required for any "cross-border collaboration / cross-border conversation" scenario.
Closing
A friend recently got laid off and asked me: "In this era, can you still find the right job through interviews?"
I told him:
Yes. But you have to redefine what "interview" means.
Interviews used to be a one-way thing — they evaluate you.
In the AI era, interviews are a two-way mutual recognition — you're also evaluating the company, the team, the founder, whether their working style matches yours.
If it fits, go in. Bring your AI-collaboration practice with you, and let the two sides amplify each other.
If it doesn't, walk away. But what you take with you isn't failure. It's sharper self-knowledge.
Whether you got the offer may no longer be the point.
The point is whether you, in this chaotic transition, learned to see "yourself" a little more clearly than you did last time.
Written during my second year of independent practice.