HR: Basically just chatted about my general situation. But I didn't tell the recruiter that I'm no longer at Amazon — over the last year and a half I wasn't very proactive at my previous company, and I didn't really listen to my manager, and I got PIP'd in May. (Should I be more upfront with the recruiter about this? If I actually get an offer, will the company find out during the background check afterward and rescind it?)
OA: I honestly don't remember the OA part anymore — it was probably similar to what I'd already seen in other people's reports on the forum. Basically one question with four parts in 90 minutes, and the third part needed a lot more code. I used Java, and I always feel like Java makes you write more code overall.
Onsite:
System Design -> Similar to what I'd seen in other people's write-ups. It was designing a cryptocurrency trading system, with a third-party exchange, interacting with that exchange through a sync API. I had prepared for something like this beforehand. But the interview still had some rough patches — I felt like I had some misunderstanding, and it wasn't until afterward that I realized: even though the interviewer called it a sync API, it was actually still async, because an order goes through multiple state transitions. The interviewer focused a lot on the state transitions of the transaction order, and also asked how to handle it if the third-party exchange times out or fails, and how the system should handle spiky traffic.
Coding -> An Iterator problem, one question with three parts. Similar to other reports I'd seen on the forum. But I want to remind everyone: go practice writing this kind of thing by hand in a blank environment beforehand, to get more comfortable with it. I had assumed there wouldn't be tests and that I'd just need to write my own. It turned out there wasn't even a starter function — everything had to be written from scratch based on the prompt. And you had to write the iterator interface yourself, then write two classes implementing it. Normally the IDE handles a lot of that for you, but when you write it all out completely by hand, it's easy to make mistakes. I kept hitting errors while writing the class and interface, and it took me a good while of testing before I got it to actually run. I'm not sure if that counted against me.
Coding -> Food delivery system. One question with three parts. Felt like a relatively new question. The first part gave a bunch of menus and restaurants and asked to find the lowest price and the nearest restaurant. The second part gave a menu (with per-item prices) and a set of orders, and asked for the total price and number of orders over a period of time, then the average. The third part asked for the Top K orders by total price over a period of time, and the Top K items by unit sales volume. Honestly the problems themselves were pretty simple, but writing the functions and tests in Java was still a bit of a struggle — I was worried about not having enough time for tests, so I wrote the code fast, which made it easy to slip up on small things. I also misread part of the problem and had to go back and fix my code after the interviewer pointed it out. On top of that, there were some typos in the interviewer's own problem statement — the last part was supposed to ask for Top K items, but it was written as Top K orders, and the interviewer corrected it. (I get the feeling their actual work environment is probably like this too — maybe not that hard, but pretty chaotic.)
BQ -> The interviewer seemed pretty tired. Questions included: my most complex project, and an example of handling the same problem in more than one way.
Discussion
Loading comments…