Harvey Front End Interview Guide

Harvey frontend preparation should include building a working spreadsheet, reviewing unfamiliar React code, and designing applications that handle documents and recover from network failures. A candidate interviewing for a full-stack role in Bangalore, India, encountered all three, with two separate system design rounds and detailed project discussions.

Practice getting a usable interface running before adding complexity. For design discussions, follow a user action through local state, APIs, and recovery: selecting files, submitting a question, or editing data while offline each exposes a different set of failure cases.

Interview process

An August 2025 profile of Harvey engineering manager Annie Shin describes revising a frontend interview process that had relied on data structure and algorithm questions. It provides historical context for practical preparation, but does not establish a current round schedule.

The Bangalore full-stack candidate described a screening round followed by five rounds, in this order:

These stages describe that candidate's experience. Confirm the frontend/backend scope, coding environment, and documentation and AI permissions for your own interview.

Coding rounds

Spreadsheet implementation

The screening exercise required visible, working UI before extending the behavior across cells and formulas. Start with a grid that accepts edits and keeps each cell's input separate from its displayed result. Clarify what the multiple-cell follow-up requires before choosing the interaction or data model.

Formula evaluation can be practiced independently in Spreadsheet. Its class supports numeric cells and addition formulas that reference other cells, with acyclic inputs. An editable grid is a separate implementation task; ranges, other arithmetic operators, and cycle handling are outside this base exercise.

For selection behavior, the Selectable Cells exercise implements dragging a rectangle across a grid. It does not include editing or formulas. Treat it as a way to rehearse one possible grid interaction, then combine the pieces only after each works on its own.

Reviewing product code

During the code-review round, the candidate identified missing loading and error states, questioned useEffect usage, and suggested simplifying the code and lazily loading editor chunks. Practice explaining the consequence of a change: which failure becomes recoverable, which state stops drifting, or which code no longer blocks the initial view.

Check whether an effect synchronizes with an external system or merely recomputes a value that could be derived during rendering. Trace request races and cleanup, and distinguish an empty result from a failed request. For a large editor dependency, consider when loading should start and what users see while it loads or if loading fails.

Another UI coding variation

A different Harvey candidate encountered file traversal, breadcrumbs, and adding or removing folders. This was a separate interview task from the Bangalore spreadsheet screen.

The tree navigation in File Explorer provides a starting point, with expandable directories and sorted entries. Breadcrumb navigation and folder editing are follow-ups. Check what happens to the selected path when a parent folder is removed, and keep record identity separate from its displayed name.

System design rounds

The Bangalore loop included both a document-aware chat interface and an offline-first application. Rehearse them separately so that upload handling and local synchronization each receive enough attention.

Chat with documents and connected sources

The first design discussion covered UI components, state management, and APIs for a ChatGPT-style interface with document uploads and external data sources. Start with the conversation, composer, attachment list, and source selection, then trace submission through to a result or a recoverable error.

Conversation state and delivery behavior are covered in Chat App, whose base design is browser-based one-to-one messaging with optimistic sends, offline queuing, and reconnect catch-up. AI response streaming, file processing, and connected sources are extensions. Explain how users cancel a response, retry a failed request, and distinguish an uploaded file from one that is ready to query.

Harvey's connector-library article is useful context for source selection: a selected integration still needs authorization, and the server must enforce the user's access to retrieved data. Account for an expired connection or a source that becomes unavailable without losing the user's draft.

The candidate later identified large and bulk uploads as something they wished they had covered. Practice these cases explicitly:

• One large file: Show progress, support cancellation, and explain how an interrupted transfer resumes without restarting every byte.
• Many files: Limit concurrent transfers and show per-file outcomes so one failure does not obscure successful uploads.
• Processing after transfer: Keep upload completion separate from document processing, with clear status and recovery when processing fails.

The concurrency limit in Map Async Limit helps isolate the scheduling problem. Its results preserve input order, and a mapping failure rejects the returned promise. Per-file retries, cancellation, resumable transfers, and continued progress after failures need additional design.

Harvey's June 2026 Vault article describes direct uploads to storage coordinated through initialization and finalization APIs. Use it to examine where authorization and completion checks belong, and how the browser manages a batch without overwhelming the network.

Offline-first application

The bar-raiser round covered IndexedDB, conflict handling, a synchronization layer, and offline UX. Service workers were also discussed. Define which operations work offline before choosing storage or a synchronization strategy.

Keep structured application data and pending changes in IndexedDB. A service worker can cache the application shell and selected resources so the interface opens without a network connection; cached assets alone do not preserve unsent edits. Make pending, synchronized, and failed changes visible to the user.

Trace an edit through a lost connection, a page reload, and reconnection. The synchronization layer needs durable queued operations and safe retries. If the server's version has changed, explain whether the application can merge the edits or must ask the user to resolve a conflict. Test a concrete case where two devices change the same record.

Do not depend on a service worker remaining active indefinitely. Resume pending work when the application opens or reconnects, and treat background synchronization as an optional improvement. Storage limits and eviction also affect what the application can promise about offline availability.

Project and manager discussions

The project round involved deep technical follow-ups, while the manager round also covered motivation, expectations, and running projects with cross-team challenges. Prepare a project you can explain from the initial requirement through implementation and delivery.

Choose decisions where you considered alternatives and can explain their consequences. Describe your own contribution, a dependency on another team, and what you did when a deadline or assumption changed. A concrete account of a difficult rollout or reliability issue gives the interviewer room to ask meaningful follow-ups.

Recommended preparation strategy

1. Build the spreadsheet in stages: Get editing and visible results working, then add formulas and clarify the required cell interactions. Use the UI coding collection for further practice integrating state and user input.
2. Review code aloud: Walk through loading, success, empty, and failure states in a React component. Explain effects and cleanup using the fundamentals quiz collection, then propose a small change and a way to verify it.
3. Design the complete file journey: Follow a document from selection through upload, processing, and use in a conversation. Read Harvey's upload and connector articles below, and use the Front End System Design Playbook to organize the discussion.
4. Rehearse offline recovery: Take a stateful application from the system design collection, disconnect it during an edit, reload it, and work through reconciliation. Explain what survives locally and which actions need the server.
5. Prepare a project deep dive: Sketch the architecture of one project, list the decisions you owned, and rehearse follow-ups about failures, alternatives, and cross-team delivery. Connect your motivation for Harvey to the engineering work described in its articles.

Company blog posts

• Building a Faster, More Reliable Upload Experience in Vault: A June 2026 case study in direct uploads, concurrent pipelines, and recovery across large file batches.
• How We Built Harvey's Connector Library to Work Across External Tools: An October 2026 explanation of external integrations, permissions, and differences between providers.
• 5 Questions With Annie Shin: An August 2025 engineering-manager profile that discusses revising frontend interviews and working across teams.