← Harvey Interview Insights

Harvey·Software Engineer·Onsite - Multi Round·Senior

Senior
Jul 2026

Summary

Harvey SWE interview, 60-minute session split between a technical deep dive on a project you own and a short behavioral block tied to company values. The project portion is where they really dig in, so if you pick something you can only describe at a surface level, you're going to have a bad time.

Questions Asked (7)

Q1

Walk me through a technically complex project you personally owned. What made it hard, what trade-offs did you face, and what would you change looking back?

Technical Trade-offsSystem Design
Author's notes

This is the whole first 45 minutes, so the project selection matters way more than I expected.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Choose a project where you were the primary owner and can clearly articulate the technical complexity, your decision-making process, and measurable outcomes. Structure your answer to highlight the hardest technical challenges, the trade-offs you consciously made, and a reflective lesson that shows growth. Keep it concise but detailed enough to demonstrate depth.

Pro tip: Quantify the impact of your trade-offs (e.g., 'we reduced latency by 40% but increased cost by 15%') and be honest about what you'd change—interviewers value self-awareness over perfection.

1. Set the Context

Briefly describe the project, your role, and why it was technically complex (e.g., scale, constraints, novel technology).

2. Explain the Hard Parts

Detail the specific technical challenges you faced, such as performance bottlenecks, data consistency issues, or integration complexity.

3. Discuss Trade-offs

Articulate the key decisions you made, the alternatives considered, and the rationale behind your choices, including any compromises.

4. Share Outcomes and Metrics

Highlight the results of your work, using quantifiable metrics (e.g., latency reduction, cost savings, user growth) to demonstrate impact.

5. Reflect on Improvements

Describe what you would do differently now, showing learning and growth from the experience.

Key Points to Mention

  • Specific technical challenges (e.g., scaling, latency, data consistency)
  • Trade-offs made (e.g., consistency vs. availability, build vs. buy, performance vs. cost)
  • Your personal ownership and decision-making authority
  • Quantifiable outcomes and impact (e.g., performance improvements, cost savings)
  • Lessons learned and what you would change
  • Alignment with the company's tech stack or domain (e.g., AI, legal tech)

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

Q2

If the core constraint that drove your main technical decision had been removed, would you have made the same choice? Walk through the alternative.

Technical Trade-offsAdaptability & Ambiguity
Author's notes

This one tripped me up more than I'd like to admit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Pick a real technical decision you made, clearly state the core constraint that drove it, then hypothetically remove that constraint and reason through how your choice would change. Show that you understand the trade-offs and can adapt your thinking when assumptions shift.

Pro tip: Acknowledge that removing a constraint often reveals new constraints or trade-offs—demonstrating that you think in systems, not just isolated decisions. Also, tie the alternative back to business or user impact to show product sense.

1. Set the context

Briefly describe the technical decision and the core constraint that drove it (e.g., latency, budget, team size, legacy system).

2. Justify the original choice

Explain why the decision was optimal given the constraint, highlighting the trade-offs you accepted.

3. Remove the constraint

Hypothetically eliminate the constraint and identify what new options become viable.

4. Explore the alternative

Walk through the alternative solution you would have chosen, including its pros, cons, and any new constraints it introduces.

5. Reflect and connect

Summarize what this exercise reveals about your decision-making process and how you adapt to changing requirements.

Key Points to Mention

  • Clear identification of the core constraint and its impact on the decision
  • Trade-offs of the original choice (e.g., performance vs. maintainability, speed vs. scalability)
  • The alternative solution and why it would be better without the constraint
  • New challenges or trade-offs introduced by the alternative
  • How you would validate or test the alternative (e.g., prototyping, benchmarking)
  • Lessons learned about adaptability and decision-making under uncertainty

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

Q3

Tell me about a decision in that project you now believe was wrong. What did it cost, and how did you find out?

Root Cause AnalysisTechnical Trade-offs
Author's notes

