How should you approach Google interview prep?

Eight weeks is enough time to become measurably better at a Google interview. It is not enough time to rebuild your career from scratch, memorize every algorithm, or imitate somebody else's interview persona. The useful goal is narrower: expose how you solve an unfamiliar problem, make that work legible to an interviewer, and remove avoidable failures from the process.

Most candidates spend too much of those eight weeks collecting questions. I have interviewed engineers, built teams, and watched good people underperform because their practice rewarded recognition rather than reasoning. A candidate who has rushed through 300 problems can still freeze when an interviewer changes one constraint. A candidate who has solved 70 carefully, explained tradeoffs, tested code, and reviewed failures usually has a better chance.

This plan assumes a software engineering role because coding, design, and behavioral interviews make the practice mix concrete. Google changes loops by role, level, location, and current hiring need, so your recruiter email outranks any generic guide, including this one. Use the plan as an operating system, then replace its assumptions with the actual rounds you receive.

Eight weeks works only with a defined target

An eight-week plan works when you already meet the role's basic qualifications and can protect about 10 to 14 focused hours each week. More hours can help, but tired repetition has poor returns. If you cannot write ordinary production code without constant reference material, or if the role expects system design experience you have never had, move the interview if the recruiter allows it. Calendar courage does not repair a missing foundation.

Set one target role, one level, and one primary programming language on day one. A broad goal such as "get into Google" gives you no way to choose between a graph problem, a distributed cache design, and a leadership story. The job description tells you the domain. The recruiter tells you the expected loop. Your baseline mock tells you where your performance actually breaks. Those inputs should control the schedule.

Use a weekly mix rather than assigning every day to one subject. For a general software engineering loop, a sensible starting allocation is 45 percent coding, 20 percent design or role knowledge, 20 percent behavioral evidence, and 15 percent mocks and review. Early-career candidates can move much of the design share into coding. Senior candidates should move time toward architecture, leadership, and the depth of their past decisions.

Do not count videos watched or pages read as preparation. Count performances you can inspect: timed solutions, recorded explanations, design diagrams, story rehearsals, and written postmortems. Each session needs an output. That rule stops a familiar failure in which a candidate studies for three hours, feels busy, and produces nothing that resembles an interview.

Before the first week ends, book the interview date if you control it, schedule at least four mock sessions with real people, and put all practice blocks on the calendar. Friends cancel and work expands. A plan that depends on finding a mock interviewer on the evening you need one will collapse.

Map the actual loop before choosing material

The recruiter-provided schedule is the only reliable map of your interview loop. Google does not run one universal sequence for every candidate, and internet recollections often mix roles, years, and levels. Ask the recruiter what each session evaluates, how long it runs, which tools you will use, whether a design round is included, and whether any role-specific material deserves special preparation. Recruiters may not reveal questions, but they can usually clarify format.

A software engineering process can contain a recruiter conversation, one or more technical screens, and a fuller set of interviews covering coding, design at applicable levels, role knowledge, and behavioral judgment. Treat that as a family of possible rounds, not a promised count or order. Team matching and final review can also affect the path after interviews, but neither changes how you should perform in the room.

Write a one-page round map with five columns: session, skill being tested, expected medium, evidence you must show, and practice owner. "Coding" is not enough in the skill column. Write observable actions such as clarifying constraints, selecting a data structure, deriving complexity, producing executable code, and testing boundary cases. For design, write requirements, estimates, interfaces, data model, failure behavior, and tradeoffs.

The medium matters more than candidates expect. Google's technical virtual interview guide says some design interviews use Google Drawings and advises candidates to focus on the answer rather than perfect shapes. It also says pen and paper may be acceptable if you tell the interviewer and make your work visible. Practice in the tool named in your confirmation email. Drawing a beautiful architecture in your favorite desktop app does not prepare you to explain a rough diagram through a shared browser window.

Run a technology check before serious mocks. Use the same computer, camera position, microphone, browser profile, and display setup you expect on interview day. Google's general virtual interview guide recommends presenting one window, closing unnecessary tabs, and limiting work to one screen and one window. That is sensible operational advice: it reduces privacy mistakes, notification interruptions, and time lost hunting for the correct document.

If the invitation conflicts with a blog or course, follow the invitation and ask the recruiter. A candidate who memorizes an obsolete process can misallocate half the plan. Uncertainty belongs in a question to the recruiter, not in a private theory built from forum posts.

