Updated by Scale AI candidates
New Grad Software Engineer Interview Experience
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.
- Online assessment
- Phone interview
- Final round
Interview rounds
5 questions across 3 roundsOnline assessment
1 questionOverview
The 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.
Question types asked
Specific questions asked
If you have multiple parties, how would you find the dead zones between their time intervals?
Can you work from the provided method/API-style input instead of a plain array?
I 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.
Phone interview
2 questionsOverview
The 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.
Question types asked
Specific questions asked
How would you sort those intervals to minimize the time the LLM spends processing the queries?
The 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.
Given meeting-room style schedule data, which rooms are free and at what times?
Can you solve it using the provided method/API-style input rather than direct arrays?
The 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.
Final round
2 questionsOverview
What 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.
Question types asked
Specific questions asked
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?
I 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.
Here is a codebase that is not getting output from the model. Can you debug what is going wrong?
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?
They 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.
Interview tips
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.
Get full access with a membership, or share your experience to try it free.
More Scale AI interview experiences
“I was given a PDF of questions related to the card game. I was asked to choose a language, I chose Python, and then I had to write complex Python logic to simulate the Card game amongst 4 players. The logic was not that hard; what was hard was that we had to write a lot of code in a very short amount of time. The interviewer was very helpful and asked me to correct my mistakes pretty early, which saved me some precious time.”
“The wild part was that they basically put me through the same bar as software engineering, then only later figured out whether I fit FDE.”
See all 2 Scale AI Software Engineer interview experiences →
