← Google Interview Insights

Google·Machine Learning Engineer·Onsite - Coding / Algorithms·Senior

SeniorPrefer not to say
May 2026

Summary

Google MLE coding round focused on a web crawler problem. The interviewer was a long-tenured Googler who clearly cared a lot about Python internals, and I was not prepared for that angle at all.

Questions Asked (4)

Q1

Implement a web crawler using both DFS and BFS approaches.

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

Got both solutions down, which felt fine in the moment.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (scale, politeness, deduplication) and then present a unified crawler architecture with a pluggable frontier that can operate as either a stack (DFS) or queue (BFS). Explain the trade-offs between DFS and BFS for crawling, including memory, completeness, and politeness, and tie the choice to ML data collection needs like coverage and freshness.

Pro tip: Emphasize politeness and distributed crawling early—Google cares about not hammering servers and about scaling to billions of pages; mentioning robots.txt, rate limiting, and sharding shows production maturity.

1. Clarify requirements and constraints

Ask about scale, politeness, deduplication, and whether the crawler is for training data or indexing. This shapes the choice of DFS vs BFS and the need for distributed processing.

2. Design a unified crawler architecture

Outline components: URL frontier, fetcher, parser, deduplication (Bloom filter), and storage. Highlight that DFS and BFS differ only in the frontier's data structure (stack vs queue).

3. Implement DFS and BFS variants

Describe DFS using a stack (LIFO) and BFS using a queue (FIFO), with pseudocode. Mention iterative implementations to avoid recursion limits and handling of cycles via visited set.

4. Analyze trade-offs

Compare DFS and BFS on memory usage, completeness, politeness, and suitability for ML data collection. For example, BFS gives breadth and freshness, DFS may go deep but risk missing important pages.

5. Discuss scaling and production concerns

Cover distributed crawling with multiple workers, sharding the frontier, rate limiting per domain, robots.txt compliance, and handling dynamic content. Relate to ML needs like data quality and coverage.

Key Points to Mention

  • Frontier data structure: stack for DFS, queue for BFS
  • Deduplication using Bloom filters or hash sets to avoid revisiting URLs
  • Politeness: robots.txt, crawl-delay, rate limiting per domain
  • Distributed crawling: sharding by domain, consistent hashing, coordination
  • Trade-offs: memory (DFS O(depth) vs BFS O(width)), completeness, freshness
  • ML relevance: BFS for broad coverage, DFS for deep dives into specific sites

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How does Python handle instance behavior and what are the implications for this kind of recursive solution?

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

Fumbled this pretty badly.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by explaining Python's instance behavior: instance attributes are stored in a per-instance dictionary, and method lookup follows the MRO. Then connect this to recursive solutions, discussing how recursion depth, state management, and performance are affected by Python's object model.

Pro tip: Mention that Python's default recursion limit and lack of tail-call optimization can cause stack overflows, so for deep recursion, consider iterative approaches or increasing the recursion limit with caution.

1. Explain Python's instance behavior

Describe how instance attributes are stored in __dict__ and how methods are bound to instances. Mention the role of __init__ and self.

2. Discuss method resolution order (MRO)

Explain how Python resolves method calls in inheritance hierarchies, which is crucial for recursive methods that may be overridden.

3. Analyze implications for recursion

Connect instance behavior to recursion: each recursive call may create new instances or modify instance state, affecting memory and correctness.

4. Address performance and limits

Discuss recursion depth limits, stack memory usage, and potential optimizations like memoization or iterative conversion.

5. Relate to machine learning context

Tie the discussion to ML scenarios, such as recursive algorithms in tree-based models or graph neural networks, highlighting trade-offs.

Key Points to Mention

  • Instance attributes are stored in a per-instance dictionary (__dict__), which can be modified dynamically.
  • Method binding: functions defined in a class become bound methods when accessed via an instance, passing self implicitly.
  • Recursion in Python has a default limit (usually 1000) and no tail-call optimization, risking stack overflow.
  • Recursive solutions may create many instances, increasing memory overhead; consider using __slots__ to reduce memory.
  • State management: mutable instance attributes can lead to unintended side effects across recursive calls if not handled carefully.
  • For ML, recursive algorithms like decision tree induction or recursive feature elimination can benefit from understanding these implications.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