A scorecard beats a problem counter

A practice scorecard shows why a solution passed or failed; a problem count hides that information. Google does not publish a complete interviewer scoring form for candidates, so do not pretend an unofficial rubric is company policy. You can still score the behaviors that any technical interviewer can observe and use the result to direct practice.

Copy this template into your practice log. Score each line from 0 to 2, where 0 means missing, 1 means present after prompting or with a significant gap, and 2 means clear and independent. Record evidence, not feelings.

Problem:                         Date:
Round type:                     Time limit:

Clarified goal and constraints  0 1 2  Evidence:
Built a correct approach        0 1 2  Evidence:
Explained tradeoffs             0 1 2  Evidence:
Implemented cleanly             0 1 2  Evidence:
Tested normal and edge cases    0 1 2  Evidence:
Estimated time and space        0 1 2  Evidence:
Recovered from feedback         0 1 2  Evidence:

First failure point:
One change for the next session:

The first failure point is more useful than the final score. Suppose your code fails on an empty input. The visible defect appeared in testing, but the first failure may have happened earlier when you never stated whether empty input was allowed. Fixing only the final line teaches you to patch that example. Fixing the first failure teaches you to clarify the contract.

Apply the same method to design and behavioral mocks. A design answer can be correct at a high level yet weak because the candidate never quantifies traffic, explains data ownership, or handles a dependency outage. A behavioral answer can sound polished yet fail to establish the candidate's personal decision, the disagreement they faced, or the result they can defend.

After every mock, choose one change for the next session. Do not carry a list of nine corrections into a new problem; working memory will drop all of them under time pressure. If the biggest defect was silent reasoning, the next practice goal is to state the plan before writing code. If it was uncontrolled scope in system design, the next goal is to confirm two core requirements before drawing components.

Keep the scorecard stable for the full eight weeks. A changing rubric makes improvement impossible to see. Difficulty will vary between problems, so look for repeated behaviors across several sessions rather than celebrating one high total.

Weeks one and two build an honest baseline

The first two weeks should reveal gaps and repair core mechanics, not produce an impressive problem count. Start with a timed coding mock before studying. Pick a problem you have not seen, give yourself 40 minutes, speak aloud, write runnable code, and test it. Record the session if your mock partner agrees, then score it without excusing nerves. Nerves are part of the system you are testing.

Build your coding inventory from patterns you can derive rather than titles you remember. Cover arrays and strings, hash maps and sets, linked structures, stacks and queues, trees and graphs, sorting and binary search, recursion, and basic dynamic programming. The list is not a forecast of questions. It is a check that a missing data structure will not block an otherwise ordinary solution.

For each pattern, practice four moves: identify the signal, state a simple approach, improve it with a reason, and prove the complexity. Write code only after those moves. Candidates often jump to an optimized technique they half remember, then cannot explain why it applies. A correct simple approach gives you a base for discussion and a path to improvement.

Use your strongest interview language unless the role or recruiter requires another. You need automatic command of its collections, sorting behavior, equality rules, integer limits, and common library operations. Create a small syntax sheet from your own errors. Review it between sessions, but do not read from it in a mock. The point is to remove incidental syntax load so you can spend attention on the problem.

By the end of week two, complete at least one diagnostic design session if your expected level includes design. Do the same for behavioral questions. Write eight to ten experience candidates from your real work: a hard technical decision, conflict, failure, ambiguous project, leadership without authority, quality tradeoff, customer impact, and a time you changed your mind. These are raw records, not scripts.

Your exit test for week two is simple. You can solve familiar medium-difficulty patterns within a fixed period, explain before typing, produce code that is close to runnable, and identify your two most common failure modes. If you cannot, reduce novelty in week three and repair the mechanics. Advancing the calendar while carrying the same defect only gives it more rehearsal.

Weeks three and four turn knowledge into an interview

Weeks three and four train the interaction that private study misses. A technical interview is collaborative evidence gathering. The interviewer needs to see your assumptions, choices, corrections, and response to hints. Silent speed is less useful than many candidates think because it conceals the process the interviewer must evaluate.

Use a repeatable coding rhythm without turning it into theater. Restate the problem in your own words, ask only questions that change the solution, walk through a small example, describe a baseline, derive the better approach, implement, and test. You do not need a speech for each stage. You need enough narration that the interviewer can locate your reasoning and intervene before you spend fifteen minutes on the wrong interpretation.

