Sharing a recent Ramp SWE interview experience from a candidate who went through the full process.

Initial recruiter screen was typical. He asked about motivations and interests and admin questions about the hiring process (sponsorship required, etc).

The first round was a technical coding interview. The question I got was the same as this one.

The next round was the onsite. The onsite included 4 interviews:

1. System design - The first half was a presentation on a project that you worked on yourself. I prepped a lot for the presentation, so I ended up talking for almost the entire first half and the interviewer didn’t have many follow-up questions. The second half was a relatively simple system design question about displaying the number of payments made on an admin dashboard used by a single executive. The interviewer then gradually expanded the requirements by increasing the frequency of updates and the number of users.

2. AI coding - The task was the same as described here. You’re given a repo. The interviewer is a software engineer acting as the PM, so they won’t answer technical implementation questions. The key is to have a back-and-forth with the interviewer to clarify the requirements and figure out the minimum product spec that solves the problem. From there, you use the coding agent to implement the solution.

3. Coding - I was asked this question.

4. Behavioral - Typical behavioral interview with "tell me about a time" questions. The interviewer seemed to value the ability to ship quickly and independently.

Sharing a recent Zip HQ SWE interview experience from a candidate who went through the full process.

Phone Interview Rounds

Coding: It was LeetCode-style coding, and I was asked this question.

Backend Practical:
The tasks were the same as described here. The focus was on applying good OOP principles and design patterns.

Virtual Onsite Rounds

Practical coding: The task was roughly to add a cache that tracks how many times an alert occurs and rejects the ticket once the count reaches a certain threshold. The follow-up was to support updating the alert level.

AI-assisted coding:
There were roughly three small tasks. You’re given an existing codebase, but there are so many files that it’s basically impossible to read through everything yourself, so most of the work involves having AI read and modify the code. The codebase was a simple system for managing employee expense reimbursements, with features such as monthly expenses and budget reports.

The first task involved incorrect monthly report data. For example, someone might submit a reimbursement in February for an expense that actually occurred in January. The task was to debug the issue. I had AI identify two bugs and fix them. The interviewer then asked whether I thought the AI’s fixes were correct. I reviewed them and thought they made sense.

The second task was to add a new feature to the reporting functionality. I essentially had AI implement the entire feature, and it passed the tests.

The third task asked what additional features you would add if you were moving the system to production. The idea was to brainstorm some features and then have AI implement them.

Overall, most of the round consisted of using AI to read and modify the codebase. At the end, the interviewer picked a few functions and asked whether I understood what the AI-generated code was doing and how I would improve or optimize it.

System design:
I was asked to design an order system. The main focus was on how to guarantee data consistency, as well as typical issues that need to be handled in a microservice architecture, such as timeouts and race conditions.

Deep dive:
This was a director-level interview. You should prepare at least three projects to discuss. The technical questions weren’t particularly deep; the main goal was to understand your role and contributions: the scale of the project, how long you worked on it, and the impact it had.

Overall impression: my impression was that the company is growing very quickly and hiring aggressively. The workload seems heavy and deadlines seem tight. It could be a good fit for younger engineers who want to grow quickly.

Sharing a recent Netflix SWE interview experience from a candidate who when through the full process.

R1 Phone Screen
Problem solving: Got this question. Only the third part was a little tricky; the other two parts were very easy.

HM: I don’t remember very clearly. I think they just asked about my experience and things like that. At the end, there was one BQ asking what my weaknesses were.

R2 VO
System Design: Design a job scheduler. I did very well in this round.

Problem solving: I was asked this question. I wasn’t very well prepared for this question, but I still managed to solve it in the end. At first I tried to solve it with a heap and got stuck for quite a while, so I didn’t have time to write tests or anything. The follow-up was multi-threading, and I verbally explained where I would add locks. The feedback I got at the end was that this round was a miss, though my multi-threading part was pretty good.

Partnership: This is basically a manager from another team that works with your team interviewing you. It was mainly BQ. I did just okay in this round as well. There were some questions I hadn’t prepared for and had to come up with answers on the spot, so I stumbled through them and didn’t answer very well.

There was a holiday break after the interviews. I followed up with HR afterward, and they told me I was moving on to the next round.