Surprisingly the question I felt best about.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Choose a real technical decision from a past project that you now recognize as suboptimal, and walk through it honestly. Focus on the reasoning behind the decision, the measurable impact it had, and the specific signals or events that revealed it was wrong. Emphasize what you learned and how you changed your approach afterward.

Pro tip: Show that you proactively identified the mistake rather than having it forced upon you—this demonstrates ownership and a growth mindset. Quantify the cost in terms of time, money, or team morale to make your answer concrete and credible.

1. Set the context

Briefly describe the project, your role, and the decision you made, including the constraints and information available at the time.

2. Explain the decision and its rationale

Detail why you chose that approach—what trade-offs you considered and why it seemed like the best option then.

3. Describe the cost and consequences

Quantify the impact: time lost, performance issues, increased complexity, team frustration, or missed opportunities.

4. Explain how you discovered it was wrong

Describe the specific trigger—a bug, user feedback, metrics, or a post-mortem—that revealed the flaw.

5. Share the lesson and corrective action

Explain what you learned, how you fixed or mitigated the issue, and how you've applied that lesson since.

Key Points to Mention

  • The specific technical decision and why it seemed right at the time
  • The measurable cost (e.g., time, money, performance, team morale)
  • The signal or event that exposed the mistake
  • Your immediate corrective actions and their results
  • The long-term lesson and how you've changed your decision-making process
  • Demonstration of ownership and accountability without blaming others

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

Q4

Describe a time you took ownership of something clearly outside your assigned scope.

Adaptability & AmbiguityCross-functional Alignment
Author's notes

Standard behavioral, but they pushed on the 'we' vs 'I' distinction pretty firmly.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Choose a specific instance where you identified a gap or problem outside your assigned responsibilities and proactively addressed it. Use the STAR method to structure your answer, emphasizing your initiative, the impact, and what you learned. Highlight how you navigated ambiguity and collaborated with others to drive results.

Pro tip: Focus on the impact and learning, not just the action. Show that you understand the business context and can prioritize effectively, even when stepping outside your scope.

1. Set the Context

Briefly describe your role and the project or situation, making clear what was in your scope and what was not.

2. Identify the Gap

Explain how you noticed the issue or opportunity outside your scope and why you felt compelled to act.

3. Take Initiative

Describe the actions you took to address the problem, including any challenges you faced and how you overcame them.

4. Collaborate and Communicate

Highlight how you worked with others, kept stakeholders informed, and ensured alignment without overstepping boundaries.

5. Share the Outcome

Quantify the impact of your actions and reflect on what you learned from the experience.

Key Points to Mention

  • Demonstrated initiative and ownership beyond assigned tasks
  • Navigated ambiguity and made decisions with incomplete information
  • Collaborated cross-functionally to achieve a common goal
  • Communicated effectively with stakeholders to maintain alignment
  • Delivered measurable impact (e.g., improved efficiency, resolved a critical bug)
  • Learned valuable lessons about taking ownership and driving change

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

Q5

Tell me about a time you disagreed with a teammate or manager. How did it get resolved, and what would that person say about the situation if I asked them directly?

Conflict ResolutionStakeholder Management
Author's notes

The 'what would they say' twist is what makes this one interesting.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Choose a real disagreement where you had a substantive, work-related difference of opinion and the outcome was positive. Focus on how you sought to understand the other person's perspective, used data or user impact to make your case, and ultimately committed to the decision. Then answer the second part by honestly imagining what the other person would say, showing self-awareness and respect.

Pro tip: When answering what the other person would say, acknowledge any shortcomings in how you handled the disagreement (e.g., 'I could have raised it earlier') and emphasize that you maintained a good working relationship. This shows maturity and that you're not just telling a one-sided story.

1. Set the context

Briefly describe the project, your role, and the other person's role so the interviewer understands the stakes and dynamics.

2. Explain the disagreement

State the specific technical or product decision you disagreed on, and why you held your position. Avoid making the other person sound unreasonable.

3. Show how you resolved it

Describe the steps you took to understand their view, present your case with evidence, and reach a resolution—whether you persuaded them, they persuaded you, or you found a compromise.