Practice receiving a hint. Some candidates treat a hint as proof they have failed and become defensive. Others accept it without integrating it. In a mock, ask your partner to interrupt once with a useful observation. A strong response acknowledges the implication, revises the plan, and continues: "That means my visited state needs the remaining resource, not just the node. I will change the state pair and revisit the complexity."

For system design, do not memorize a giant architecture and force every prompt into it. Start with the behavior the system must provide and the scale that changes the design. Choose two or three core user actions, estimate the order of magnitude only when it affects a decision, define the main data and interfaces, then trace one request. Add caching, queues, replication, or partitioning when a stated constraint calls for them. Decorative components create questions you cannot answer.

Run one design failure drill each week. After presenting a basic design, let the mock interviewer remove a dependency, increase one dimension of traffic, require a consistency property, or ask how you would investigate latency. This is closer to engineering than reciting boxes. It also reveals whether you understand a component or merely know its name.

Behavioral practice belongs in these weeks as well. Convert your experience inventory into compact stories with context, your responsibility, the decision you made, the action you personally took, the result, and what you would change. Do not memorize full sentences. Interviewers follow interesting details, and a memorized monologue breaks when the next question enters from the side.

Finish week four with a mixed mock that changes modes, for example coding followed by a behavioral question, or design followed by a deep discussion of a past project. Real loops demand this reset. Your postmortem should note how quickly you recovered attention between rounds, not just how each answer scored.

Weeks five and six need pressure and feedback

Weeks five and six should contain the hardest work: full-length mocks, unfamiliar partners, and ruthless review of repeated failures. Solo practice can maintain technique, but it cannot reproduce interruption, ambiguity, another person's pacing, or the discomfort of exposing half-formed reasoning. Schedule two live mocks each week if possible, with at least one partner who does not know your usual explanation style.

Make mocks realistic in constraints but clean in purpose. Tell the partner which round they are simulating and give them the scorecard. Ask them not to rescue you early. They should provide a hint when an actual interviewer plausibly would, record what caused it, and leave time for your questions. A mock designed to humiliate the candidate with obscure trivia supplies poor evidence.

Alternate problem sources and formats so recognition cannot carry you. One session can use an unseen coding problem, another a design prompt, and another a deep review of a project you claim on your resume. For the project review, your partner should ask why you chose the architecture, what failed, which metric changed, what you owned, what another engineer did, and what you would choose now. If a resume bullet cannot survive those questions, rewrite it truthfully before screening.

This is also when you test your behavioral evidence against vague language. Replace "we improved reliability" with your decision and an observable result you can support. If the result is confidential or lacks a public number, describe the operational change without inventing precision: incidents stopped recurring after a particular guard was added, a review step caught a class of defects, or a migration removed a manual handoff. Interviewers can tell when a number exists only to decorate a story.

At the end of each week, aggregate the scorecards. Count how often each behavior received 0 or 1 and read the evidence lines. Choose the top two patterns for repair. If implementation is consistently clean but clarification is weak, solving harder problems is the wrong prescription. Use slightly easier problems and require a precise contract before touching code.

One recommendation I argue against is doing a full mock every day. It sounds serious because it maximizes exposure, but it leaves no time to isolate a defect and rebuild the underlying skill. Use a cycle of performance, diagnosis, focused drill, and another performance. Athletes do not run a race as their only form of training, and interview preparation should not either.

By the end of week six, you should have at least two passing mixed mocks under realistic timing, no unexplained resume claims, and a short list of persistent risks. Passing does not mean perfect. It means the partner could follow your reasoning, the solution met the stated constraints, and you recovered when the session changed direction.

Weeks seven and eight reduce variance

The final two weeks should make your performance repeatable. Candidates often respond to the approaching date by increasing volume, sleeping less, and introducing new material. That raises variance exactly when they need stability. Stop chasing rare topics unless the role description or recruiter points to one.

In week seven, run one complete loop simulation across the number and type of sessions you expect, with proper breaks. Use different questions and partners from prior mocks. Test food, water, room temperature, note-taking, and the transition between calls. A correct solution followed by a headache in the next round is an operational failure you can prevent.

Review your stories for consistency with the resume and application. AI writing tools make it easy to produce polished bullets that are broader than the work a candidate can defend. Every noun and number in your application should survive follow-up questions. If an assistant helped edit the language, compare the final text with your source facts and remove claims it introduced.

