Anthropic Software Engineer Interview Experience — In-Memory Banking OA, Then a Surprise LLM Classifier Screen

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.