R3 VO
System Design: This was directly related to the team, designing one of their systems.
I thought I did okay, but when the feedback came back, I failed this round. The reason was that I didn’t complete the design within the allotted time. But I basically addressed all of the interviewer’s questions, and afterward I went through my proposal with AI and didn’t see any major problems with it either. The interviewer reminded me about the time at one point, so maybe I just didn’t manage my pacing well. The problem itself was very wide, and I probably spent too much time on areas that the interviewer didn’t consider that important.

HM: Met with the HM again, and this round was basically standard BQ. This time I was pretty satisfied with how I answered.

Overall, I feel like Netflix BQ puts a lot of emphasis on their culture, so read through it several times and avoid stepping on any landmines. Also, interview rounds with names like problem solving, [X] expertise, or partnership are essentially still coding, SD, or BQ, just with different names.

Yesterday I got the news that they were not moving forward, and I had a call with the recruiter to ask for feedback. I’m still pretty disappointed after going through all of this and making it to the final round without getting an offer.

Sharing a recent Valon Mortgage SWE phone screen interview experience from a candidate who went through the process.

Valon Mortgage is a Series C mortgage company based in NYC. The interview felt very OOP-focused.

For the technical phone screen, the coding question was same as the one here. If you haven’t prepared for this type of question beforehand, the time can feel pretty tight. During the interview, you’re not allowed to use AI. You have to share your screen, and you can only use Google search. You don’t really need to worry about algorithmic complexity. The main thing is to get the code working and write comprehensive test cases. Overall, there’s a lot of code to write. I’ve been relying on AI a lot in my day-to-day work, and I hadn’t interviewed in a long time or done much preparation, so I didn’t even manage to finish the core implementation.

Sharing a recent Attentive SWE interview experience from a candidate who went through the interview process.

HR Call

The recruiter asked questions including:

• How much do you know about Attentive?
• Are you actively interviewing right now? Do you have any offer deadlines?
• Do you need sponsorship?
• What compensation range are you targeting?
• Tell me about yourself.
• Are you able to talk about a feature or product that you worked on end-to-end, or a zero-to-one product?
• What is your primary programming language?
• Why did you leave your previous company? What have you been doing since leaving? Why are you looking for a job now?

Then the recruiter explained the interview process:

Round 1 — 2 hours

• 1-hour coding
• 1-hour system design

The coding interview would be LeetCode-style. The system design interview would be conducted using Lucid, a virtual whiteboard.

If Round 1 went well, I would move on to Round 2.

Round 2 — Virtual Onsite

• 1-hour coding
• 1-hour system design
• 45-minute Hiring Manager interview

The HM round would focus heavily on behavioral questions, such as how you collaborate, how you deal with ambiguity, and things like that.

Round 1 — System Design

The interviewer first introduced themselves, and then I introduced my background.

The question was same as the first one from this list. After clarifying the requirements, I walked through my design, entities, database choice, etc. The interviewer then asked how I would build observability for this system and what measures I would take to make sure everything is operating as expected. Then we moved on to my questions for the interviewer. Overall, I felt pretty good about this round.

Round 1 — Coding

This was on the same day as the system design interview, so the two interviews were back-to-back for two hours.

We first introduced ourselves. Then the interviewer asked this question. After I finished the implementation, we ran some tests and they passed. Then we moved on to my questions for the interviewer. Overall, I felt pretty good about this round as well.

Level Change

I moved on to Round 2, the virtual onsite. However, the day before the interview, I received a call from the recruiter. He told me that the position I had originally interviewed for had just been filled. However, because I had performed extremely well in the first round, the feedback was that I was “on the cusp of a SWE II–Senior”. There also happened to be a team looking for a Senior Engineer, so they wanted to evaluate me for this potential Senior role instead.

Round 2 — Coding

The question was same as this one. After finishing the implementation, I started writing test cases. I wrote several, and he added a duplicate-timestamp case where multiple logs had the same timestamp.

All the tests passed. Then we discussed time and space complexity. There were also some distributed-systems-related follow-up questions, and then we moved on to my questions for the interviewer.

Round 2 — System Design

I first introduced myself, and the interviewer asked me some questions about my previous projects.

Then we started the system design interview. The problem was designing a metrics system, but unfortunately, the interviewer explained things in a somewhat disorganized and inconsistent way, which made it difficult for me to understand the requirements and made the interview challenging. Every time I described one component, he would change a requirement or introduce a new requirement. He talked a lot throughout the interview, and some of the things he said seemed contradictory, so I wasn’t sure exactly what he wanted. I had to keep clarifying the requirements, and I tried my best to explain everything I knew.

