Google runs one centrally-designed loop that varies mostly in the content of its technical rounds: a recruiter conversation, an optional online assessment or role-related project, then a panel of independent 45-minute interviews scored against fixed rubrics, followed by team matching and a hiring-committee decision that the interviewers themselves do not make. Engineering candidates get three to four algorithm-heavy rounds plus a Googleyness behavioural round; data, product, program, design, sales and data-centre candidates get the same four-signal frame (Role-Related Knowledge, General Cognitive Ability, Leadership, Googleyness) delivered as SQL and data-modelling, product cases, pitch roleplays, portfolio reviews or troubleshooting scenarios instead. The long tail after a positive panel (team matching, then hiring committee) is where several accounts stall or get downlevelled even after strong interview feedback.
These 25 writeups cover software engineering, site reliability engineering, data engineering and other roles. 20 of them were posted under a pseudonym (Reddit, GeeksforGeeks or forum handles), so we could not verify the authors’ identities.
Typical rounds
3.91-8 range
Outcomes shared
9/9offer / not
Most common round
Technical
Sources span
2008 - 2026
Most frequently reported · Resume deep-dive(18), Data structures & algorithms(15), Behavioral(13), Arrays & strings(10), Past projects(10)
Alphabet’s official process
Google publishes the whole shape of its process. It says the basics are the same whether the role is engineering or marketing, intern or leadership, and that the loop normally runs about six to eight weeks. Steps it names: a resume review (it explicitly recommends the 'accomplished X as measured by Y, by doing Z' formula and says cover letters are not required); a cap of three applications per rolling 30 days; possibly the Google Hiring Assessment plus role-specific assessments such as a coding exercise; one or two recruiter conversations; optional project work such as a case study, writing sample or code sample; then a panel of interviews with a rotating set of Googlers, video or in person. It stresses structured interviewing against identical rubrics per role and open-ended, role-related questions, states flatly that brainteasers have not been used in years, and bans AI tool use during interviews. Decisions are made collectively rather than by the interviewers, and the recruiter delivers the offer. Reapplication for the same type of role is suggested after about a year.
A recruiter call covering her prior internship, the projects and tech stack behind it, her competitive-programming profiles and which language she wanted to code in. Ended with scheduling, and she was able to push the technical round out by two weeks because of end-semester exams.
Covered · Resume deep-dive, Past projects
2
Technical interview 1Technical
Two problems delivered in a shared Google doc. The first was stated in a single line with no test cases and she was asked to invent edge cases herself before proposing an approach; the second, with about ten minutes left, was a DP problem she took from recursion to memoisation. Closed with a few minutes on Google's culture.
A graph problem followed by a graph-based follow-up, with two approaches compared on time and space before the interviewer steered her to the better one. He probed her choice of a hash map of lists over a plain adjacency list.
Covered · Graphs, Data structures & algorithms
4
Transcripts and offer callFinal
The recruiter asked for all academic transcripts on short notice, then called the next day with the intern offer.
A 60-minute test in which each candidate got two problems drawn from a pan-India pool of eight, most of them medium difficulty with a couple of hard ones.
Covered · Data structures & algorithms
2
TechnicalTechnical
A single problem about reconstructing an array consistent with several remembered subsequences, which reduces to a topological ordering. He gave both BFS and DFS formulations and coded them in roughly 25 minutes, then fielded several short follow-up questions.
Covered · Graphs, Data structures & algorithms
3
Technical plus behavioralTechnical
A minimum-sum fixed-size submatrix problem solved with prefix sums, then pushed to constant extra space, then varied so that zero-valued cells disqualify a submatrix. Ended with a handful of situational questions.
Covered · Arrays & strings, Behavioral
4
Technical plus behavioralTechnical
An 'odd one out' word problem where the goal is to find the item whose removal maximises the attributes shared by the rest. A disjoint-set attempt failed before he landed on a prefix-and-suffix set-intersection approach; coding it took about forty minutes, leaving time for Googliness questions.
Two algorithm problems; 30 students from the campus cleared it into the interview stage.
Covered · Data structures & algorithms
2
DSA (45 min)Technical
A shortest-path-under-a-deadline problem over flight objects with arrival and departure times, solved with BFS. He spent the first fifteen minutes explaining the algorithm, coded it in twenty, then fixed an edge case found during a dry run before a follow-up variant.
Covered · Graphs, Data structures & algorithms
3
DSA plus Googlyness (60 min)Technical
A weighted-tree problem requiring edge deletions so that no two original leaves stay connected, minimising deleted weight. He iterated for half an hour and only got a brute-force solution out, then spent the last fifteen minutes on leadership questions about running teams and college events.
Covered · Trees, Behavioral, Conflict handling
4
DSA plus Googlyness (60 min)Technical
His strongest round: a DP problem about maximising distance travelled given a fuel budget and a fixed number of rest days, coded recursively then memoised, with three follow-ups escalating it from 2D to 3D DP. Closed with Googlyness questions about credit-stealing and taking a stand.
He rated this the hardest stage: instead of the usual medium-plus-hard pairing he got two hard problems with follow-ups, built on array operations and bitmasking.
Covered · Arrays & strings, Data structures & algorithms
2
Onsite technical 1Technical
A binary search over real-valued answers with a follow-up, plus a discussion of his own projects.
Covered · Data structures & algorithms, Past projects
3
Onsite technical 2Technical
A classic priority-queue and heap problem, with the twist that the input arrived as a file so he also had to write the reading logic.
Covered · Data structures & algorithms
4
Onsite technical 3Technical
A sliding-window problem using sets with two follow-ups, and a long stretch of the round spent on code quality and object-oriented structure rather than the algorithm itself.
Covered · Arrays & strings, OOP, Testing
5
GoogleynessBehavioral
Five or six situational prompts he found the most intimidating part: conflict with a manager or teammate, handling failure, taking initiative outside your remit, helping a colleague, someone badmouthing you, and what to do when QA has not tested properly.
Covered · Behavioral, Conflict handling, STAR stories
6
Team matchingHiring manager
Three separate team-matching conversations. End to end the process ran about two months from first recruiter call to team matching.
The recruiter laid out exactly what would be graded: syntactically correct modular code with sensible naming, an optimal algorithmic solution with a known complexity, continuous thinking aloud, and coding speed under time pressure.
Covered · Resume deep-dive
2
Phone screen (45 min)Phone screen
An easy hashing-based problem plus a harder follow-up. The feedback relayed afterwards was unusually granular, covering thought process, communication, coding speed and language depth.
Covered · Arrays & strings, Data structures & algorithms
3
Onsite coding 1 (45 min)Technical
A medium pattern-matching problem and a follow-up, then a discussion of how the same approach would hold up at scale.
Covered · Arrays & strings, Scalability
4
Onsite coding 2 (45 min)Technical
A medium string problem; once he had coded it the interviewer changed a core part of the requirement to see how flexibly the code could be adapted.
Covered · Arrays & strings, Data structures & algorithms
5
Onsite coding 3 (45 min)Technical
A hard graph question he could not crack directly, so he decomposed it and optimised piece by piece, arriving with the interviewer's help at a traversal-plus-DP solution.
Covered · Graphs, Dynamic programming
6
GoogleynessBehavioral
Situational questions about how he would react as a Googler in various workplace scenarios. His recruiter's only advice was to be honest, and he found it the most enjoyable round.
Covered · Behavioral, Conflict handling
7
Team matchHiring manager
Two 30-minute conversations with managers of teams he had ranked, discussing the work he had done and wanted to do.
Covered · Past projects
8
Hiring committeeFinal
The recruiter assembled a packet of interview feedback, documents and internal references for a committee he never met; the criteria were opaque to him.
Introduction, preferred language, tech-stack knowledge, number and type of projects, and availability for technical rounds.
Covered · Resume deep-dive, Past projects
2
DSATechnical
A problem she could not find on any standard practice site. She walked through a quadratic brute force, then a linear hash-map solution which she coded, then offered a third alternative when asked for more approaches.
Covered · Arrays & strings, Data structures & algorithms
3
DSATechnical
A long, hard-to-parse problem statement. She needed clarification, attempted a list-based solution that did not impress, and could not use the hints because she had not covered the required data structures.
Application Engineer Intern (on-campus, intern plus PPO)
Internship
Not selected2 rounds
1
Technical (50 min)Technical
After a self-introduction, two tree problems: flattening an N-ary tree, and a traversal built on parent, left-child and right-sibling pointers. Both were answered correctly.
Covered · Trees, Data structures & algorithms
2
System design (50 min)System design
An open design of an e-commerce site, covering components, features and overall architecture. This round ended the process for him.
A resume-led call: self-introduction and skills, where he saw himself in two years, whether he had worked with large datasets, a walk through internship and personal projects and the technologies used, why he settled on C++, and a light question on the steps involved in designing a web application from a flowchart. The recruiter closed by explaining that later rounds would centre on problem solving, coding and design, and gave him direct feedback on his answers.
Covered · Resume deep-dive, Past projects, System design
Google ran a group briefing for all shortlisted candidates about a week before interviews, explaining that the loop would be four technical rounds focused on problem solving and coding.
Covered · Resume deep-dive
2
TechnicalTechnical
An intervals-over-arrays problem. He offered two approaches with complexities, which the interviewer accepted, but made a small coding error he could not fix within the time even after a hint. The rejection email arrived the same evening.
Covered · Arrays & strings, Data structures & algorithms
A screening call on CGPA, preferred language, familiarity with data structures and algorithms, and coding-platform profiles.
Covered · Resume deep-dive
2
Google prep sessionPhone screen
Google ran an optional preparation session two days later, emphasising explaining the approach before coding, clean naming and structure, justifying why the chosen solution fits, and practising under time limits.
Covered · Testing, Debugging
3
Technical (45 min)Technical
A graph problem with discussion of optimisation strategies and edge cases. He reached a working but not fully optimised solution and got real-time feedback from the interviewer; the rejection followed after a long wait.
A medium recursion problem solved in time, followed by a request to re-implement the same idea with a different data structure, which she also handled.
Covered · Data structures & algorithms
2
Technical (45 min)Technical
An easier base problem where the real test was the follow-up: optimising the brute force and covering edge cases. She got the brute force out cleanly but stalled on the optimisation and went quiet while stuck, which she saw afterwards as the fatal mistake.
Software / Data Analytics Apprentice (Google India Apprenticeship 2025)
Internship
Not selected2 rounds
1
Online challenge (90 min)Online assessment
A HackerEarth-hosted test with two problems: a minimum-cost string transformation that needed DP, and an array-shrinking task collapsing duplicate elements into sums while preserving relative order. Both were solved.
Covered · Dynamic programming, Arrays & strings
2
Recruiter callPhone screen
About two and a half months later, a recruiter asked for a self-introduction, his best language, how many practice problems he had solved and a self-rating on data structures, why he had applied to both the software and analytics tracks, and his data-science and AI background. He fumbled the introduction and was cut after this round.
A pure resume screen that eliminates most applicants. He advises a single page ordered education, work experience, projects, competitive-programming profiles, achievements, bulleted and linked.
Covered · Resume deep-dive
2
Technical (45 min)Technical
Strictly timebox 45 minutes, a couple of minutes of introduction then either two mediums or one hard. He puts the difficulty around Codeforces Div2 B/C and says the recurring areas were shortest paths, minimum spanning trees, topological sort, Eulerian paths, tree DP, combinatorics and tree queries.
Covered · Graphs, Trees, Dynamic programming
3
Technical (45 min)Technical
Same format. He initially could not even parse what the question was asking and got there with the interviewer's hints, which he credits for the round going well.
Covered · Graphs, Dynamic programming
4
Hiring committeeFinal
The recruiter packaged his resume and interview feedback for a committee that returns hire, no hire, or a request for extra interviews when the existing feedback is inconclusive.
Inbound recruiter contact on LinkedIn in early February, with the call five weeks later.
Covered · Resume deep-dive
2
Technical screenTechnical
A two-pointer and greedy problem in a pattern he had not met before. He reached the time-optimal but not space-optimal solution, took a hint, and then coded a harder follow-up optimally.
Covered · Arrays & strings, Data structures & algorithms
3
GoogleynessBehavioral
Ran the day after the screen. He answered in STAR format and found the questions close to what public writeups had led him to expect.
Covered · Behavioral, STAR stories
4
Onsite technical 1Technical
A heap-based problem he identified and coded quickly, with a straightforward follow-up.
Covered · Data structures & algorithms
5
Onsite technical 2Technical
A DP problem he solved fast, with an unusual follow-up that took a brief struggle to crack.
Covered · Dynamic programming
6
Team matchingHiring manager
Panel feedback was uniformly positive and he moved to team matching; the first hiring-manager call went well and the recruiter signalled the manager wanted to hire him. Final approval then downlevelled him to L3, which disqualified him from that role, and no second match followed.
Outcome not sharedcompensation expectations discussed at recruiter screen5 rounds
1
Recruiter screen (30 min)Phone screen
Current role, total experience, compensation expectations, motivation for moving, and an overview of the process. No technical questions.
Covered · Resume deep-dive
2
Technical (45 min)Technical
A medium-to-hard problem combining a trie with a hash map. He got a working solution, stalled on optimising it, and finished after hints; follow-ups covered alternatives, complexity, edge cases and the memory-versus-lookup trade-off. Rated strong hire.
Covered · Arrays & strings, Data structures & algorithms
3
Technical (45 min)Technical
A hard graph problem requiring a modified disjoint-set-union. Follow-ups pressed on correctness of union and find, path compression, union by rank or size, complexity and disconnected components. His implementation got messy under time pressure but the round was still rated strong hire.
Covered · Graphs, Data structures & algorithms
4
Technical plus domain discussionTechnical
A problem combining DP and binary search where the interviewer walked him from recursion to memoisation to an optimal binary-search formulation. Because he works as an AI engineer, the last stretch became a discussion of production generative-AI use cases, agentic workflows, evaluation, latency, cost and deployment at scale.
His weakest round: one algorithm problem he did not finish plus Googliness, collaboration and decision-making questions. He went silent when stuck instead of restating what he knew and naming the blocker. Rated lean hire.
Covered · Behavioral, Conflict handling, Data structures & algorithms
He had applied for an internship months earlier; a recruiter resurfaced and offered a full-time L3 loop instead. Background and motivation questions only.
Covered · Resume deep-dive
2
Technical screenTechnical
One medium problem. His solution worked but was neither clean nor optimal and the recruiter called the feedback 'not the strongest', yet he was advanced on the strength of how quickly he learned.
Covered · Data structures & algorithms
3
Onsite technical 1Technical
A DP problem. He kept communication flowing and reached a working but inelegant solution.
Covered · Dynamic programming
4
Onsite designLow-level design
Build the class structure for a game with full functionality, then a deliberate mid-round requirement change framed as a product manager reversing the spec. He restructured the design and handled the follow-ups; his best round.
Covered · Low-level design, OOP, API design
5
Onsite technical 2Technical
Another DP problem taken from brute force to memoisation, ending with a joint edge-case hunt where he found two and the interviewer added two more.
Covered · Dynamic programming, Testing
6
BehavioralBehavioral
Almost entirely about his first internship: being onboarded in days, inheriting a project with an active backlog after the previous developer left, owning client communication and delivering on time.
Unusually technical for a recruiter call: after explaining the architecture-heavy role, the recruiter asked two SQL problems, one Python and one Spark problem, eight to ten theory questions and standard fit questions. He then asked for three weeks to prepare and spent all of it on algorithms.
Covered · SQL, Domain knowledge, Resume deep-dive
2
Role-Related KnowledgeTechnical
Roughly four-fifths theory: big-data technologies, warehousing, Google Cloud services and hypothetical solution-design questions. His strongest round, rated strong hire.
Covered · Domain knowledge, System design, Scalability
3
General Cognitive AbilityTechnical
Split in two. First he had to build a data model for a real-world system, then answer three or four SQL questions against his own model, so a weak model poisons everything after it. Then a single algorithm problem of roughly medium difficulty, solved with hints. He rated his own data modelling below par because he had prepped only coding.
Covered · SQL, System design, Data structures & algorithms
4
GoogleynessBehavioral
Two hypothetical and two behavioural questions over about forty minutes. He prepared four days specifically for it after the recruiter warned that candidates routinely fail here.
Received an offerdescribed the offer as underwhelming and left for another employer after a year4 rounds
1
Recruiter call (30 min)Phone screen
Role details and levelling, with the recruiter reluctant to discuss compensation, which he found frustrating.
Covered · Resume deep-dive
2
Hiring manager (50 min)Hiring manager
General problem-solving scenarios followed by product-specific analytics questions grounded in a real Google product, such as how you would measure spam or abusive use of the browser.
Covered · Case study, Domain knowledge
3
Technical (60 min)Technical
Pure SQL, ramping from easy queries into self joins, running totals, percentiles and window functions. He found it easier than expected.
Covered · SQL
4
Googlyness (45 min)Behavioral
A values round digging into past experience, including disagreements with managers and handling underperforming teammates. The decision came back within a week.
Covered · Behavioral, Conflict handling, STAR stories
A conventional PM round which he felt went well, prompting the second round.
Covered · Case study, Domain knowledge
2
Vibe-coding build (45 min)Technical
A format he had never seen documented anywhere and was not warned about: build a working AI application live inside the interview. He dived straight into an agent backend with tool calling, blanked on the implementation under stress and never produced a structure. In hindsight he thinks the round wanted a product-design approach, a short requirements doc turned into a prompt and then built in an AI app-builder.
Standard screening call ahead of the product rounds.
Covered · Resume deep-dive
2
Product senseTechnical
A 45-minute product case with a PM. She ran a modified CIRCLES-style framework: state the outline, clarify, pause to write structured questions about business need, scope, timeline and constraints, then user segmentation with demographics and psychographics and a single prioritised segment.
Covered · Case study, Market sizing
3
Product interview with a PM directorTechnical
Same 45-minute product-case shape one level up. Her approach was to propose two solutions explicitly, name which she was prioritising, outline an MVP then the expansion, and check in with the interviewer at each transition to keep it collaborative.
Covered · Case study, Market sizing
4
Case study on business needCase study
A business-need case closing on risks, trade-offs and KPIs: engineering capacity, adoption, supply and timeline risks, what was deprioritised and why, and product-appropriate success metrics.
Technical Program Manager (Google Cloud, Kirkland)
Experienced
Received an offer4 rounds
1
Recruiter phone interviewPhone screen
A single call sampling all four TPM signals: describe a favourite project, go deeper on its system design, describe finding something broken in a product and fixing it with the team, and give an example of helping a teammate.
Covered · Past projects, System design, Behavioral
2
On-campus panelPanel
A day of interviews at the Kirkland campus, some interviewers in the room and some over video. Overwhelmingly behavioural and past-project driven; he ran out of prepared stories by the last interviews. He was never asked to write code but had to discuss technical design in depth.
Covered · Behavioral, STAR stories, Past projects, System design
3
Team matchingHiring manager
The recruiter circulated his packet to hiring managers; an interested Google Cloud Platform manager scheduled a call, they agreed on a match, and the manager wrote a letter of support that was added to the packet.
Covered · Past projects
4
Hiring committeeFinal
The committee, not the interviewers, made the hire decision from the assembled packet. The offer call came a couple of weeks later.
Thirty to forty-five minutes on background, communication and general interest, covering her design experience, projects and process. The recruiter then shared preparation resources.
Covered · Resume deep-dive, Past projects
2
Portfolio reviewTechnical
A video session where she walked a Google designer through her work and got feedback. She advises leading with problem-solving, ideation, communication, collaboration, execution and research rather than visuals. A preliminary team match happened after this.
Covered · Past projects, Case study
3
Portfolio interview (panel)Panel
A deeper version of the portfolio review in front of a panel of managers, designers and cross-functional partners, pressing on process, specific design decisions and how she attacks complex problems.
Covered · Past projects, Case study
4
One-on-one loopPanel
Four separate calls with different team members: cross-functional collaboration, design leadership, a design challenge, and Googliness. She was not selected but was given performance feedback and encouraged to reapply in a year.
Covered · Behavioral, Case study, Conflict handling
A conversation about his experience and career aspirations. The recruiter gave direct feedback on the structure of his answers before advancing him. He notes his first application to the same programme, two years earlier, ended in a rejection he treated as feedback.
Covered · Resume deep-dive, Behavioral
2
Sales case and pitchTechnical
Roughly twenty minutes of pitch plus twenty of general questions, run by a member of the hiring team. The interviewer played a marketing manager at a fictional company; he spent the first stretch diagnosing the client's business before mapping needs to Google Ads products and handling objections with product facts. Leadership and Googleyness questions followed. He notes that for other business roles this slot becomes open-ended questions or mini-cases, and for engineering roles a whiteboard interview.
Covered · Sales roleplay, Case study, Domain knowledge, Behavioral
3
Onsite panel, three back-to-back interviewsPanel
Three 30-to-45-minute interviews covering all four Google signals in no fixed order. The first, with his prospective manager, was a General Cognitive Ability round built on an open estimation and reasoning problem of the 'how would you increase profit per table at a restaurant' type, judged on logical structure rather than the answer. The second, with a manager from another team, was role-related knowledge on sales and digital marketing plus past-experience questions answered in STAR form. The third covered leadership and Googleyness.
Covered · Market sizing, Domain knowledge, Behavioral, STAR stories
The recruiter walked the process and had him self-rate zero to ten across C, C++, Python, networking, algorithms, distributed systems and Linux administration, which is what steered him from a software-engineer track to SRE. A light technical section on Linux administration, algorithms, architecture and C followed as a bluff check.
An engineer from the ads team opened with an out-of-core sorting problem and made him narrate the data structures he would use, then moved through data structures, DNS behaviour, TCP mechanics and a TCP-related security weakness.
Covered · Data structures & algorithms, Networking, Scalability
3
Phone codingTechnical
A simple set-difference program dictated over the phone, which proved impossible to speak aloud so he emailed the code, then escalated to how the solution changes at gigabyte and terabyte scale. Closed on DNS, HTTP and routing.
Forty-five minutes on a past project he built in C on Linux, and how it would change at very large user counts, ending with basic Unix filesystem questions.
Covered · Past projects, Operating systems
5
Onsite codingTechnical
Opened with a geometry trick question, then asked him to implement the general version in C and write a binary tree on the whiteboard, where the interviewer caught him leaving a freshly allocated structure uninitialised.
Covered · Trees, Data structures & algorithms
6
Onsite troubleshooting and networkingTechnical
The interviewer drew a network topology hiding a fault; he had to locate it purely by asking targeted diagnostic questions, then answer device- and OSI-model questions.
Covered · Networking, Debugging
7
Onsite codingTechnical
A single string-manipulation routine in C consumed the whole slot; he made an off-by-one error.
Covered · Arrays & strings
8
Onsite algorithms and data structuresTechnical
The out-of-core sort from the phone round made distributed: sort data that does not fit in memory across a hundred machines. He reached the correct map-reduce-shaped answer near the end, which the interviewer said few candidates do.
Covered · Data structures & algorithms, Scalability, Concurrency
Around twenty rapid-fire questions on PC and server hardware components, storage interfaces and partitioning, BIOS and boot, MAC addressing, cabling and connectors, common protocol ports, and Linux device and filesystem administration. Also his previous jobs and willingness to relocate.
Run by someone who worked in a data centre. The centrepiece was an open-ended triage scenario: a hundred machines are broken, how do you proceed. He felt he handled it poorly and later reasoned it should be attacked as a mind-map, establishing scope and severity, checking shared infrastructure like power and network, grouping machines by symptom, correlating with recent changes, and pulling logs and diagnostics. Also Linux boot and log questions, an imaging question, a 'how would you turn a room into a data centre' design question, and standard fit questions about colleagues and managers.
Google runs one centrally-designed loop that varies mostly in the content of its technical rounds: a recruiter conversation, an optional online assessment or role-related project, then a panel of independent 45-minute interviews scored against fixed rubrics, followed by team matching and a hiring-committee decision that the interviewers themselves do not make. Engineering candidates get three to four algorithm-heavy rounds plus a Googleyness behavioural round; data, product, program, design, sales and data-centre candidates get the same four-signal frame (Role-Related Knowledge, General Cognitive Ability, Leadership, Googleyness) delivered as SQL and data-modelling, product cases, pitch roleplays, portfolio reviews or troubleshooting scenarios instead. The long tail after a positive panel (team matching, then hiring committee) is where several accounts stall or get downlevelled even after strong interview feedback.
What topics does Alphabet test in interviews?
Commonly reported topics include Data structures & algorithms, Dynamic programming, Graphs, Trees, Arrays & strings, System design.
These guides summarize public, first-hand interview experiences shared by candidates. They describe the shape of each loop and the topics that came up, not a leaked question bank, and every experience links back to its original source. Processes change often; treat this as directional prep, not a script.
