Most of the questions were the classic, well-worn ones you'd already find on the forum.
Phone
Leetcode easy + mid
Onsite
2 AI coding rounds + 2 AI system design rounds + 1 BQ
AI coding 01:
Friend system:
Implement a friend recommendation algorithm
Given data: a list of users, a list of friendships (user-user pairs)
Design a strategy to recommend new friends to a user (e.g., search for friends of friends, search for popular users, etc.)
3 test suites, the 3rd one has about 100k users and about 1.5 million friend pairs
AI coding 02:
Card:
Pick-a-card game: a 36-card deck. The solver/player can see the full deck; cards only have values 1-9; pick 3 cards that sum to 15; only 16 (or 15? I don't remember exactly) cards on the table are visible at a time, and after each pick, feed 3 more random cards from the remaining pile if possible. The game is won if all 36 cards get consumed (12 groups).
Need to write new tests to benchmark the algorithm on a large dataset (>1k games)
AI sys design 01:
Video game leaderboard
Entities: players, games, friends, high scores (one per player+game)
Key feature: show the closest scores when a user finishes a game (range search over a large dataset)
AI sys design 02
Ride-share system
A lot of people on the forum ask all sorts of things about AI interviews — that's basically the new interview format a lot of companies are using this year. Most of the writeups on the forum are pretty short. I've interviewed at a bunch of other companies with AI coding rounds recently too, and combining that with my day-to-day experience developing with AI, I've hit countless pitfalls and worked out some things I wish I'd known earlier. Hope this helps. Here's the writeup:
Key differences between an AI coding interview and everyday LLM coding-agent (I'll just call it "AI" below) use
Time limit:
Almost nobody limits the AI to responding within 5 minutes in normal use — the leading models are all built to run independently for as long as possible.
More back-and-forth:
In daily use, basically everyone wants as few interactions as possible; in an interview it's almost the exact opposite.
You can't just sit there staring blankly during the interview — you need to show you can actually work interactively with the AI.
Going off track at any point is hugely costly in time.
Environment constraints:
The interview sandbox is resource-constrained (in most big-company environments I've tested, it's about 1.5 cores, 2GB memory, basically no room for multithreading/multiple sessions/agents), while the test suites behind, say, Meta's AI coding rounds are almost all stress tests.
The most recent AI versions mostly auto-run tests; if you don't explicitly direct them, they'll spontaneously run the large test cases in the interview environment, which eats up a huge amount of time, or can just hang before you've optimized anything.
Strategy:
At the start, add a few session-level prompts to make sure the AI clearly understands this session is special (see below).
The key is telling the AI about the time constraints of the interview environment. For the points below, honestly the smarter models basically figure out their own rules to follow once you explain the time limit and the interview environment — in my experience you basically don't need to repeat this step (write the session prompt, then re-apply); manually emphasizing a few key points is usually enough.
On top of guaranteeing correctness, speed comes first — minimize output, cut/skip tests.
With the newest models (Claude 4.8 / GPT 5.5+), for most interview-level algorithm difficulty you can basically trust the AI to get it right on the first guess/attempt — you don't need to test every tiny step (especially in a Java environment, where every test run needs a build, which still eats up some time).
Break the task down — planning, implementation, testing — and make sure each chunk produces a result in 2-5 minutes.
This is the most important point, and it's basically my go-to session prompt every time (set as a session-level memory/standard).
With the newest models (Claude 4.8 / GPT 5.5+), let the AI do all of this itself: plan the implementation steps, estimate the time, and adjust with prompts if needed.
With the very newest models, you can insert new prompts mid-run, though most of the environments I've interviewed in recently don't support that, and the interview's cheap little VM sometimes gets unstable from interrupted execution — sometimes you even need to refresh the page or restart the environment. Better to minimize interruptions as much as possible.
Recent model versions are generally pretty good at task decomposition — aim early for the final target and plan implementation steps toward it (the most optimized algorithm), instead of the usual coding-interview approach of writing a basic version first and optimizing later. You can go straight for a more complex optimized algorithm, which cuts down on the context burden of later prompting.
AI system design:
From what I've seen, this basically isn't really deployed yet — the interviewer says you can use AI, but in practice you don't really end up using it, and some interviewers straight up say they don't recommend it. In practice, the AI system design interviewers I've had didn't provide any real use case — they just gave you an AI chat window and said you could use it to unblock yourself as needed (which isn't really different from the pre-AI days when you'd just google something you didn't know). Since these are also all decades-old classic system design questions, and system design itself is really about demonstrating your depth of knowledge, personally I didn't feel there was much of a positive use case. Some platforms have an AI diagram-drawing feature that I used a bit when drawing flow diagrams (the mouse isn't great for that), which occasionally saved a few seconds, but it wasn't the key to the interview either.
Below is a consolidated version of the session-level rules I use a lot — once I got a feel for the rhythm after the first few interviews, I've used something like this almost every time, and it's worked well (e.g., for the Meta card game: 99.97% win rate in 40 seconds on 10k cases). Obviously you can't just copy-paste this straight into an interview — I usually type out a few of the rules I think matter most for the specific question by hand, and adjust on the fly during the interview.
Short version:
- Timed interview, weak box (~1.5 cores, flaky tools).
- Cap each response to ~3 min of work. If a task will exceed that, stop and give me a breakdown with step time + expected gain.
- Before any optimization, quote expected gain + effort; skip if marginal.
- No long background runs; cap every run with a timeout (30-60s), single-threaded.
- Correctness first; validate on tiny samples, full sample only with explicit human confirmation.
Full starter prompt (Java stack)
You're helping me with a timed (40-minute) CoderPad interview task (Java/Maven, shared container, about 1.5 CPU cores, unreliable tooling). The goal is to deliver correct code as fast as possible, not to be clever. Unless I explicitly override these, follow the rules below:
Timing and communication
- Put at most about 3 minutes of work into each response. If a task will take longer than that, stop and give me a breakdown, including the time and expected gain for each step, then let me choose.
- Before doing any optimization, state: (a) the expected improvement, (b) the estimated effort, (c) the risk. If the gain is small or the effort is high, recommend skipping it.
- Keep answers easy to skim: give the result first, then the reasoning.
Environment safety
- Never start background or long-running JVM processes. Every run must have a timeout (<= ~200 seconds), and prefer single-threaded execution with reduced (nice) priority.
- Assume only about 1.5 CPU cores are available: don't run benchmarks in parallel, and don't start multiple heavy JVMs at once — they'll lock up the whole environment.
- After every change, re-read the file to confirm the change was actually applied (this tool sometimes reports a timeout even though the change went through, which leads to duplicate edits).
Workflow
- First read the code and the problem statement, then restate the goal, the pass criteria, and exactly which sample/metric those criteria are measured on.
- Before optimizing anything, make sure correctness fully passes first.
- Set up a small measurement harness early: tiered sample sizes (20 / 100 / full), with a fixed, persisted seed so runs are reproducible and comparable.
- Iterate using the smallest sample that can falsify a change; only run the full sample when I explicitly ask for it.
- Prefer batching a set of changes in one go rather than multiple tool round-trips. Keep scratch/benchmark code clearly separated from the real code, and remind me to delete it before submitting.
Verification discipline
- Never claim a performance improvement without an actual before/after measurement on the same sample.
- If a result could just be noise from too small a sample size, say so explicitly.
- Keep a short changelog recording avg/worst/time for each change, so we can compare.
At the start, read the problem first, then give me: the goal, the pass criteria, a plan with 3-5 items and time estimates, and the first correctness milestone. Don't optimize before I confirm.
Discussion
Loading comments…