My overall design was complete, and I also felt that I handled the troubleshooting portion well. Looking back, though, the interviewer did most of the talking, and I didn’t have many opportunities to jump in and drive the conversation. Immediately after the interview, I actually felt pretty good about it. I even thought my system design round had gone better than my coding round. But based on the final result, I think the most likely issue was communication.

Result Call

They told me they had decided not to move forward. The feedback was that my coding was very good, but system design was the weaker area. They said I definitely met the SWE II bar, but I did not meet the Senior-level bar.

I asked whether they could provide more detailed feedback. I felt that I had performed well and wanted to understand what the interviewer thought I hadn’t done well enough and what I could improve. The recruiter said that, for Senior-level candidates, they expected the candidate to drive more of the technical discussion and think through some of the smaller details they were looking for that I had missed.

I felt pretty disappointed. The position was a really good fit for me, and I genuinely tried my best. After getting the result, I kept wondering whether things might have turned out differently if I had scheduled the interviews a little earlier, or if my second system design round had been with the interviewer from my first round, or simply with a different interviewer. But I still have to move on. Maybe it just wasn’t meant to be. I’m sharing this now in the hope that it helps others. Good luck to everyone with the job search.

Sharing a recent Luma AI Product Engineer interview experience from a candidate who went through the whole process.

The process is very fast but also a bit chaotic: recruiter, take-home assignment, onsite, offer. If the recruiter doesn’t respond about the next step, you can proactively follow up. TC is very high. They’re mainly trying to compete within the OAI/Anthropic range, but most of the comp is Series C paper money, and they’re still some distance away from an IPO.

Recruiter call

• motivation
• why luma
• experience with AI development tools and workflows
• what specific interests in dev

OA assignment

• 8–12 hours, choose one out of five questions, covering frontend, backend, and infra.
• The recruiter email will include a curl script to directly download the question README and submission script.
• Chat logs from Cursor, Codex, and Claude Code will all be uploaded.
• I think they’re testing agentic best practices, 0-to-1 product development scoping, and UX/dev experience design.

Question topics:

• build scalable TTS system
• managing prompt & model behavior in prod
• where and when to eat with friends
• collaborative document editing with people and agents
• reverse engineer undocumented APIs from another app and rebuild app to improve UX

Onsite

The office is in Redwood City and is already getting a bit full. According to the recruiter, the company has already started looking for expansion space in SF.

Take-home product review

This round mainly discusses the tradeoffs, scaling limitations, customer needs, and UI/UX of the take-home assignment. They ask about things in a lot of detail. It seems like there’s an AI judge on the backend that reviews the assignment and identifies all the weaknesses for the interviewer to drill into. You can think of the work you did in one day as a prototype, and then they’ll add other customer requirements and discuss integration, estimation, and roadmap.

Leadership

This round is with CTO Scott. He’s very smart and knows about everything. He also talks very fast, so be mentally prepared. Mainly discusses potential projects, interests, and team.

System design

The recruiter said during the prep call that the question would be something like rideshare or payment processor. I got build Uber, which you could also say is one of the most complex SD questions. The interviewer used to be a backend systems engineer at a similar big tech company working on this kind of thing, so you can’t BS your way past him. If you identify tradeoffs, you can discuss them proactively. All the solutions online have a lot of shortcomings.

Topics:

• requirements and scope clarification
• entities, database design, and API endpoints
• system diagram
• idempotent tx, atomic writes, double charge
• database design, peak throughput, scaling read/writes, sharding
• distributed locks
• geospatial search
• tx logging, error/crash recovery, replay
• audit trail and reconciliation
• workflow tooling and durable execution
• cancellation handling
• client/server state updates SSE vs. Websocket vs. push notification
• system scaling and weak points

Overall, my impression is that the people there are very smart internally, but PMF is still a bit lacking. Research has already started looking into projects like robotics and real-world models, while the product side is still working on gen AI video/image tools that they’re preparing to sell to large media and advertising customers.

Sharing a recent Axon interview experience from a candidate who went through the process from the initial HR conversation all the way through the Virtual Onsite.

HR Screen

