Meta·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

May 2026

Summary

Meta SWE onsite, object-oriented design round. The problem was a cloud file system with users, quotas, and a bunch of methods to implement. More moving parts than I expected for an OOD question and it kept growing.

Questions Asked (4)

Design an in-memory cloud file system class that supports files with unique names and sizes, users with storage quotas, and an admin user with infinite capacity. Implement methods to add users, add files (by admin or by a specific user), retrieve file sizes, and delete files.

System DesignData ModelingAlgorithms & Data Structures

Author's notes

The core CRUD stuff was fine.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and edge cases, then design a class with a map for users (each with quota and files) and a global map for files to ensure unique names. Implement methods for adding users, adding files with quota checks, retrieving file sizes, and deleting files, handling admin privileges and ownership.

Pro tip: Proactively discuss concurrency and thread-safety, as in-memory systems often require synchronization; mention using locks or concurrent data structures to handle simultaneous operations.

1. Clarify Requirements and Constraints

Ask questions to confirm assumptions: Are file names globally unique? Can users delete files they don't own? What happens when quota is exceeded? Should operations be thread-safe?

2. Design Data Model

Define classes: User (name, quota, used space, files), File (name, size, owner), and FileSystem (users map, files map). Consider using a global map for files to enforce unique names and a map for users.

3. Implement Core Methods

