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 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.
Questions asked
Overview
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.
Get full access with a membership, or share your experience to try it free.