The recruiter explained that this is a relatively new team focused primarily on voice processing and transformation. The team was formed following an acquisition and currently has around 30 people, but it is expanding rapidly. The environment sounded similar to a startup. The recruiter also hinted that work-life balance might not be great, with fairly frequent on-call responsibilities.

The compensation package was described as roughly comparable to an L5 position at a mid-sized tech company.

Phone Screen

This was the question I got. There isn’t an exact LeetCode equivalent.

Hiring Manager Round

This was purely a behavioral interview. We mainly discussed what the team does and the type of engineers they were looking for. They wanted people who could contribute immediately. There is a significant amount of on-call work, and the expectation seemed to be that a new hire should be capable of deploying production code almost immediately after joining. My background matched what they were looking for, so I moved on to the next stage.

Virtual Onsite

There were two rounds.

Round 1: System Design

The question was designing a real-time voice processing system. This is similar to the "design YouTube/voice" type of question. They jump straight into asking you to design a voice system. Roughly speaking: clients will make voice calls into the system, and the system must recognize, process, and convert the messages so that the platform can extract the important information and receive notifications.

The main idea is that it requires very low real-time latency — use the WebRTC protocol, and know how to handle audio streaming. Refer to the concept of designing YouTube for storage (e.g., storing in S3) and pairing it with a CDN. The difference is that since it's real-time voice, you need some knowledge of speech-to-text / cloud upload concepts. Roughly: use AWS Transcribe to convert speech to text, chained through an async worker. After processing completes, extract the key points and trigger a Notification service to push them to the platform.

Round 2: Coding

I was asked this question. Axon’s interview questions were quite practical. None of them were direct copies of LeetCode problems; instead, they required applying standard algorithmic concepts to real-world scenarios.

Sharing a recent Mintlify SWE interview experience from a candidate who went through the entire process.

Interview Process

• Behavioral screen — Talked with their CTO about my work experience, salary expectations, and some behavioral questions.
• Technical screen 1
  • Debugging CSS and APIs
  • Some very basic web development trivia
• Onsite coding
  • Build a component based on a screenshot. It was somewhat like a shadcn-style card with badges/chips.
  • AI was allowed. Took around 20–30 minutes.
• Onsite systems design — Collaborative Editor
  • Frontend: Tokenization and change-management techniques
  • Backend: Streaming updates, session data journaling, and Git integration
  • Database: Comparing blob storage with streaming data

The recruiter gave me the systems design question ahead of time, but they went into a lot of detail during the actual interview.

Onsite Experience

The coordinator booked the wrong flight for me, and I ended up paying the change fee myself. My Uber rides to and from the airport weren’t reimbursed either.

The hotel they booked was a crappy $120/night place in Tenderloin. It was noisy at night, and overall I got the impression that the company was being excessively cheap with the onsite arrangements.

Both co-founders were pretty friendly, though, and the product seemed good. I might take another look at the company in the future if they have more resources.

Offer

The offer was around $200K + options for a senior-level position. I didn’t accept it. I basically treated the whole experience as interview practice plus a partially self-funded trip…

Sharing a recent Decagon SWE interview experience from a candidate who went through the entire process.

After the initial hiring call with the recruiter, there were two phone screen interviews: practical coding and system design.

For the practical coding round, I got asked this question.

For the system design screen, I was asked to design a delayed task scheduler.

Onsite:

Culture screen: asked pretty generic questions like tell me about a project, tell me about a project that went wrong, how do you use AI.

AI coding round: same question as this -> https://www.interviewdb.io/question/decagon?page=1&name=router

Algo coding: got this question.

Past project deep dive: I felt like I had prepared at too high a level. The interviewer seemed more interested in the detailed design of a specific project, so I ended up drawing the system architecture for one of my projects on the spot.

I was rejected immediately afterward.

Sharing two questions from a recent Google SWE Intern OA.

Question 1:
Given an integer array (a vector of ints), where the index represents a student ID and the corresponding value represents that student’s exam score.

The grading criteria are:

• < 50%: Failed
• 50% ≤ score ≤ 80%: Pass
• &gt; 80%: Pass with distinction

Return an array containing 3 elements, representing, in order:

1. The number of students who failed
2. The number of students who passed
3. The number of students who passed with distinction

Question 2:
You want to read all the chapters of a book.

You are given an array time, where the index represents a day and the corresponding value represents the amount of time you have available to read on that day.