What are Python's recursion and stack depth limits, and how would they affect a DFS-based crawler?

Algorithms & Data StructuresSystem Design
Author's notes

Knew there was a default recursion limit, said something like 'you can increase it with sys.setrecursionlimit' and left it there.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by explaining Python's default recursion limit (typically 1000) and how it's enforced by the interpreter's call stack. Then discuss how a DFS-based crawler using recursion can hit this limit on deep websites, and propose iterative alternatives or increasing the limit with caution. Finally, relate this to system design considerations for scalable crawling.

Pro tip: Mention that while you can increase the recursion limit with sys.setrecursionlimit(), it risks a C stack overflow and is not a scalable solution; instead, emphasize iterative DFS with an explicit stack for production systems.

1. State Python's recursion limit

Explain that Python's default recursion limit is 1000, set by sys.getrecursionlimit(), and that exceeding it raises a RecursionError. Mention that it can be adjusted but with risks.

2. Explain stack depth and memory

Describe how each recursive call adds a frame to the call stack, consuming memory. Deep recursion can lead to stack overflow or excessive memory usage, especially in a crawler traversing many pages.

3. Impact on DFS-based crawler

Discuss how a recursive DFS crawler can easily hit the recursion limit on sites with deep link hierarchies (e.g., >1000 levels). This would cause the crawler to crash or require error handling.

4. Propose solutions

Suggest converting the recursive DFS to an iterative one using an explicit stack (e.g., list or deque). Alternatively, mention increasing the recursion limit as a temporary fix but highlight its dangers.

5. Relate to system design

Tie this to broader system design: for a production crawler at Google scale, iterative approaches are preferred for scalability, and other factors like distributed crawling and memory management should be considered.

Key Points to Mention

  • Python's default recursion limit is 1000, adjustable via sys.setrecursionlimit().
  • Each recursive call consumes stack memory; deep recursion can cause RecursionError or C stack overflow.
  • A DFS-based crawler using recursion may fail on deep websites (e.g., >1000 levels).
  • Iterative DFS with an explicit stack avoids recursion limits and is more memory-efficient.
  • Increasing the recursion limit is risky and not scalable for production systems.
  • For large-scale crawling, consider distributed or breadth-first approaches to manage depth and resources.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

What kinds of hash-related bugs could appear in a web crawler implementation?

Algorithms & Data StructuresRoot Cause Analysis
Author's notes

Completely unprepared for this.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the role of hashing in a web crawler, such as URL deduplication, content fingerprinting, and caching. Then systematically discuss potential hash-related bugs, including collisions, inconsistent hashing, and hash function weaknesses, and how they could impact crawler behavior. Finally, relate these bugs to broader system reliability and ML data quality issues.

Pro tip: Emphasize that hash collisions in URL deduplication can lead to missed pages, which directly affects training data completeness and model performance. Mentioning real-world examples like the Google crawler's scale shows you understand production challenges.

1. Identify hash use cases in crawlers

List where hashing is used: URL deduplication, content checksums, bloom filters for visited links, and caching. This sets the context for potential bugs.

2. Analyze collision-related bugs

Discuss how hash collisions can cause false positives in deduplication (skipping unique URLs) or false negatives (crawling duplicates), leading to incomplete or redundant data.

3. Examine hash function and implementation issues

Consider bugs from weak hash functions (e.g., MD5 collisions), inconsistent hashing across distributed nodes, or improper handling of hash outputs (e.g., truncation).

4. Assess impact on crawler and ML pipeline

Explain consequences: reduced crawl coverage, biased training data, increased storage costs, and potential model degradation due to missing or duplicated content.

5. Propose mitigation strategies

Suggest solutions like using cryptographic hashes (SHA-256), consistent hashing, collision-resistant data structures, and monitoring hash distribution.

Key Points to Mention

  • Hash collisions leading to URL deduplication errors (false positives/negatives)
  • Inconsistent hashing across distributed crawler nodes causing duplicate crawls
  • Weak hash functions (e.g., MD5, SHA-1) vulnerable to collision attacks
  • Hash truncation or modulo operations increasing collision probability
  • Impact on ML training data: missing pages, duplicates, and bias
  • Mitigation: use strong hashes, consistent hashing, and bloom filters with low false positive rates

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.