Harvey AI Principal MLOps Engineer Interview Experience
Harvey AI · Principal · Machine Learning Engineer
I ended up pitching this quantum ML architecture where we were training models on quantum hardware to do something as stupidly simple as predict whether a number was even or odd, and Harvey’s panel got weirdly fascinated by the remote coding environment I built for physicists.
Interview process
I cold-applied because the role looked almost bizarrely close to the kind of MLOps work I was already doing, so I was curious how they were thinking about the same problem. The process was five rounds on separate days: recruiter, OA, live coding, a three-person architecture panel, and then a director chat, and I thought the job was represented very accurately the whole way through. The most useful signal was the panel, where they pushed hard on tradeoffs, latency, and how I communicate the same architecture to technical and non-technical people. The live coding round was also interesting because it mixed a real algorithmic problem with tokenization, embeddings, and vector database questions instead of keeping those separate. I did get an offer. They said it was not negotiable, and I passed.
Interview rounds · 5
- 1
Recruiter screen
BehavioralThe recruiter screen was really formulaic and felt like a box-checking pass to weed out volume, with the only notable thing being that they asked about compensation right away.
Q1. What is your expected compensation range?
Follow-up questions- Is that your full package, including base, benefits, and equity?
- 2
Online assessment
CodingData Structures & AlgorithmsThe OA was a standard one-hour timed coding screen with tab monitoring, so nothing especially memorable except that it was pretty locked down.
- 3
Technical round
CodingData Structures & AlgorithmsMachine LearningArtificial IntelligenceTechnicalThe live coding round was an AI-flavored LeetCode session where I shared my own editor and had to juggle a hard algorithmic problem plus open-ended ML systems questions at the same time.
Q1. Solve this coding problem around turning a string into a specific tokenized sequence and validating it in a fake vector-store workflow.
How they answeredThe prompt felt like a hard tree or graph problem wrapped in fake RAG plumbing. I had to start with a string, generate a very specific tokenized sequence, and make it pass a validator that pretended I was inserting embeddings into a vector store, but I could not use an embedding model and had to do it classically. While I was coding, he was also asking about tokenization, embeddings, and vector DB behavior, so I was balancing DS&A and systems thinking at once. I thought I handled it okay.
Follow-up questions- How would you think about tokenization here?
- What are embeddings in this setup if you cannot call a model?
- What matters about the vector database side?
- 4
Technical round
System DesignMachine LearningData Pipeline DesignCross-FunctionalTechnicalThe panel round was the best one by far: three people from the AI side dug into a past architecture I owned, collaborated in my whiteboard tool, and kept pushing deeper.
Q1. Walk us through a past AI-focused solution architecture you owned.
How they answeredI chose a recent architecture from a previous company. I explained how we were building and training models on hardware for very simple tasks like even-versus-odd prediction, because the real goal was testing hardware efficacy, not shipping some flashy AI product. That led to a lot of discussion about the stack, why it was so complicated, and how I was supporting researchers instead of optimizing one narrow app.
Follow-up questions- Why did you choose that architecture instead of something else?
- How well did it actually solve the original problem?
- What tradeoffs were you making?
Q2. How did you support researchers and engineers working in that environment day to day?
How they answeredThey got especially interested in the remote development environment piece. Our setup was unbelievably complicated, easy to break with updates, and easy to leave on stale versions, so I built shareable remote coding environments. That let multiple people collaborate on the same environment and data instead of everyone having their own snowflake machine. I spent a long time on that alone because they were weirdly fascinated by it.
Follow-up questions- What was painful about the local setup?
- How did you handle collaboration and reproducibility?
Q3. Okay, but this is too slow. How would you make it 10x faster?
How they answeredThis was the pressure point in that round. They kept taking parts of my design and saying, basically, this is too slow, now make it an order of magnitude faster, or several orders faster. So I had to reason through what I would actually change at the architecture level versus what I would just tune. It felt very different from a pure ML-research conversation, because they were clearly testing whether I think like a platform person once something has to survive production constraints.
Follow-up questions- What if it takes two minutes and I need 10 milliseconds?
- What changes are architectural versus incremental?
Q4. Now explain the same thing to a director, and then to a CEO.
How they answeredAfter getting deep into the technical weeds, they changed the audience on me. First I had to explain it as if they were a director who was not embedded in the engineering details, then as if I was presenting to the CEO. I kept the same architecture but changed the language, the depth, and the tradeoffs I highlighted. I thought that was a strong signal that they cared about translation and communication, not just whether I could build the thing.
Follow-up questions- What would you emphasize differently for each audience?
- 5
Final / onsite round
BehavioralCross-FunctionalThe last round with the director was pretty informal and felt more like a sell call where he restated the role, explained the org, and checked whether I was still interested.
Q1. After hearing more about the role and org structure, are you still excited about this position?
How they answeredHe mostly restated the position, the org structure, and what the team needed. I came away feeling like the company had represented the job accurately the whole way through. That round was much more about mutual fit and whether I was still interested than about testing me.
Tips from the candidate
I would go in expecting them to be a little vague in advance about what some of the rounds actually are, especially the live coding one, so do not assume technical means only straight LeetCode. I would brush up on graphs and trees, but also tokenization, embeddings, and vector database optimization from an infrastructure or platform angle, not just from a researcher angle. I would also pick one AI-heavy architecture from my past that I know cold, because they are going to ask why I chose each piece, what broke, how I would make it way faster, and then make me explain it to a director or CEO without hiding behind jargon.
Company culture
My read was that they knew pretty clearly what they wanted: not just a generic ML engineer, but somebody who could live on the platform and infrastructure side and still speak ML fluently. The process felt practical, and the actual role matched the job description way better than a lot of companies I have talked to. At the same time, some interviewers definitely seemed slammed and a little mentally elsewhere, like they had to rip themselves out of real work for an hour, while others were extremely engaged. They also stressed that product and feature ideas can bubble up from engineers, which is not always typical for MLOps roles, and they were upfront that org changes were coming.