You are also given another array book, where the index represents a chapter and the corresponding value represents the amount of time required to finish that chapter.

If you have enough time on a given day, you may read more than one chapter. However, each chapter must be completed in one sitting: a chapter cannot be split across multiple days.

Given these constraints, return the number of days required to finish the entire book. If it is not possible to finish the book with the available time, return an appropriate status indicating that it cannot be completed.

Sharing a question encountered in a recent CoderPad OA for Figma’s SWE Intern position.

The task involves building a document revision history system for a document editor. You’re given several operations to support, along with a set of example API signatures. However, you don’t have to strictly follow the suggested APIs. You’re free to structure your implementation differently if an alternative design works better. Full details of the task can be found here.

Sharing a recent full-loop interview experience at Verkada shared by a candidate who went through the whole interview process.

Phone Screen

Pretty standard LeetCode-style round. Was asked to solve this problem: https://www.interviewdb.io/question/verkada?page=1&name=camera-intensity

Onsite

Drove to the San Mateo office. Only afterward did I realize they reimburse for Uber.

Round 1: Coding

Started with implementing an LRU cache and got it working. Then they asked me to implement LFU as a follow-up. I got most of it done but ran out of time near the end.

Lunch

Had lunch with the hiring manager and three other senior-looking guys.

Round 2: Pair Programming

This was done in a local IDE. The development environment was already set up with the tools you need, such as Docker, along with a basic project scaffold to get started. The task was to build a simple API server and implement three API calls. The requirements and starter code are the same as the ones described here.

Round 3: System Design

Whiteboard round. There were two design questions, and both of them are available here: https://www.interviewdb.io/question/verkada?type=design&page=1

Round 4: Behavioral

Behavioral interview with the hiring manager. Most of the questions were pretty normal. One question that caught me off guard was something along the lines of: “What do you think about your previous company?” I definitely had not prepared for that one. I tried to be diplomatic: mostly saying positive things while lightly mentioning a few areas that could have been better.

Final: HR Check-in

Finished with a short HR check-in.

Sharing the coding question from a recent Optiver OA for the Software Engineer Intern position.

The assessment had one coding question, with C++, Java, and Python available as language options.

Here’s the question:
Simulate a firmware controller that prevents a multicore processor from overheating. Each core has a configured workload, all cores share passive cooling, and each running core can receive a dedicated active-cooling channel.

Implement a pure function that processes the controller operations in order:

simulateOverheatController(
    passiveCapacity,
    activeCapacityPerCore,
    coreIds,
    operations
) -> list of Tick results

Each operation is one of:

["set", timestamp, coreId, loadWatts]
["tick", timestamp]

Return one array for every tick. Each array contains strings in the form "coreId=status", sorted by coreId, for exactly the cores whose status changed at that tick. A status is idle for a running core without active cooling, cooling for a running core with active cooling selected for the next interval, or shutdown.

Initial State and Pending Loads

Every core starts at 20.0 degrees Celsius, running with load 0, active cooling off, and status idle.

A set operation records a pending load but performs no temperature calculation. If several pending loads target the same core before the next tick, keep only the last one.

For a running core, the pending load takes effect after temperature advancement and shutdown checks at the next tick. For a shutdown core, set is a one-time restart request: at that next tick, restart with the pending load only when its temperature is strictly below 50.0; otherwise discard the request and leave the core shut down with load 0.

The first tick establishes the time origin and advances temperatures by zero seconds. Every later tick advances from the previous tick timestamp. A set timestamp determines operation order but does not split the thermal interval.

Thermal Advancement

During an interval, use the loads and active-cooling choices established by the previous tick.

For every core, passive demand is load + 2 watts. If k cores had active cooling during the interval, effective passive capacity is:

passiveCapacity * (1 - vibrationPenalty(k) / 100)

where:

vibrationPenalty(0) = 0
vibrationPenalty(k) = sum(10 / Fib[i] for i = 1..k)
Fib = [1, 2, 3, 5, 8, 13, ...]

If total demand is at most effective capacity, each core receives its full demand. Otherwise, a core receives the same proportional fraction of its demand:

passiveForCore = effectiveCapacity * coreDemand / totalDemand

A core selected for active cooling receives an additional activeCapacityPerCore watts. Its net heat is:

