Scale AI New Grad Software Engineer Interview Experience
Scale AI · Entry level · Software Engineer
What stood out most was the interviewer straight up told me the culture at Scale is “pretty like 996,” which you usually never hear that openly. And the rounds were super speed focused, like two interval-style problems in one hour.
Interview process
I cold applied early, and the first thing they sent me was a HackerRank, not a recruiter screen. After that, there was a gap of a few weeks, then I had a 60-minute technical screen followed by a back-to-back system design and debugging round that felt like the onsite.
The whole process felt much more practical than a standard LeetCode-only interview, but it was still very time-intensive, especially in the coding round. As the process progressed, it became increasingly AI-specific, especially in the design and debugging interviews. I got rejected after that onsite-style round, so I did not make it to what I think would have been later culture-fit or vibe-coding interviews.
Interview rounds · 3
- 1
Online assessment
CodingData Structures & AlgorithmsThe first thing they sent me was a 50-minute HackerRank, and it already felt more practical than a normal LeetCode OA. It was still basically an intervals problem, but wrapped in a more real-world API-style setup where I had to understand how to pull the data first and then code fast.
Q1. If you have multiple parties, how would you find the dead zones between their time intervals?
How they answeredI treated it like an intervals problem around party schedules and had to find the dead zones between them. The twist was that they did not just hand me a normal array. I had to use the method they gave and understand how to get the data first, then write the actual logic. The algorithm itself was not too bad. I finished in around 20 to 25 minutes, so the bigger thing was being comfortable reading the setup and coding it quickly.
Follow-up questions- Can you work from the provided method/API-style input instead of a plain array?
- 2
Phone screen
CodingData Structures & AlgorithmsTechnicalThe technical screen was 60 minutes with an engineer, and the main pressure was speed, not some insanely hard algorithm. It felt very Stripe or DoorDash-ish to me: practical data formats, interval-heavy questions, and you had to drive the round yourself while the interviewer mostly helped if you needed clarification.
Q1. Given query time intervals, how would you find the free time where queries can be ingested?
How they answeredThe first problem was about query ingestion windows. I had to find the free time where queries could be inserted, then sort things in a way that minimized how long the LLM would be processing them. It was again interval-based, but with a more realistic setup where I was working from data coming through a method instead of a raw array. The hard part was not figuring out the idea. It was just typing everything out cleanly and fast enough.
Follow-up questions- How would you sort those intervals to minimize the time the LLM spends processing the queries?
Q2. Given meeting-room style schedule data, which rooms are free and at what times?
How they answeredThe second problem was basically a meeting rooms question. I had to find which rooms were free and when they were free. Again, the format was slightly more real-world because the input came through a provided method instead of just an array in the prompt. That round made it really obvious they care about syntax speed and being able to code without a lot of pauses. I did not feel like they were testing tricky theory. They were testing how fast I could execute.
Follow-up questions- Can you solve it using the provided method/API-style input rather than direct arrays?
- 3
Final / onsite round
System DesignTechnicalArtificial IntelligenceWhat I did next was a back-to-back onsite-style round online: one system design and one debugging interview. This was where the process got much more AI-focused and much closer to what I think they actually care about on the job.
Q1. If you were building an insurance claims agent, how would you design a backend system that ingests claims and makes decisions?
How they answeredI scoped it as a backend-only design where emails come in and the output is a decision like approve or deny a claim. I talked through building a RAG-style pipeline to extract data from emails and PDFs, then combining that with policy metadata and user policy info.
Follow-up questions- How would you use RAG to extract data from claim emails and PDFs?
- How would you keep LLM token usage from getting too expensive?
- What infrastructure or cloud services would you use to handle ingestion and storage?
Q2. Here is a codebase that is not getting output from the model. Can you debug what is going wrong?
How they answeredThey gave me around 150 to 200 lines of clean, modular code and an API key to test against one of their own model endpoints. The task was basically to figure out why the system was not returning model output. I used a lot of print statements to narrow down which methods were actually involved, because the hard part was not reading messy code. It was tracing the relationships between pieces. I found that the issue was in the hashing flow for the prompt, and that mattered because they were using hashing to reduce token cost.
Follow-up questions- Which method or methods are involved in the broken functionality?
- How would you isolate the issue using print statements?
- Can you identify the problem in the hashing logic?
Tips from the candidate
I would not spend all my prep just grinding random hard LeetCode. I would make sure I can do interval and meeting-room style mediums really fast and write clean syntax without asking for much help. For the system design, I would prep practical AI backend stuff, especially RAG, token-cost tradeoffs, caching or databases for static info, and basic cloud services. For debugging, I would practice tracing modular code and figuring out which methods are actually involved instead of just staring at the file.
Company culture
My read was that they know exactly what they are screening for. The engineers were helpful and chill, but the rounds were very candidate-driven, so I had to lead and think on my feet. It also felt like a place that cares a lot about speed and execution over fancy interview theatrics, and the process got more AI-friendly the further I went. There was no recruiter screen up front at all, which made it feel very technical-first. When I asked about culture, one interviewer straight up said it was kind of a 996 environment, so I came away thinking they expect people to work hard and move fast.