Updated by xAI candidates
Senior Software Engineer, Safety Interview Experience
When I went on-site in Palo Alto, they had security guards with guns at the entrance, were doing bag checks, and I even needed an escort to the bathroom. It honestly felt like TSA before an interview.
Interview process
I originally applied to a different xAI role, and an engineer on that team redirected me to the Senior Safety role after a quick intro call. From there I did a hiring manager screen, a practical technical phone screen, and then an onsite in Palo Alto with one coding round and one hybrid coding/system design round, plus a short follow-up call after. The actual questions were much more practical class-design problems than LeetCode, which matched a broader trend I was seeing, but xAI gave almost no useful prep and the process felt pretty ad hoc. The onsite was easily my least favorite one because the whole thing started with armed guards, bag checks, and escorting me around the building, and then one interviewer spent a bunch of the coding round on his phone. I got rejected afterward with a vague note about a shift in prioritization of open roles, so I still do not know whether the role actually changed or if that was just their way of saying no.
- Phone interview
- Technical interview
- Final round
- Other
Interview tips
I would not over-index on LeetCode for xAI. I would spend a lot more time on practical object-oriented and class-design problems like iterators, transactions, and rate limiters, especially prompts that are intentionally vague and then get follow-ups around extensibility. Ask clarifying questions early, because at least one round was looking for a much simpler initial scope than the prompt made it sound like. I would also practice writing complete, bug-free code with sensible input validation instead of obsessing over runtime trivia, because they barely seemed to care about complexity. And honestly, go in expecting very little recruiter prep and a pretty intense onsite vibe so that part does not throw you off before the interview even starts.
Company culture
My read is xAI is hiring fast and pretty loosely right now. I never got the polished recruiter-prep experience you get at more mature companies, the first screen was with an engineer, and I got the sense interviewers had a lot of freedom in what they asked instead of pulling from a tight question bank. The Safety team also sounded extremely small, to the point that other teams were helping interview because they barely had engineers there yet. The coding bar felt more about whether I could write practical, complete code than whether I could recite optimal LeetCode solutions, and one interviewer literally told me they ask easier problems than some other companies. The weirdest thing for a Safety role was that nobody really tested safety judgment or ethics at all. The whole process felt very shipping-first and code-first, and I even had one interviewer tell me leadership cares a lot about the code you ship.
Questions asked
Overview
The onsite in Palo Alto felt off before the interviews even started because there were armed guards, bag checks, ID checks, and I even needed an escort to use the bathroom. The loop itself was two rounds: one coding round with a really disengaged engineer, then a hybrid coding and lightweight system design round with the hiring manager. The problems were manageable, but the vibe made it my least favorite onsite.
Question types asked
Specific questions asked
How would you extend your solution to support a list of iterators that behaves like one iterator?
What other edge cases are you thinking about?
What if your input is not a list?
I implemented the iterator with next, hasNext, getState, and setState, then extended it so a list of iterators would behave like one continuous iterator and getState would return the global index across them. I was proactively talking through edge cases as I coded. The only push I remember was him asking something very basic like what if the input is not a list, and I said I would just add an if check for input validation.
What rate-limiting approach would you choose?
How would you support rules that apply to multiple URLs together?
How would you support rules based on inspecting the request payload, like cumulative payload size over a time window?
I started by asking clarifying questions because the prompt was intentionally vague. I talked through the common approaches like fixed window, rolling window, and leaky bucket, then scoped the first version to a simple per-URL limiter. After that I designed it to be more modular so it could support compound rules, like one limit shared across a.com and b.com, and more complex rules based on cumulative request-body size over five minutes.
Get full access with a membership, or share your experience to try it free.