4. Share the outcome and learning

Explain what happened as a result and what you learned about collaboration, communication, or decision-making.

5. Answer the perspective question

Imagine what the other person would say about your behavior and the resolution, showing empathy and self-awareness.

Key Points to Mention

  • Focus on a work-related disagreement, not a personal conflict.
  • Demonstrate active listening and empathy for the other person's perspective.
  • Use data, user impact, or engineering principles to support your argument.
  • Show that you can disagree and commit once a decision is made.
  • Highlight the positive outcome and maintained relationship.
  • When answering the perspective question, be honest about any missteps and show you've grown.

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

Q6

Tell me about a time you failed and what you concretely changed as a result.

Adaptability & AmbiguityRoot Cause Analysis
Author's notes

Pretty direct.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Choose a genuine failure with clear consequences, then focus on the concrete changes you made to your process or behavior. Emphasize the root cause you identified and how you verified the fix prevented recurrence.

Pro tip: Show that you turned the failure into a systematic improvement—not just a one-time fix—by describing a new habit, checklist, or automated safeguard you adopted. This demonstrates maturity and a growth mindset.

1. Set the context

Briefly describe the project, your role, and what you were trying to achieve. Keep it concise so you can spend most time on the failure and the change.

2. Own the failure

Clearly state what went wrong and your specific responsibility. Avoid blaming others or external factors; take accountability.

3. Analyze the root cause

Explain why it happened—go beyond the surface to identify the underlying process, technical, or communication gap. Show you used a structured approach like the 5 Whys.

4. Describe the concrete change

Detail the specific action you took to prevent recurrence. This could be a new code review practice, automated test, monitoring alert, or communication protocol.

5. Show the impact and learning

Explain how the change improved outcomes, and how you've applied this lesson to other areas. Quantify if possible.

Key Points to Mention

  • A genuine failure with real consequences, not a humblebrag
  • Personal accountability and ownership of the mistake
  • Root cause analysis using a structured method (e.g., 5 Whys, post-mortem)
  • A specific, concrete change to your process or behavior
  • Evidence that the change prevented similar failures (e.g., metrics, feedback)
  • How you've generalized the learning to other projects or teams

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

Q7

What is the hardest piece of feedback you have received, and what did you concretely do differently afterward?

Adaptability & AmbiguityConflict Resolution
Author's notes

Felt redundant with the failure question but they asked both.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Choose a genuine, specific piece of feedback that initially stung but led to real growth, ideally one that reveals a blind spot in how you work with others or handle ambiguity. Briefly set the context, then spend most of your answer on the concrete actions you took and the measurable impact, showing self-awareness and follow-through.

Pro tip: Pick feedback that is 'safe' but still meaningful—avoid anything that suggests a character flaw or ethical lapse, and avoid humble-brags. Show that you not only changed behavior but also sought feedback again to confirm the improvement.

1. Set the context briefly

Describe the situation and the feedback you received in 1-2 sentences, without over-explaining or blaming others. Make it clear why the feedback was hard to hear.

2. Acknowledge the emotional impact

Share your initial reaction honestly but briefly—e.g., you felt defensive or surprised—then pivot to how you processed it and decided to act.

3. Detail concrete actions

List 2-3 specific, tangible things you did differently afterward. These should be observable behaviors, not vague intentions.

4. Show measurable results

Quantify or qualify the outcome: improved team velocity, fewer bugs, positive feedback from peers, etc. This proves the change stuck.

5. Reflect on lasting impact

Explain how this experience changed your approach to feedback and working with others, and how it makes you a better engineer today.

Key Points to Mention

  • A specific piece of feedback that was hard to hear but ultimately valuable
  • Your initial emotional reaction and how you moved past it
  • Concrete, behavioral changes you made (e.g., writing design docs, asking clarifying questions, pair programming)
  • Measurable outcomes or positive feedback that resulted from the change
  • How you actively seek feedback now to continue improving
  • Relevance to the role: adaptability, collaboration, and handling ambiguity

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