During week eight, reduce the load. Do short pattern reviews, one or two moderate coding sessions, a compact design walkthrough, and conversational story practice. Take the last full mock several days before the interview so you have time to fix a specific problem without carrying the emotional residue into the real loop.

Prepare a one-page logistics sheet with session times and time zone, recruiter contact, meeting method, permitted tools, required identification, and your questions for interviewers. Do not include solution notes or material you are not allowed to consult. Google's candidate guide recommends a computer, webcam, backup phone, paper and marker, and an equipment test; your confirmation email may change that list.

The day before, stop early. Read your application, check the setup, and sleep. One more difficult graph problem at midnight will not create a new capability. It can make the capability you built harder to access.

AI changed screening more than preparation

AI-assisted hiring made generic application language cheap, increased the temptation to outsource preparation, and pushed identity and authorship closer to the center of screening. It did not make clear reasoning, correct code, or defensible experience obsolete. The candidate's response should be better provenance and more realistic practice, not a contest to sound machine-optimized.

Do not claim to know Google's internal screening model. Public materials do not give candidates a full description of how every application is ranked, and practices can vary. Optimize for the role description and truthful evidence that works under either human or automated review: standard job titles where accurate, explicit relevant skills, dates that parse cleanly, and bullets that connect your action to a result. Keyword dumping and invisible text make an application worse for any serious reviewer.

Use AI before the interview as a coach you verify. It can generate variants of a problem, challenge a design assumption, simulate follow-up questions, inspect code you already wrote, or point out where a story lacks your personal action. Ask it to critique rather than author your identity. Keep a source record for application facts, and never accept a rewritten bullet until you can defend each claim without the tool.

The boundary changes when the interview starts. Google's current general virtual interview guide says, in direct terms, not to use AI to answer questions during the interview and warns that doing so results in disqualification. The same guide says candidates must submit their own work and identifies AI-generated answers or copied source code as disqualifying examples. That is clearer than forum debate. Close assistants, overlays, transcription bots that generate suggestions, and secondary devices unless your recruiter explicitly authorizes a tool as an accommodation or part of the exercise.

AI detection is not the skill to practice. Authorship is. You should be able to explain why every line exists, revise it when a constraint changes, and connect every experience claim to a memory of the actual work. An interviewer who asks an unexpected follow-up is testing the same continuity that generic AI prose tends to erase.

There is another distinction candidates blur: AI-assisted screening by an employer is not permission for AI-assisted answering by a candidate. One is a company process that may include policy and review controls. The other is governed by the instructions you receive. Fairness arguments do not override a written interview rule, and discovering the rule through disqualification is a poor experiment.

If a future invitation explicitly permits an AI assistant, treat that as a different round with a different observable skill. Practice specifying the task, checking generated code, finding subtle failures, and explaining what you accept or reject. Do not assume that policy from news about another company or another pilot. The recruiter and the written invitation define your session.

Interview day is controlled adaptation

On interview day, follow the process you rehearsed and adapt to the person in front of you. Join early, confirm audio and the working medium, and listen to the full prompt. If the connection fails, say so immediately and use the recruiter contact or backup method. Concealing a technical problem wastes time and can make a communication failure look like a reasoning failure.

When you get stuck, expose the useful state of the problem. Summarize what you know, identify the assumption blocking progress, and offer a simpler version or brute-force baseline. This gives the interviewer something concrete to respond to. Repeating "I am thinking" while staring at the editor does not.

Treat follow-up questions as new constraints, not verdicts on the first answer. Confirm what changed, preserve any work that still applies, and revise. If you find a bug, state it, repair it, and retest the affected case. Hiding a defect after you notice it destroys more confidence than making an ordinary mistake.

Between sessions, do not autopsy the previous round. Write one factual note if needed, drink water, and reset. Candidates routinely misread neutral interviewer behavior and spend the next interview litigating a failure that may not have happened. Your next interviewer needs your full attention.

If the loop changes, a round is rescheduled, or a recruiter adds a format you did not prepare for, ask for the exact expectation and revise the remaining calendar. The eight-week plan is not sacred. Its purpose is to keep evidence, practice, and risk visible while circumstances move.

Founders reading this for their own hiring should notice the same lesson: a defined rubric and observable work beat question folklore, and the Team & AI Audit at oleg.is applies that discipline to engineering roles, workflows, and staffing costs. Candidates should keep their focus narrower. Bring work you own, a process you can explain, and enough rest to use both.