Harvey's five-round Software Engineer, Agents interview was not a pure LeetCode loop. Its coding and system-design questions repeatedly moved into document processing, RAG, agents, and the constraints that appear when an AI system has to work in production.
Interview Experience | Agents / SWE | 🔥🔥🔥 | Harvey
2026 (July–August) · Software Engineer, Agents · online application · onsite.
The full process had five rounds. My impression was that Harvey does not use many isolated algorithm questions for this role. A problem might begin with ordinary data structures or pipeline code, but it would quickly acquire constraints from document retrieval, legal AI, or long-running agent systems.
This article describes one candidate's experience, not a guaranteed or official Harvey interview loop. The team, interviewers, questions, and follow-ups can change.
Round 1: Recruiter and hiring manager conversation
The first round focused on my resume and previous projects.
The questions included:
- Why Harvey, and why legal AI?
- Why do you want to work on agents?
- Have you shipped an LLM feature to production?
- Tell me about a project where you had substantial ownership.
- When model quality and latency could not both be prioritized, how did you make the trade-off?
We also discussed how I work. The team seemed to care about whether I could make progress independently when the problem and requirements were still ambiguous.
Round 2: Coding — document chunk merge
The interviewer provided many document chunks. Each chunk contained:
document_id / start / end / text
Chunks returned by different retrieval requests could overlap.
The first task was to merge overlapping chunks.
The second added source attribution. Identical text could come from different documents, so merging could not discard the association between the text and its sources.
The third follow-up made the data set too large to fit in memory. I had to explain how I would turn the solution into a streaming process.
The fourth made chunks arrive continuously and asked for the current merged result to remain available in real time.
The base problem was not unusually difficult, but the interviewer kept asking about complexity, edge cases, and how the code should be structured as each new constraint arrived.
Round 3: AI practical coding — RAG pipeline
This round used a simplified question-answering pipeline for legal documents. Some functions were already provided, and I had to complete the rest of the pipeline:
query -> retrieve -> rerank -> build context -> LLM
The first task was to implement top-k retrieval and context construction.
The second asked what to do when the assembled context exceeded the token limit.
The third introduced retrieved documents that contradicted one another. The answer needed to cite its sources instead of flattening the conflict into a single unsupported conclusion.
The fourth presented a debugging problem: retrieval recall was high, but final-answer accuracy had fallen. How would I find the cause?
The remaining discussion covered:
- chunk size
- reranking
- context-window use
- hallucination
- evaluation data sets
This felt much closer to practical AI engineering than to a traditional machine-learning theory interview.
Round 4: System design — a long-running research agent
The prompt was to design an agent for a user who uploads hundreds of legal documents and asks a complex question such as:
Find every passage related to a particular clause, compare conflicts across the documents, and produce a report with citations.
An agent run could take several minutes or even tens of minutes.
The discussion covered:
- document ingestion and indexing
- retrieval
- planning and tool calling
- context management
- persistence of intermediate state
- task queues
- retries and idempotency
- model timeouts
- partial results
- citation correctness
- what happens when the user changes the query during a run
One question kept returning throughout the design:
If the agent has completed 20 steps and step 21 fails, should the system restart the run or resume from a checkpoint?
We finished by discussing evaluation: how do you decide whether an entire agent run was actually correct, rather than merely complete?
Round 5: Project deep dive and behavioral questions
I was asked to choose the most complex project I had worked on and explain it from the architecture downward.
The follow-ups were detailed:
- What were you personally responsible for?
- What was the most important technical decision?
- Which decision would you change in hindsight?
- What was the largest production incident you encountered?
- How did you handle disagreement with a product manager or researcher?
- Have you deliberately cut a feature to ship faster?
Behavioral questions
- Why Harvey?
- Why agents instead of traditional SaaS?
- Tell me about a time you moved forward with incomplete information.
- Tell me about a disagreement with a strong engineer.
- Tell me about a solution you believed was technically correct but the product ultimately did not adopt.
Overall impression
Harvey appeared to place substantial weight on practical engineering and ownership.
The coding itself was not extreme, but new constraints kept arriving. The AI questions were not tests of whether I could recite Transformer internals. They kept returning to a more practical standard:
If this had to ship tomorrow, how would you build it?