PracHub
QuestionsLearningGuidesInterview Prep
|Home/Software Engineering Fundamentals/Google

Find the Most Frequent IP Addresses in a File Too Large for Memory

Last updated: Jul 22, 2026

Quick Overview

Design an exact, bounded-memory method for finding the most frequent IP addresses in a file far larger than RAM. Analyze memory and disk-I/O trade-offs while defining address normalization, malformed-record handling, deterministic ties, skew behavior, temporary-storage limits, and cleanup.

  • medium
  • Google
  • Software Engineering Fundamentals
  • Software Engineer

Find the Most Frequent IP Addresses in a File Too Large for Memory

Company: Google

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Onsite

# Find the Most Frequent IP Addresses in a File Too Large for Memory You receive a file containing billions of IP-address records, one record per line. Design an implementation that returns the `k` addresses with the highest occurrence counts. The file is much larger than available RAM, but sequential disk scans are allowed. Define how malformed lines are handled, how ties are ordered, and whether IPv4 and IPv6 text is normalized before counting. Give precise time, memory, and disk-I/O complexity for your design. ### Constraints & Assumptions - The available memory budget is known and substantially smaller than the file. - The exact result is required; an approximate heavy-hitters answer is not sufficient unless discussed as a follow-up. - Temporary disk space is available but should be bounded and cleaned up safely. - `k` is small compared with the number of distinct addresses. ### Clarifying Questions to Ask - Must differently formatted but equivalent IPv6 addresses count as the same key? - Is input compressed, and may it be read more than once? - What deterministic order should break equal-count ties? - What are the memory and temporary-storage budgets? ### What a Strong Answer Covers - A bounded-memory exact counting strategy - Stable partitioning or external sorting and safe temporary-file handling - A size-`k` selection structure after aggregation - Complexity expressed in records, distinct keys, partitions, and disk passes - Skew, malformed input, normalization, and operational failure cases ### Follow-up Questions - How would the design change for an unbounded stream? - When would an approximate sketch be preferable? - How could multiple machines process the file in parallel? - How would you avoid one extremely frequent address creating a hot partition?

Quick Answer: Design an exact, bounded-memory method for finding the most frequent IP addresses in a file far larger than RAM. Analyze memory and disk-I/O trade-offs while defining address normalization, malformed-record handling, deterministic ties, skew behavior, temporary-storage limits, and cleanup.

Related Interview Questions

  • Deduplicate and Order Batch and Streaming Logs - Google (medium)
  • Build a Custom CompletableFuture: Async Primitive and Parallel Array Processing - Google (medium)
  • Plan a Safe Repository-Wide Identifier Migration - Google (hard)
  • Process Sharded Login Logs - Google (medium)
|Home/Software Engineering Fundamentals/Google

Find the Most Frequent IP Addresses in a File Too Large for Memory

Google logo
Google
Jun 17, 2026, 12:00 AM
mediumSoftware EngineerOnsiteSoftware Engineering Fundamentals
0
0

Find the Most Frequent IP Addresses in a File Too Large for Memory

You receive a file containing billions of IP-address records, one record per line. Design an implementation that returns the k addresses with the highest occurrence counts. The file is much larger than available RAM, but sequential disk scans are allowed.

Define how malformed lines are handled, how ties are ordered, and whether IPv4 and IPv6 text is normalized before counting. Give precise time, memory, and disk-I/O complexity for your design.

Constraints & Assumptions

  • The available memory budget is known and substantially smaller than the file.
  • The exact result is required; an approximate heavy-hitters answer is not sufficient unless discussed as a follow-up.
  • Temporary disk space is available but should be bounded and cleaned up safely.
  • k is small compared with the number of distinct addresses.

Clarifying Questions to Ask Guidance

  • Must differently formatted but equivalent IPv6 addresses count as the same key?
  • Is input compressed, and may it be read more than once?
  • What deterministic order should break equal-count ties?
  • What are the memory and temporary-storage budgets?

What a Strong Answer Covers Guidance

  • A bounded-memory exact counting strategy
  • Stable partitioning or external sorting and safe temporary-file handling
  • A size- k selection structure after aggregation
  • Complexity expressed in records, distinct keys, partitions, and disk passes
  • Skew, malformed input, normalization, and operational failure cases

Follow-up Questions Guidance

  • How would the design change for an unbounded stream?
  • When would an approximate sketch be preferable?
  • How could multiple machines process the file in parallel?
  • How would you avoid one extremely frequent address creating a hot partition?
Loading comments...

Browse More Questions

More Software Engineering Fundamentals•More Google•More Software Engineer•Google Software Engineer•Google Software Engineering Fundamentals•Software Engineer Software Engineering Fundamentals

Write your answer

Your first approved answer each day earns 20 XP.

Sign in to write your answer.
PracHub

Master your tech interviews with 8,500+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.