load - passiveForCore - activeCoolingForCore

Temperature changes by 0.02 degrees Celsius per second for each watt of net heat and never falls below 20.0. A shutdown core has load 0 and no active cooling, but it still participates in passive-demand allocation through its 2-watt demand.

After advancement, shut down every core whose temperature is at least 80.0, clear its load to 0, and discard any pending ordinary load for that now-shutdown core. Then process the pending load and restart rules described above.

Choosing Active Cooling

Recompute active cooling from scratch after pending loads are processed. Shutdown cores are never selected.

Find the minimal stable selected set with this monotone procedure:

1. Initially select every running core whose current temperature is above 60.0 .
2. For the current selected-set size k , recompute the effective passive capacity and passive allocation using current loads.
3. For each running core not yet selected, compute its temperature rate without active cooling. If that rate is strictly greater than 0.5 degrees Celsius per second, select it.
4. Repeat steps 2 and 3 until no core is added.

This captures the feedback in which each new active channel increases vibration, reduces passive cooling for everyone, and can force additional channels on. The selected set applies until the next tick.

Status Reporting

Compare each post-tick status with its status after the previous tick, using the initial idle status before the first one. Report each changed core once. Temperature or load changes alone are not status changes.

Constraints & Assumptions

• 1 <= len(coreIds) < 1024 ; identifiers are unique nonempty strings.
• passiveCapacity > 0 and activeCapacityPerCore > 0 .
• 1 < len(operations) < 1024 .
• Operation timestamps are globally strictly increasing positive values with millisecond precision.
• 0 <= loadWatts <= 32768 , with at most three decimal places.
• Test values stay safely away from the exact 50.0 , 60.0 , 80.0 , and 0.5 comparisons except when the stated strictness is intentionally tested.
• Return every floating-point-independent status transition exactly; no temperature values are returned.

Sharing a recent full-loop Datadog interview experience from a candidate who went through the process.

Initial Phone Screen – Coding

This was a coding round. I got a question involving string processing and hash maps, and it was one of the questions from this Datadog interview question list.

Onsite

Code Review Round

I was given a PR for an issue where some python app was crashing under heavy load. The PR changed the existing synchronous processor (one request at a time) to a batched processor (40 requests at a time). The repo still had the synchronous processor for reference. However, if the batched processor failed to create, the new code returned None, instead of falling back to the synchronous processor. I pointed this out.

Also - the PR description mentioned that the new batched processor could handle 6k/s/instance, while the peak load (as per the README.md) was 8k/s/instance.

Important note: PR is huge, PR description, ReadMe files are also huge. Expectation is to use AI for everything. They judge you on how well you use AI. If you try to do it manually, you wont be able to manage time. There are tons of bugs in PR, you need to prioritize it and identify which ones are critical using AI. Also dont forget to validate AI suggestions.

Coding + System Design Round

For the coding and system design rounds, the questions were again from the same Datadog interview question list.

Sharing a recent interview experience for Harvey’s AI-assisted coding round. It seems to be a new round added to their onsite loop, and there isn’t much information about it yet, so sharing some info about it here.

The interviewer provided a coding task and explicitly asked me to use AI as part of the process. During the interview, they introduced additional test cases and requirements, and I was expected to use AI to update the implementation and then validate that the changes were actually correct.

