The Format Pivot That Caught Everyone Off Guard
For close to fifteen years, the coding interview at Google and Meta followed a script that any prepared candidate could recite in their sleep. You opened a shared editor — Google Docs, then CoderPad, then internal tools like Google's own interview surface — typed in a clean room with no autocomplete, no Stack Overflow, no Copilot. The interviewer watched you stare at a wall, asked clarifying questions, and judged you on whether you reached an optimal solution to a problem you had almost certainly seen on LeetCode.
That era ended in 2026. Both companies, within roughly six months of each other, formally permitted AI assistants inside their coding loops. Google rolled the change into its standard Software Engineer and Software Engineer III interview tracks, allowing candidates to use an internally hosted variant of Gemini during the coding round. Meta followed with a permission to use a sandboxed Llama-based assistant inside its CoderPad equivalent, branded internally as part of the broader "AI-native interviewing" rollout that surfaced in leaked recruiter emails and was later confirmed publicly.
This was not a cosmetic change. It is a re-architecture of what the coding interview is testing. When the candidate can ask an LLM to draft the binary search, the question is no longer "do you remember how to write binary search." The question becomes: can you specify the problem precisely, can you read generated code critically, can you spot the off-by-one in the third iteration, and can you steer toward the correct asymptotic complexity when the model defaults to something quadratic?
This article is a reaction to that pivot, written for engineers and career-switchers who are actively interviewing in 2026 or planning to in the next twelve months. It is not a generic "how to crack the coding interview" guide — that genre is rapidly losing relevance. It is a practitioner-level breakdown of what changed, what the new rubric actually measures, the failure modes we are watching candidates fall into, and the preparation loop that works under the new format.
If you are preparing for these interviews and want a structured environment that mirrors the new expectations — data structures, system design, testing, CI/CD, and code review with AI in the loop — Refonte Learning's full-stack software engineering program is built around exactly this stack of skills. We will reference it once more later; the rest of this piece is the technical reaction.
What Google and Meta Actually Changed
Let's get the factual layer right before we draw conclusions, because there is already a lot of confused commentary on LinkedIn and tech Twitter about what is and isn't allowed.
At Google, the change applies to the standard coding rounds — typically two to three forty-five-minute slots during the onsite (now usually virtual). Candidates are given access to an interview-mode Gemini surface inside the editor. It can autocomplete, it can be prompted with natural language, and it can explain code. What it cannot do, in interview mode, is execute arbitrary network requests or load external content. The model has been deliberately tuned to be a collaborator rather than a solver — it will frequently respond with clarifying questions, and it has been instructed to avoid producing a full solution to common LeetCode-style problems without candidate-driven decomposition.
At Meta, the surface is different but the philosophy is similar. The assistant is integrated into Meta's internal CoderPad fork and behaves more like a turbocharged Copilot than a chat agent. Inline suggestions are aggressive. The candidate can accept, modify, or reject completions, and the interviewer sees every keystroke including AI suggestions and which ones were accepted. Meta's product round and system design round have separate, more limited AI access — system design still leans heavily on whiteboard reasoning and the model is mostly there to look up API references or sketch boilerplate.
A few things did not change:
- The interviewer is still in the room (virtually) and still drives the conversation.
- The bar for hire is still calibrated against existing engineers, not against "the candidate plus an LLM." In practice, this means the bar has gone up on judgment and down on raw recall.
- Phone screens at both companies still use AI tooling, but the problems are now noticeably harder and more ambiguous than the classic two-pointer warmups.
- System design remains largely AI-skeptical at the senior levels. The L5/E5 and above design loop expects the candidate to reason about tradeoffs, not generate diagrams.
A few things changed quietly that matter:
- Both companies now record AI prompts and completions as part of the interview signal. Recruiters and hiring committees can see what the candidate asked and what the model produced.
- The rubric explicitly includes "effective use of AI tooling" as a scored dimension at Meta. At Google it is implicit but consistently mentioned in debrief notes we have seen.
- The questions themselves have shifted. Pure algorithmic puzzles are being replaced or supplemented by what Google internally calls "realistic engineering vignettes" — questions that involve reading existing code, extending it, debugging it, or integrating two components.
That last point is the most important and the rest of this article unpacks why.
Why the Change Happened Now
The obvious answer is that everyone is using AI assistants in their day job, so banning them in interviews started to feel like banning calculators on engineering exams — performative, not predictive. But the deeper driver is that both companies were getting bad signal from the old format.
Internally at Google, hiring committees had been flagging for at least eighteen months that LeetCode-prepared candidates were passing interviews and then underperforming in their first six months. The gap between "can solve a memorized graph problem on a whiteboard" and "can ship a feature in a 40-million-line monorepo with code review, testing, and rollback" was widening. The interview was selecting for the wrong skill.
Meta had a similar internal conversation, complicated by the fact that their recruiter pipeline was being flooded with candidates using stealth AI tools — browser extensions, second monitors, hidden earpieces feeding GPT-4 outputs in real time. The arms race against cheating was unwinnable. Rather than keep building anti-cheat surveillance, Meta's engineering leadership decided to flip the model: bring the AI inside the interview, instrument it, and judge how the candidate uses it.
There is also a candid product-strategy reason. Both companies are betting their next decade on AI-native engineering — coding agents, autonomous PR generation, AI-driven incident response. The engineers they hire in 2026 will spend the bulk of their day collaborating with models. Testing them in a model-free environment selects for skills that will be progressively less valuable. Refonte Learning has written separately about how AI and automation are helping developers work smarter, and that shift on the job is exactly what the new interview is trying to mirror.
There is a labor-market angle as well. The volume of applications has exploded because LLMs make it trivial to tailor resumes and write cover letters. Both companies needed an interview that could differentiate signal in a flood. Ironically, AI in the interview is part of the answer — the noise floor is too high for the old format to discriminate.
Finally, there is a fairness argument that internal recruiters at both companies have made publicly. The old format favored candidates with the time and money to grind LeetCode for six months. Engineers from non-traditional backgrounds, career-switchers, parents, and people working full-time were systematically disadvantaged. An interview that judges judgment, communication, and review skills — which can be developed on the job — is arguably more equitable than one that judges memorization of CS-curriculum classics.
The New Rubric: What Is Actually Being Scored
This is where most prep content is still wrong. Candidates are showing up assuming the interviewer wants to see them code fast with AI assist. That is not what the rubric rewards.
The dimensions we are seeing scored, based on conversations with current Google and Meta interviewers and leaked rubric documents that have circulated in 2026:
Problem decomposition. Before any code is written, can the candidate restate the problem, identify edge cases, propose a data model, and outline a solution at a level of abstraction the model can act on? Interviewers are explicitly looking for candidates who spend the first ten minutes talking and sketching before they touch the editor.
Prompt quality. When the candidate does engage the AI, are the prompts specific and bounded? "Write the function" gets penalized. "Implement a sliding window that maintains the maximum in O(n) using a monotonic deque, with the signature we defined above" gets credit. The interviewer can see the prompts.
Critical reading of generated code. The AI will produce code that compiles, runs on the happy path, and is subtly wrong. The candidate's job is to find the bug. We are seeing interviews where the model deliberately produces an off-by-one or a missed edge case and the score hinges on whether the candidate catches it before the interviewer points it out.
Complexity reasoning. AI assistants are notoriously bad at minimizing asymptotic complexity unless explicitly directed. A candidate who accepts an O(n²) suggestion when O(n log n) is achievable loses points even if the code is correct.
Testing and verification. Candidates are expected to write tests, run them, and iterate. The classic "I think this works, shall we move on" closing is now a red flag. Strong candidates produce a test harness, often with AI help, and walk through cases.
Communication. The candidate is talking to the interviewer the entire time, narrating decisions, flagging tradeoffs, and explaining what they are about to ask the model. Silent typing has always been a weak signal; now it is a near-disqualifier.
Knowing when not to use AI. This one is subtle but real. Strong candidates write trivial code by hand because the AI round-trip is slower than just typing a five-line loop. They invoke the model for boilerplate, for unfamiliar APIs, and for tedious transformations — not for the core algorithmic insight.
Notice what is absent from this list: speed of producing code, memorization of canonical solutions, ability to recall a specific data structure under pressure. Those skills have been deprecated, not because they are useless but because AI makes them table stakes.
A Walkthrough of a 2026 Google-Style Coding Round
Let me make this concrete with a composite of what we have seen candidates report from recent loops. Names and specifics are anonymized.
The problem is presented as a vignette: "Here is a small codebase implementing a rate limiter using a token bucket. There is a bug — under burst traffic, it occasionally allows more requests than the configured limit. Find and fix the bug, then extend the rate limiter to support per-user limits."
The candidate is given roughly 200 lines of Python across three files, a test file with passing tests, and access to the AI assistant.
A weak candidate immediately pastes the code into the assistant and asks "find the bug." The model responds with three plausible-sounding bugs, two of which are not actually present. The candidate spends fifteen minutes chasing ghosts.
A strong candidate first reads the code. They ask the interviewer for clarification on the expected concurrency model. They note that the bucket refill logic uses wall-clock time and ask whether the system runs in a multi-threaded environment. They then ask the AI a precise question: "Given this token bucket implementation, what race conditions exist if consume is called from multiple threads simultaneously?" The model identifies the missing lock around the refill-and-consume sequence. The candidate confirms by reading the code, writes a failing test that demonstrates the race, fixes it with a lock, and reruns the suite.
For the extension, the strong candidate sketches the per-user data model on a virtual whiteboard, discusses memory implications (what happens when there are a million users?), proposes an LRU eviction policy, and only then asks the AI to scaffold the implementation. They review the generated code, notice that the AI used a regular dict rather than an OrderedDict or functools.lru_cache-style structure, ask it to revise, and integrate.
The round ends with the candidate writing a few additional tests covering the per-user case and discussing what they would add in production — observability hooks, configuration loading, an admin endpoint to flush a user's bucket.
Notice the distribution of activity. The candidate typed less code than in a classic interview. They read more, talked more, and made more decisions. The AI was a tool, not the main character.
How Meta's Format Differs
Meta's coding round in 2026 is closer to a pair-programming session than a puzzle. The problems tend to be more product-flavored — implementing a feed ranking helper, building a notification deduplication function, writing a service that aggregates events from a stream.
The AI assistant is more aggressive about inline suggestions. As you type, completions appear constantly. Candidates who have practiced with Copilot have a real advantage here because the rhythm of accept-modify-reject is muscle memory.
Meta interviewers explicitly probe on three things we do not see as heavily emphasized at Google:
Production-readiness. Once you have a working solution, the interviewer will ask "what would you change to ship this?" Strong candidates immediately bring up input validation, error handling, logging, metrics, feature flags, and how they would roll it out. The interview implicitly tests whether you think like an engineer who has shipped before, not just one who has solved.
Integration thinking. Meta loves to give a problem that involves two or three existing components — a cache, a queue, a database — and ask you to wire them together. The AI helps with the boilerplate of each integration, but the candidate has to drive the architecture.
Refactoring under load. A common pattern: get a solution working, then the interviewer adds a constraint that breaks your design. "Now imagine the input is 100GB and doesn't fit in memory." The candidate has to refactor, often substantially, and the AI is allowed to help — but the redesign decisions must come from the human.
Meta's E5 and above also have what is called the "product judgment" portion of the coding round, where the interviewer asks open-ended questions about the API design or the user-facing behavior. AI is not particularly helpful here and candidates who lean on it too heavily look weaker.
For a broader take on what skills the modern Meta-style engineer needs to develop, the skills and AI roadmap for software engineers in 2026 breakdown maps closely to what these interviews are measuring.
Failure Modes We Keep Seeing
From mentoring candidates through these new loops, a handful of failure modes show up over and over. They are worth naming because once you see them in yourself, they are fixable.
The dictator. The candidate treats the AI as a junior engineer they are bossing around. They write a prompt, accept whatever comes back, and move on without reading it. Half the time the code is wrong in non-obvious ways. The interviewer sees a candidate who can issue commands but cannot evaluate output. This is the most common failure mode and almost always results in a no-hire.
The transcriptionist. The candidate copies the problem statement into the AI verbatim and asks for a solution. The model produces something. The candidate cleans up the variable names and presents it. Interviewers can spot this from a kilometer away because the candidate cannot explain why specific design choices were made. The follow-up questions reveal the absence of understanding immediately.
The refuser. Some candidates, especially those who prepared heavily for the old format, refuse to use the AI at all. They want to show they don't need it. This also fails, because the rubric expects effective AI use as a positive signal. Refusing to use the tool reads as either pride or unfamiliarity, neither of which helps.
The over-prompter. The candidate writes elaborate, paragraph-long prompts for trivial tasks, burning the clock. By the time they get to the actual problem-solving, they are behind. The fix is to learn what is worth prompting for and what is faster to type by hand.
The silent typist. The candidate stops talking once they engage the AI. The interviewer can see the prompts, but the reasoning is invisible. Strong candidates narrate: "I'm going to ask the model to draft the parsing logic because the spec is messy, then I'll review." That narration is most of the signal.
The trust-on-first-glance. The AI produces a function. The candidate reads it once, says "looks good," and runs the test. The test passes on the happy path. The interviewer asks about an edge case the candidate didn't consider. Catastrophe. Always assume generated code is wrong until proven otherwise.
How to Practice for the New Format
The preparation loop has changed substantially. Grinding LeetCode is still useful for building algorithmic intuition, but it is no longer sufficient and is probably not even the highest-leverage activity anymore.
A practice week that mirrors the new format looks roughly like this:
Spend two or three sessions a week working through medium-difficulty problems with Copilot or Cursor enabled, but with a constraint: you must narrate every prompt out loud, and you must spend at least one minute reading any non-trivial completion before accepting it. Record yourself. Watch the recording. You will be horrified at how often you accept code without reading it.
Spend at least one session a week on what we call "bug hunt" practice. Take a working solution to a known problem, use the AI to introduce a subtle bug, then practice finding it. The skill of reading suspicious code is now central and almost nobody practices it deliberately.
Spend a session a week on the integration-style vignettes Meta and Google now favor. Pick two open-source libraries — say, FastAPI and Redis — and build small features that combine them. The skill being trained is the ability to read unfamiliar APIs quickly, identify the right primitives, and assemble them with AI help.
Do at least one mock interview every two weeks with a human interviewer, with AI enabled, under realistic time pressure. The format is unfamiliar to almost everyone. The first three mocks you do will be rough. By the fifth, you will start to find a rhythm.
Finally, build small projects that involve testing, CI/CD, and code review with AI in the loop. The Refonte Learning curriculum on AI-driven product engineering practices walks through exactly this stack — the same stack the interviews are increasingly probing.
What to deprioritize: pure recall practice for obscure algorithms, hand-implementing standard data structures from memory under time pressure, and any prep that involves silently grinding problems alone. The new format is collaborative, verbal, and judgment-driven. Solo grinding optimizes for the wrong thing.
System Design and Behavioral: Still Mostly AI-Free
It is worth noting what did not change much, so candidates do not over-correct.
System design at L5/E5 and above is still substantially AI-skeptical. The interviewer wants to see how you reason about tradeoffs in a four-to-six-hour design problem — sharding strategies, consistency models, capacity planning, failure modes. The AI is there if you need to look up a specific service's quota or sketch a diagram, but the design itself must come from you. Candidates who lean on the AI to propose architectures lose because the model produces generic, surface-level designs that fall apart under interviewer probing.
The areas where AI is genuinely helpful in design rounds: looking up specific cloud service limits (Aurora's max IOPS, Spanner's transaction size, Kafka's partition limits), generating example payloads to discuss, sketching ER diagrams from a verbal description. Use it as a reference tool, not as the designer.
Behavioral interviews have not changed at all. AI cannot help you in real time with a behavioral round, and trying to use it usually makes you look slower and less prepared. Practice your stories the old-fashioned way — STAR format, specific examples, ownership language. Both companies still weight behavioral heavily, especially for leveling decisions.
For more on the broader career picture and how senior engineers are positioning themselves, continuous learning for career growth covers the longer arc.
What This Means for Career-Switchers and Bootcamp Graduates
The change is a mixed bag for non-traditional candidates. On the positive side, the deprecation of pure recall favors people who can think clearly and communicate well, which are skills that career-switchers often bring from previous careers. The fairness argument that drove some of the change is real — the new format is less brutal on people who didn't spend four years at a CS-heavy university memorizing the canon.
On the negative side, the new format demands a broader skill set. You need to be comfortable with AI tools, fluent in at least one production language, able to read and modify unfamiliar code quickly, and capable of system-level reasoning. A bootcamp that taught you React and a bit of Python is no longer enough. You need depth.
The path that works in 2026 looks something like: solid CS fundamentals (data structures, complexity, basic algorithms — this is still required, you just won't be tested on recall), real engineering experience including testing, code review, and deployment, comfort working with at least one AI coding assistant in a daily workflow, and the soft skills of narrating your reasoning under pressure.
Bootcamp graduates we have seen succeed in 2026 typically did one of three things: contributed substantially to an open-source project where they had to read existing code and submit reviewable PRs, took an internship or apprenticeship where they shipped to production under code review, or worked through a structured program that includes the full engineering lifecycle rather than just "build a CRUD app."
This is exactly the model behind Refonte Learning's software engineering track. The program puts learners through real codebases, real code review, real CI/CD, and increasingly, real AI-assisted workflows. The piece on preparing for a software engineering career in 2026 goes into more detail on how non-traditional candidates can structure their twelve-month plan.
What Happens Next: The 2027 Loop
It is worth speculating briefly about where this goes, because the format is still moving.
We expect both companies to push further into agent-style interviewing within twelve to eighteen months. The candidate will be given a problem and a coding agent — something more autonomous than current assistants — and asked to direct the agent through a larger task than fits in a single forty-five-minute slot. The skill being measured will shift from "can you co-write code with an AI" to "can you supervise an AI engineer." This is already how senior ICs at both companies are starting to work day-to-day.
We expect take-home assessments to make a partial comeback, ironically because AI makes them harder to game in obvious ways. If everyone has AI, the interesting signal is what they build with it over a few hours of focused work. Some teams at both companies are already experimenting with this for senior hires.
We expect the bar for system design to keep rising. As coding becomes more commoditized by AI, the differentiating skill is judgment about systems — what to build, how to scale it, what tradeoffs to accept. The system design loop will probably grow from one round to two for senior candidates within the next couple of years.
We expect specialized rounds for ML/AI engineers to diverge further from generalist SWE loops. Candidates targeting roles on AI infra teams should expect deep questions about distributed training, inference optimization, and model evaluation that the general SWE loop does not cover.
And we expect — this is more speculative — that the new format will spread to the rest of the industry within eighteen months. Stripe, Anthropic, OpenAI, Netflix, and the larger Series-C startups already use AI-permissive interviews in some form. By late 2026, expect the format to be the default at any company hiring senior engineers, with smaller and more traditional shops following in 2027.
Bringing It Together
The FAANG coding interview is not dead. It has, however, undergone the largest single-format change in its history, and the candidate playbook from 2023 no longer works. The interview has shifted from a memory-and-recall test to a judgment-and-collaboration test. AI is not a crutch you are allowed to use; it is a tool you are expected to use well.
If you are interviewing in the next six months at Google, Meta, or any company that has followed their lead, the highest-leverage changes to your preparation are: practice with AI tools enabled and narrate every decision, deliberately practice reading and debugging generated code, do mock interviews under realistic conditions, deprioritize pure LeetCode grinding in favor of integration-style problems and production-readiness thinking, and continue to invest heavily in system design and behavioral preparation because those rounds are still mostly traditional.
If you are earlier in your trajectory — a student, a career-switcher, someone six to twelve months from interviewing — the implication is bigger. The skills the new interview rewards are the same skills the new job rewards: working effectively with AI, reading and reviewing code at speed, owning the full lifecycle from spec to ship, and reasoning about systems. Build for the job, and the interview will take care of itself.
That is the bet behind Refonte Learning's program design, and it is the bet behind this article. The coding interview at the largest companies in the industry has finally caught up with the way engineering actually works in 2026. That is good news for engineers who are doing the real work, and a wake-up call for everyone whose interview prep stopped evolving in 2022.
About Refonte Learning
Refonte Learning is an EdTech platform offering professional training in AI, data, cloud, DevOps, and software engineering. Our programs combine instructor-led teaching, real internship-style projects, and AI-native workflows so that what you learn in training is what you do on the job — and what you are tested on in interviews. If you are preparing for an AI-assisted technical loop at a top-tier company, our software engineering track is built around the same skills the new rubric measures.