It was a direct two-round company screen — coding plus system design — and if you pass, the next step is the hiring manager round. The interviewer was based in China, so we could only schedule evening slots. The team is a new one in Seattle building a productivity tool.
System Design — a real-time robot-chase mini-game
The problem: the player moves around on a 500×500 terrain grid, and different-height cells take different amounts of time to move across. A number of AI robots pathfind toward the player. The player wins by reaching the goal, and loses if a robot catches them. It's single-player, but the system needs to support a large number of concurrent games, and game history needs to be persisted.
Questions worth asking before diving in: is it single-player or multiplayer, how big is the map, is the robot count configurable, is the terrain pregenerated or generated on the fly, and what happens if the player changes direction mid-move.
What he was testing for:
- Why use WebSocket — bidirectional, low latency, server holds the authoritative state.
- How to model the game state — a 2D height matrix for the terrain, each robot's independent position, the player's position and the goal, and using a "move counter + target cell" to express move duration, with the ability to cancel if the player changes direction mid-move.
- How to do pathfinding — this was what he was most interested in. Treat the terrain as a weighted graph (height difference = edge weight). What I proposed was precomputing at game creation and storing, for every (start, end) pair, only the "next direction," so each robot just does a table lookup every tick. But note: a full pairwise table for a 500×500 grid is O(n²) = 62.5 billion entries. I didn't do that math on the spot, but once you actually calculate it, you realize you need a different approach (run A* every tick, or build a flow field with the player as the source). Lesson: in system design rounds, actually work out the numbers.
- Win/loss determination, and the game history table.
Coding — merging paginated records from multiple data sources
The problem: given a lot of data sources — the interviewer said "hundreds or more" — merge them into a single globally ordered, deduplicated record stream, writing one record at a time through a RecordWriter. Each data source can only be pulled page by page via offset/limit.
My solution: a heap for the k-way merge, deduplicate using the id of the last record written, and when a source's buffer runs dry, pull its next page. If a returned page has fewer records than the limit, that source is exhausted and gets removed from the heap. Since the writer only consumes one record at a time, there's no need to buffer the whole result in memory.
The one question everyone gets asked: AI
The interviewer asked directly, "How do you use AI in your day-to-day work?" and then followed up with, "Would you delegate a task to an agent that picks its own tools?" My advice: have a specific 60-second answer ready — what scenarios you'd use it in, where the boundaries are, how you'd verify the output — because a lot of companies are asking this now.
Company info (from the Chinese-language chat portion)
They're hiring in the US because Singapore doesn't have enough hiring density. The IPO is "in progress," though he said himself that timing isn't up to the business side — he described the business itself as stable rather than explosive. On positioning: Stripe does payments and Wise does cross-border transfers, and those are two separate companies; Airwallex does both, plus holds financial licenses in multiple jurisdictions (local bank collection and payout, account opening) — that's the moat, as he put it.
I got the rejection letter a bit over a week after the interview, no feedback.
Discussion
Loading comments…