Write methods: addUser, addFile (checking quota and uniqueness), getFileSize, deleteFile (updating user's used space and removing from global map). Handle admin as a special user with infinite quota.

4. Handle Edge Cases and Errors

Address cases like duplicate file names, quota exceeded, non-existent users/files, and unauthorized deletions. Return appropriate errors or exceptions.

5. Discuss Extensibility and Optimization

Mention potential improvements: thread-safety with locks, efficient quota tracking, or supporting directories. Also consider time/space complexity of operations.

Key Points to Mention

Use a global map to enforce unique file names across all users.
Track each user's used storage to efficiently check quotas before adding files.
Admin user should bypass quota checks and can add files on behalf of any user.
Deletion should update both the global file map and the owner's used storage.
Consider thread-safety for concurrent operations, e.g., using synchronized methods or concurrent collections.
Discuss error handling for invalid operations (e.g., duplicate file, quota exceeded, missing user/file).

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

Add a method to retrieve the N largest files whose names start with a given prefix, sorted by size descending and then name ascending for ties, formatted as 'name(size)'.

Algorithms & Data StructuresSystem Design

Author's notes

Sorting with a tie-breaker tripped me up for a second.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the input format (e.g., list of file objects or directory traversal) and constraints (N, prefix, tie-breaking). Then propose an efficient solution using a min-heap of size N while iterating through files, or sorting if the dataset is small, and discuss trade-offs. Finally, outline the implementation details for filtering by prefix, maintaining the heap, and formatting the output.

Pro tip: Discuss the trade-off between using a heap (O(M log N) time, O(N) space) and sorting (O(M log M) time) based on expected data size, and mention that for very large datasets, a distributed approach like MapReduce could be used.

1. Clarify requirements and constraints

Ask about the input format (e.g., list of files, directory path), the expected size of the dataset, and whether N is small relative to total files. Confirm the sorting order and formatting.

2. Choose the right data structure

Decide between a min-heap of size N for efficiency or sorting all matching files. Explain why a heap is better for large datasets when N is small.

3. Outline the algorithm

Describe the steps: iterate through files, filter by prefix, maintain a min-heap of size N based on size (and name for ties), then extract and sort the heap to produce the final list.

4. Handle edge cases and formatting

Consider cases like fewer than N matching files, empty results, and ties. Explain how to format each file as 'name(size)' and sort the final list by size descending and name ascending.

5. Analyze complexity and scalability

State time and space complexity, and discuss how the solution scales. Mention potential optimizations like parallel processing or distributed computing for massive datasets.

Key Points to Mention

Time and space complexity of the heap-based approach vs. sorting
Use of a min-heap to keep track of the N largest files efficiently
Custom comparator for tie-breaking: size descending, then name ascending
Efficient prefix matching (e.g., using startsWith or trie if many queries)
Edge cases: N larger than matching files, empty prefix, no matches
Formatting the output string as 'name(size)'

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

Add a merge_user method that transfers all files from one user to another, combines their remaining capacities, and deletes the source user.

System DesignData Modeling

Author's notes

Pretty straightforward once I saw it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the data model and requirements, then outline a transactional merge operation that reassigns files, combines capacities, and deletes the source user. Discuss trade-offs around consistency, concurrency, and failure handling, and propose a scalable implementation.

Pro tip: Emphasize idempotency and atomicity: design the operation to be safely retryable and all-or-nothing, which is critical in distributed systems like Meta's.

1. Clarify Requirements and Data Model

Ask about the user and file schemas, capacity semantics (e.g., total vs. remaining), and constraints like file ownership or sharing. Confirm whether the operation must be atomic and how to handle concurrent merges.

2. Design the Merge Algorithm

Outline steps: validate users, transfer files (update ownership), combine capacities (sum remaining), and delete source user. Consider batching for large file sets and updating any indexes or references.

3. Ensure Atomicity and Consistency

Propose using a transaction or distributed transaction protocol to guarantee all-or-nothing. Discuss locking strategies to prevent race conditions, such as locking both user records during the operation.

4. Handle Failures and Idempotency

Design for retries: make the operation idempotent by tracking merge status or using unique operation IDs. Describe rollback or compensation logic if partial failure occurs.

5. Address Scalability and Performance

Consider sharding, asynchronous processing for large merges, and minimizing impact on live traffic. Discuss monitoring and logging for observability.

Key Points to Mention

Atomicity and transactional guarantees (ACID or distributed transactions)
Idempotency and safe retries to handle failures
Concurrency control (locking, optimistic concurrency) to prevent race conditions
Data consistency across file ownership, capacity, and user deletion
Scalability considerations for large numbers of files or users
Error handling and rollback strategies

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

Implement backup_user and restore_user methods: backup snapshots a user's current files, and restore re-applies that snapshot while skipping any filenames already taken by other users.

System DesignTechnical Trade-offsData Modeling

Author's notes

This one got complicated fast.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then design a data model that captures snapshots efficiently, and finally outline the backup and restore algorithms with attention to conflict resolution. Emphasize trade-offs between storage, performance, and correctness, and discuss how to handle edge cases like concurrent modifications.

Pro tip: Demonstrate awareness of real-world constraints by discussing how to handle large-scale snapshots (e.g., incremental backups) and how to ensure atomicity and consistency during restore, especially in a distributed environment.

1. Clarify Requirements and Constraints

Ask questions to understand the scope: What is the expected scale? Are snapshots full or incremental? How are filenames scoped (global vs per-user)? What consistency guarantees are needed?

2. Design Data Model

Propose a schema to store snapshots, such as a snapshot table with user ID, timestamp, and a mapping of filenames to content references. Consider using a versioned file system or a key-value store for efficiency.

3. Outline Backup Algorithm

Describe how to capture the current state: iterate over the user's files, record metadata and content (or references), and persist the snapshot atomically. Discuss incremental approaches if applicable.

4. Outline Restore Algorithm

Explain how to re-apply the snapshot: for each file in the snapshot, check if the filename is already taken by another user; if not, restore it. Handle conflicts by skipping or renaming, and ensure atomicity.

5. Discuss Trade-offs and Edge Cases

Analyze trade-offs: storage cost vs. speed, full vs. incremental backups, and conflict resolution strategies. Address edge cases like concurrent backups/restores, partial failures, and scalability.

Key Points to Mention

Data model for snapshots: use of immutable storage, content-addressable storage, or versioning to avoid duplication.
Conflict resolution: how to detect filename collisions (e.g., global namespace) and decide whether to skip, rename, or overwrite.
Atomicity and consistency: ensuring backup and restore operations are atomic, possibly using transactions or two-phase commit.
Scalability: handling large numbers of files and users, possibly with sharding or distributed storage.
Performance: optimizing backup/restore speed with incremental snapshots, compression, or lazy loading.
Security and access control: ensuring only authorized users can backup/restore, and data isolation between users.

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