← HarveyAI Interview Insights

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

Senior
Apr 2026

Summary

System design round at HarveyAI for a software engineer role. The interviewer pushed way deeper than I expected on two specific areas, file uploads and access control, to the point where it felt less like a breadth check and more like a technical interrogation.

Questions Asked (2)

Q1

Design the file upload flow for a cloud storage system like Google Drive, covering chunking, resumable uploads, deduplication, and how you separate metadata storage from blob storage while keeping them consistent.

System DesignTechnical Trade-offsData Modeling
Author's notes

This is where the interview got uncomfortable.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (file sizes, concurrency, consistency needs) and then walk through the upload flow from client to storage, covering chunking, resumable uploads, deduplication, and the separation of metadata and blob storage. Emphasize trade-offs and how you ensure consistency between metadata and blobs, such as using a write-ahead log or two-phase commit.

Pro tip: Proactively discuss failure scenarios and how your design handles them (e.g., partial uploads, metadata-blob inconsistency) to demonstrate production maturity. Also, mention how deduplication interacts with security (e.g., proof of ownership) to show depth.

1. Clarify Requirements and Constraints

Ask about expected file sizes, upload frequency, consistency requirements, and whether deduplication should be global or per-user. This sets the stage for design decisions.

2. Design the Upload Protocol

Describe chunking strategy (e.g., fixed or variable size), resumable uploads using unique upload IDs and chunk checksums, and client-side retry logic.

3. Implement Deduplication

Explain how to compute chunk/file hashes, check for existing blobs, and handle race conditions. Discuss trade-offs between chunk-level and file-level dedup.

4. Separate Metadata and Blob Storage

Propose a metadata store (e.g., SQL/NoSQL) for file info, permissions, and chunk locations, and a blob store (e.g., object storage) for actual data. Highlight scalability and cost benefits.

5. Ensure Consistency and Handle Failures

Describe mechanisms like write-ahead logging, two-phase commit, or eventual consistency with reconciliation to keep metadata and blobs in sync. Cover garbage collection for orphaned blobs.

Key Points to Mention

  • Chunking: fixed vs. variable size, chunk size trade-offs (e.g., 4MB), and parallel uploads.
  • Resumable uploads: upload session IDs, chunk checksums, and client-side persistence of progress.
  • Deduplication: content-addressable storage, hash collisions, and security implications (proof of ownership).
  • Metadata vs. blob storage: using a database for metadata and object storage for blobs, with references via unique IDs.
  • Consistency: write-ahead log, two-phase commit, or eventual consistency with background reconciliation.
  • Failure handling: retries, idempotency, garbage collection of orphaned blobs, and monitoring.

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

Q2

How would you design the access control system for a cloud storage product, including folder permission inheritance, link-based sharing with different permission levels, and making ACL checks fast at read time?

System DesignTechnical Trade-offsAPI & Integrations
Author's notes

ACL inheritance is one of those things that sounds clean until you try to explain it under pressure.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a data model that separates resources, permissions, and inheritance. Explain how you'd compute effective permissions at read time using caching and denormalization, and discuss trade-offs between simplicity, consistency, and performance.

Pro tip: Emphasize that permission checks should be fast and predictable: precompute and cache effective permissions per user-resource pair, and use a bitmask or enum for permission levels to enable quick bitwise checks. Also mention the importance of auditing and revocation for link-based sharing.

1. Clarify requirements and scale

Ask about expected number of users, folders, files, and sharing patterns. Clarify permission levels (e.g., read, write, share) and whether inheritance can be overridden.

2. Design data model

Propose tables for resources (folders/files), permissions (user/group, resource, permission level), and links (token, resource, permission, expiry). Include parent-child relationships for inheritance.

3. Define permission inheritance and resolution

Explain how permissions propagate down the folder tree, how overrides work, and how to resolve effective permissions for a user on a resource (e.g., walk up the tree or use precomputed paths).

4. Optimize read-time ACL checks

Describe caching strategies (e.g., Redis) for effective permissions, denormalization, and using bitmasks for fast checks. Discuss cache invalidation on permission changes.

5. Handle link-based sharing and trade-offs

Explain how to generate and validate share links with different permission levels, including expiry and revocation. Discuss trade-offs between consistency, latency, and complexity.

Key Points to Mention

  • Use of bitmasks or enums for permission levels to enable fast bitwise operations.
  • Precomputation and caching of effective permissions per user-resource pair to avoid tree traversal at read time.
  • Handling of group permissions and nested groups for scalability.
  • Link-based sharing: token generation, permission scoping, expiry, and revocation mechanisms.
  • Cache invalidation strategies when permissions change (e.g., write-through, event-based).
  • Trade-offs between strong consistency and eventual consistency in permission propagation.

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