Five rounds plus one add-on round, the most intense interview I've had this year.
Fair warning up front: the intensity here is not the same league as other places. Five rounds packed into two days, two of them straight-up hard, and then they tacked on an extra round at the last minute. By the evening after I finished I was basically wrecked.
Some interviewers were Chinese, some were not. All the ones I got happened to be Chinese, so we spoke Chinese, but I'd still suggest writing your code comments and variable names in English. The problem titles were given to me as coded/homophone substitutions (a common thing on this forum to dodge keyword filters), so below I'm just describing what they actually asked.
Round 1
Forty-five minutes, one problem, and it was hard right out of the gate.
The problem: you're given a bunch of stickers, each sticker has some letters on it (you can use the same sticker type unlimited times), and you need to find the minimum number of stickers required to spell out a target string.
I knew immediately this was a hard. Took a breath, told the interviewer "I need a minute to think this through," he said that was fine.
For the approach I started with the naive idea: this is essentially a state-search problem, where the state is "which letters of the target string are still uncovered." Since the target string length is no more than the mid-teens, you can use a bitmask to represent which positions are already covered, then do memoized search or BFS.
Concretely: dp[mask] = the minimum number of stickers needed to reach this coverage state. From the current state, find the first uncovered position, and only try stickers that contain that character (this is the key pruning — otherwise the branching explodes), use that sticker to cover as many subsequent positions as possible, and transition to the new state.
I got stuck while writing on "how to optimally cover the remaining positions with one sticker." At first I wanted to enumerate every way of assigning the sticker's letters. The interviewer hinted: "the letters on the sticker can match arbitrarily, you just need to greedily fill left to right." That one line snapped it into place for me.
I only got to run one small test case before time was up. The complexity I gave was O(2^n * m * n), where n is the target string length and m is the number of stickers.
I didn't feel great walking out of this round, since the code wasn't validated enough.
Round 2
The problem was minimum window substring. Given two strings S and T, find the shortest substring in S that contains every character of T, including multiplicity.
I'd practiced this one before, so it went smoothly. Sliding window plus two hash maps — one tracking what T needs, one tracking the window's current state — plus a counter tracking how many distinct characters are currently satisfied. Right pointer expands, once the window is satisfied the left pointer contracts, and the answer updates during contraction.
What the interviewer focused on:
First, exactly when to increment/decrement the valid-count counter. This is the easiest place to get wrong — you can only increment it at the exact moment a character's count in the window equals the required count, not beyond that.
Second, when to update the answer during contraction. It has to happen before contracting, because after contracting the window might no longer be valid.
Third, complexity. O(|S| + |T|), since each character is visited at most once by each pointer. He followed up with "does a hash table operation count as O(1)?" — I said if the character set is fixed you can use a fixed-length array instead, which is strictly O(1).
Follow-ups: what if T's requirement is "at least k occurrences" instead of an exact count? Just change the value in the requirement map, the rest of the logic stays the same. What if you need to return all shortest substrings? Record every starting point that achieves the minimum length.
This round went pretty well, I had about ten minutes left over to just chat.
Round 3
The problem: design a data structure that supports adding numbers and returning the median of all numbers currently stored, at any time.
Two heaps. A max-heap holds the smaller half, a min-heap holds the larger half, keeping the size difference between the two no more than one. When adding a number, push it into one heap then rebalance; get the median based on whether the total count is odd or even.
After I finished, the interviewer fired off a string of follow-ups:
What if the number range is known and small (say, ages 0 to 100)? Then use a counting array — adding is O(1), and finding the median means scanning at most 101 entries, faster than the heap approach.
What if the data is too large to fit in memory? We got into approximate quantiles — I said you could use sampling or a structure like t-digest that only keeps a summary. I don't know this area deeply, so I only sketched it at a high level.
What if you need to support deletion? Heaps don't support efficient deletion, so I said you could use lazy deletion: maintain a pending-deletion set, and if the heap top is in that set, pop it before reading; you'd also need to separately track the count of valid elements in each heap. He had me walk through this logic out loud.
What about multithreading? Read-heavy, write-light workloads can use a read-write lock, locking the whole thing on writes. If you need higher concurrency you'd have to consider sharding the stats and merging them, but median doesn't merge cleanly the way a sum does, so that's a lot more expensive.
Round 4 — machine learning / recommendation system design
The question: design a short-video recommendation system.
For this round I walked through it using the standard rec-sys architecture:
Recall layer. Multiple recall paths run in parallel: collaborative filtering (what did people who watched similar videos also watch), content similarity (based on video tags and embeddings), a popularity fallback, follow-relationship based recall, and a cold-start strategy for new users. Each path returns hundreds to low-thousands of candidates, then merge and dedupe.
Coarse ranking. Use a lightweight model (e.g. two-tower) to cut a few thousand candidates down to a few hundred, mainly to keep the compute cost of the fine-ranking stage under control.
Fine ranking. Use a heavier model to predict multiple objectives — completion rate, like rate, comment rate, follow-conversion rate — then weight and combine them into a single score. The interviewer pushed on "how do you decide the weights for multiple objectives" — I said the weights themselves are a business decision, tunable through AB testing, and there's also multi-task learning approaches that let the model learn the weighting itself.
Re-ranking. This layer handles what fine ranking can't: the same author's content shouldn't cluster together, content types need diversity, and a certain proportion of slots need to be reserved for exploration.
A few points that got dug into deeply:
First, cold start. What do you do with a new video that has no interaction data yet — give it some exploration traffic, use content features to estimate an initial score, then adjust quickly based on feedback from its first few hundred impressions. What about a new user with no history — start with registration info and device info for a coarse profile, and weight the behavior from their first few dozen videos heavily.
Second, feature leakage across time. If training uses features that wouldn't actually be available at prediction time, online performance ends up far worse than offline. I said you need to strictly construct feature snapshots keyed to the event timestamp. He was noticeably satisfied with this answer.
Third, real-time responsiveness. A user just swiped away from a video — can the next recommendation reflect that immediately? I said you need a real-time feature pipeline, streaming updates to the user's recent behavior sequence, and the model side needs to be able to ingest at least the last few dozen actions.
Fourth, evaluation. Offline you look at metrics like AUC; online you have to run AB tests and look at North Star metrics like watch time and retention, not just click rate — otherwise you'll easily end up optimizing your way into promoting clickbait.
This was the round I enjoyed the most, because there was a lot of room to just riff.
Round 5
Behavioral, with a deep dive into my resume. Questions included: most challenging project; how do you resolve disagreements with others; what do you think your biggest weakness is; why do you want to change jobs; can you handle high intensity.
That last question was asked very directly, so I answered it honestly too.
Add-on round
Got notified the next afternoon of an extra round tacked on last minute. The interviewer said it was to "look at things from another angle."
The question: given an integer array, determine whether there exist three numbers a, b, c such that a² + b² = c².
For example, [0,1,-2,3,4,5] should return true, because 3, 4, 5 satisfy it. Note that [0,0,0] and [0,1,-1] also return true.
My approach: take the absolute value of every number, square it, and put it in a set (note that even after dedup you still need to preserve info about how many times 0 appeared). Then do a double loop over a and b, and check if a² + b² is in the set. Complexity O(n²).
The trap is 0 and duplicate elements. [0,0,0] should be true, meaning the same value can be reused multiple times — because the array actually contains three 0s. But if the array has only a single 0, [0] can't produce three numbers. So the set can't just store the values, it also needs to store how many times each value occurs, and you check during enumeration whether there are enough occurrences left to use. I only patched this in after the interviewer specifically asked about the [0] case.
At the end the interviewer asked if this could be optimized below O(n log n). I said this class of problem is usually stuck at O(n²) unless there's an additional constraint on the value range that lets you speed it up with bit tricks. He said that was right, he just wanted to see if I'd hard-code a wrong optimization.
Discussion
Loading comments…