After mass-applying online, HR reached out really fast — they basically sent the OA in the second week.
The OA was pretty simple: design an in-memory banking system, four levels total. There's discussion of this question all over the forum.
The first level was designing three functions: add account, pay, and deposit. The logic was simple — just define a dict to track accounts and balances.
The second level was to start recording user activity based on timestamp, and design a top_activity function that returns the k users with the highest activity. One thing to watch: activity is the absolute value of the amount — e.g. if someone deposits 200 and then withdraws 100, their balance is 100, but at the current timestamp their activity value is 200+100=300. Also simple — just add another dict to track each account's activity, and top_activity is a basic sort.
The third level was transfer and accept_transfer. The only thing to watch out for: when a transfer starts, money gets deducted right away, but it doesn't count toward activity yet — it only counts once the other side accepts the transfer.
The fourth level was merging accounts and getting balances. The requirements for this level were explained very unclearly. I wrote a first version and then debugged the edge cases based on which unit tests failed. A couple things stuck with me:
If account 2 has already been merged, its activity from before the merge timestamp still exists — but if you query its activity using a timestamp after the merge, it returns none.
Once account 2 has been merged, you can use create_account to add account 2 again (adding it before the merge would just return none). If that happens, it doesn't reset the account's historical activity — it's just that starting from the new creation timestamp, its balance goes back to 0. Worth noting.
In short there were a ton of edge cases like this, but don't stress about it — they're all covered by the unit tests. Just look at which ones fail, walk through that case yourself, and you'll basically find what you missed.
Next was the phone screen.
I noticed that for a lot of people, HR would tell them the topic in the email before the phone screen — like concurrency for some people, and their phone screen turned out to be about web crawlers, that kind of thing.
My phone screen topic was LLM — that keyword had never shown up on the forum before.
I was pretty anxious, but I gritted my teeth and prepared like an MLE would — coding up an MLP and attention from scratch, that sort of thing — but it turned out to be completely useless.
The actual question: I was given a helper function that takes a batch of inputs and returns the token probability for each input, and I had to design a binary classifier using that function.
It wasn't a hard question — just write a system prompt, fill it in based on the data you're classifying, then query the helper function twice and see which time the probability comes out higher — that's the class you go with.
There were a few gotchas along the way — like needing to design it to return a score instead of a plain classification decision, and the helper returns log probability, so you have to process that first.
The follow-up wasn't hard either — just how to improve the classifier's performance. I answered with things like tuning the threshold, doing some prompt engineering, and repeated sampling.
Discussion
Loading comments…