The initial coding part was fairly straightforward (I would say it's about LC medium level). The second and third parts were more interesting and pushed the problem beyond a typical coding interview. It became less about coding and more about systems reasoning.

I was asked to discuss multiple possible approaches, compare their design trade-offs, and then implement one of the solutions. There was also discussion around things like atomicity and how the implementation would behave under different edge cases.

The coding task and follow-up parts were the same as what’s described here: https://www.interviewdb.io/question/harvey?page=1&name=ai-coding

Overall, I don’t think the coding difficulty itself was particularly high. The more important parts seemed to be clarifying requirements before jumping into implementation, identifying edge cases (including ones that weren’t explicitly given), using AI effectively without blindly trusting its output, and discussing alternative designs and their trade-offs.

Sharing some info about the Anthropic Fellow Program’s second OA, which is a debugging exercise.

The task involves debugging a provided implementation of the Extremely Randomized Trees algorithm. The implementation is mostly functional, but it contains several bugs that can cause it to crash in some cases and produce poor accuracy in others.

For the assessment, you’re allowed to consult the NumPy and Python documentation, but you cannot use web search or any AI assistance. You can use pretty much any standard debugging approach, including print statements, the REPL, and terminal-based debuggers. CodeSignal’s graphical debugger is available, but they don’t recommend using it since it apparently doesn’t work very well.

You can find the debugging task description and the buggy source code here.

Would also love to hear more data points from people who have taken this OA, particularly how well you need to perform to advance to the next round. If you’ve taken it and are comfortable sharing your experience or score/results, that would be really helpful.

Sharing a recent interview experience with Harvey AI.

Technical Screen

It was a coding question with 2 parts, same as this one:
https://www.interviewdb.io/question/harvey?page=1&name=file-organization

Was able to finish it in around 45 minutes, and then spent the remaining time chatting with the interviewer.

Onsite

There were 3 rounds:

1. System Design

Design a system to support one of Harvey’s core product features. It was similar to this question:
https://www.interviewdb.io/question/harvey?page=1&name=legal-agent

The main focus was LLM + RAG. Don't know much about this area so probably failed at this round.

2. Project Deep Dive + Behavioral

The first ~45 minutes were a project deep dive. You prepare one project you’ve worked on and walk through it in detail. The last ~15 minutes were behavioral questions related to Harvey’s core values.

3. Coding

There were 3 parts, same as described here: https://www.interviewdb.io/question/harvey?page=1&name=formula

Sharing a recent interview experience for a Platform Engineer position at Cartesia.

Intro Call

The process started with a 30-minute intro call with HR.

They asked a few standard questions:

• What do you know about Cartesia?
• Why do you want to join Cartesia?
• If you had multiple offers, what would be the top 3 factors you’d use to decide between them?

There were also two basic DSA/CS questions:

1. Given a tree with branching factor b, what is the maximum number of nodes in a tree of height H?
2. In a sorted array, what is the time complexity of accessing the element at index 6?

Technical Screen

I was asked one of the coding questions from this list.

Virtual Onsite

One of the virtual onsite rounds is called Backend Practical. For this round, you use your own coding environment (i.e. your preferred IDE and any AI coding agent you normally use), so it’s worth making sure everything is set up and ready beforehand. I was asked to build an API in this round. The details was the same as described here: https://www.interviewdb.io/question/cartesia?page=1&name=backend-practical

After analyzing hundreds of recent Affirm interview experiences, here’s what we found about the types of questions they’ve asked in interviews.

Affirm’s technical interview questions are a bit different from the typical LeetCode style. Their coding interviews focus on real-world scenarios and test practical coding skills.

The practical coding interview is typically split into several parts. In the first part, you’ll be presented with some existing code and asked to find and fix bugs. In the second part, you’ll be asked to extend the functionality of the existing code, usually by adding a new method that does something new.

If you’re looking for resources to practice these types of questions, you can check out these questions that have been asked in their practical coding interviews before:

1. https://www.interviewdb.io/question/affirm?page=1&name=dispute-status
2. https://www.interviewdb.io/question/affirm?page=1&name=fraud
3. https://www.interviewdb.io/question/affirm?page=1&name=loan-company

You can also find more coding questions, as well as system design questions (you’ll get a system design round if you interview for a senior+ role), from past Affirm interviews here. Based on past interview experiences, Affirm often repeat some of the questions, so there’s a chance you could see the exact same ones or something very similar in your own interview.

Sharing a recent Nuro interview experience for a Software Engineer (AI Platform) position.

The screening round was 1.5 hours total, consisting of two 45-minute coding interviews, and covered two types of coding:

• Coding (Algorithms) — pretty standard LeetCode-style problems focused on data structures and algorithms.
• Coding (Systems) — more focused on lower-level/system concepts such as concurrency, multithreading, locks, mutexes, memory management, etc.

The question I got for the algorithm coding round was the same as this one: https://www.interviewdb.io/question/nuro?page=1&name=hidden-hazards

The problem I got for the system coding round was essentially this one: https://www.interviewdb.io/question/nuro?page=2&name=video-player. After the interview, I looked into it a bit more and realized that a good approach would be something similar to a publish-subscribe / producer-consumer model.

Overall, I’d recommend preparing not only regular LeetCode questions for Nuro, but also concurrency-related topics like thread synchronization, producer-consumer patterns, condition variables and mutexes.