System design interview: Design Robinhood (with ex-Google SWE)
HTML-код
- Опубликовано: 25 май 2024
- GET 1-to-1 COACHING for system design interviews: igotanoffer.com/en/interview-...
Today's mock interview: "Design a stock trading app like Robinhood"
Our special guest candidate: Jordan (ex-Google SWE)
Jordan hosts the excellent "Jordan has no life". Check it out: www.youtube.com/@jordanhasnol...
Chapters:
00:00 Intro
01:06 Question "Design a stock trading app like Robinhood"
01:12 1. Clarifications and requirements
05:14 2. Initial design overview
06:22 3. Exchange layer
14:25 4. User layer
23:16 Router layer
31:20 Bring it all together
41:20 Outro
Need more help prepping for your system design interview? Use our free guide: igotanoffer.com/blogs/tech/sy...
About us
IGotAnOffer is an interview coaching platform that helps engineers get a job at top companies like Google, Amazon, Facebook, etc. Our coaches are all ex-interviewers with first hand experience of what it takes to get an offer.
- Read what FAANG engineers say about us: igotanoffer.com/en/reviews
- Get 1-1 interview coaching and land a job at Google, Amazon, Facebook, etc. Browse our coaches: igotanoffer.com/en/interview-...
- Subscribe to this channel for more high quality system design mock interview videos coming soon!
![How Sweet - NewJeans ニュージーンズ 뉴진스 [Music Bank] | KBS WORLD TV 240524](http://i.ytimg.com/vi/UEELqlGOl_k/mqdefault.jpg)
Get 1-on-1 coaching to ace your system design interview: igotanoffer.com/en/interview-coaching/type/system-design-interview
I'd love to see videos of SD interviews going wrong and feedback of the interviewer on why they failed. 99% of candidates dont know what went wrong unless we were really terrible in the interview. but more often than not, we step out of interviews feeling great but not selected without any feedback.
Thanks a lot for having me Tom, looking forwards to the next one :)
Thank you Jordan, was great to have you on!
I think a doubly linked list with a hashmap would not allow for constant time sorting and knowing what bid is the highest, I think a heap with a hashmap combination is your best strategy here.
i really admire your abilities of finding these wonderful engineers with a large spectrum of experiences to help do mock interviews. they really have brought their real life experiences into the interviews. aside from interview preparations, even from the perspective of learning software architectures, these are some really great videos.
I don't understand how can we use round robin and also use websocket? Shouldn't the user directed to the same server because this server have this connection open there ?
If you just need to store the best national bid/ask for all tickers from all exchanges, a normal modern machine is capable of doing so, we can still shard/replicate on the tickers. Also for the pricing part, your client is likely going to connect with your stock pricing service through a load balancer, 100 connections to different servers to drain the battery seems kinda weird to me. To avoid the client/server communication I think we can only ask for the price updates of the tickets shown on the user current screen.
Very good explanation. Thank you.
Data wrangling / enrichment is a huge part not addressed. For instance, bucketing / continuous aggregation into different timeframes and calculating technical indicators. I don't have it all mapped out but I have a feeling redis won't work here.
why not use something like consistent hashing for a user layer which will give it a scaling capability ?
13:30 it's not possible to make binary search in a linked list with log(n) complexity as this list doesn't have indexes.
This was a little hard to follow - for example his talking about linked lists and binary search is a little too deep for system design interviews IMO.
How is a changed value in the Redis cache propagated to the User layer servers ? Will it be a push or pull model ?
Soooo humble 😅
Which level is this interview corresponding to? It seems a bit short for L5 or L6?
This was all over the place, with an unnecessary dive into an overkill algorithm for keeping price data sorted
Completely agree - I’d have definitely have stopped him pretty early on to clarify how quickly he needs to refresh the ticker data on the client device. this is partially on the interviewer for letting him spin his wheels in the wrong direction for too long.
Great video
Woo!
@@jordanhasnolife5163 Love you broskii (no homo)
There are only O(8000) securities listed on all U.S stock exchanges. If in average each Robinhood user trade 50 times per year, 100M users lead to below 500 TPS (8 hours per day). The total size of pending orders is small enough to fit in the memory of a home computer. Replicas for routing server are necessary for redundance and fault-tolerance reason but it is unclear the justification to shard them by stock symbols. Also doing binary insertion on linked list is weird. Overall, the design appears confusing to me here and there.
1) A person can have a thousand orders on 1 securities! 2) Day trades may trade 50 times in a day! 3) If Robinhood allowed algorithms trading, that number would x10!
How would guarantee strong consistency here ?
Letsgoooo
This was all over the place, with an unnecessary dive into an overkill algorithm for keeping prices sorted
In the last section he said UDP from Exchange platforms. As far as I know, the broker application cannot actually decide the protocols to communicate with exchanges. Exchanges keep a common protocol for all the brokers. They cannot be biased in this. Perhaps, UDP is the one they use, but isn't it unreliable incomparison to TCP/IP?
UDP is fast and you need to send it fast. Any error you have you can correct on the application layer.
I don't think his assumption on the ticker price is correct. In my experience, the price shown is the last transaction price on the exchange and what he is describing is how an order book calculates the middle bid. If his assumption of the price would be correct, then anyone can make a really high bid and push price. The price shown should be the last full-filled order (with some logic to trim extreme cases added).
I’m not so sure whether an internet company will ask to design a trading platform as it’s not a common knowledge. On the other hand, do trading firms do system design interviews at all?
Yes they do. I have one tomorrow.
For L3 and L4 at Robinhood, they have 2 system design, 2 coding, 1 project deepdive, and 1 HM sessions. The project deepdive is similar to System design but you present one of your past projects with 2-3 slides or diagrams that you are expected to prepare in advance.
Next video : Design RUclips
Hobinrood ❤
The videos are really good and helpful, thanks a lot. But tbh the interviewer is just the worst. No interesting questions at all - zero. Just what would you do if one server goes down? Man, that's all you know or all you care? No offense and thanks again.)
My $0.02. Don't start answering every single one of your interviewers question with "Yeah, that's a fair question" 😄
why is that? annoying or something else?
What I realize is - it's not useful for someone who works in the same domain/product to do system design. It def came off very weird/empty and at times condescending
What did you find condescending?
Sorry to hear that I came off this was way Aaku!
I'm assuming you meant this in reference to some of the exchange specific information like different OCC exchanges + keeping number of systems listening to them low.
I think that while that's technically knowledge that is not required for this problem, incorporating it makes the problem a bit more interesting, because actually having to aggregate the results themselves to deliver a single valuation for any security/option makes the problem a bit more complex (in fact I've been asked this piece in interviews before!)
Anyways, if you have more questions feel free to ask them here and I'll get back to you!
Have a nice day!
I agree, the interview isn't led by the interviewer but rather by the interviewee. The interviewee came in with the prepared answer and basically shared it on a zoom call. This isn't not at all how it's like during the actual system design interviews.
What'd be more helpful is an actual mock interview where interviewee is challenged with questions regarding the solution the interviewee comes up with. This approach will showcase the interviewee's skills to come up with a solution (optimal or not), discuss about the reasonings and thought process behind it, and depend their system design decisions. Interviewer can ask further questions about the approach then adjust as needed.
@@d-yb2db Don't disagree
@@jordanhasnolife5163 having to get interviewed by this L3-knowledge-robot-zero-personality interviewer didn't help.
Unconventional.
No feature scoping, no API design.
No QPS / bandwidth / storage estimation.
Diagramming too late.
No mention of multiple devices per user.
Not mentioning data structures.
Great, confident speaker though.
Let’s be honest, it was bad.
This is not a good interview. The candidate (TC) spends much too long going into minute details and algorithms and the architecture proposed has several shortcomings that the candidate admitted to and then proceeded to over-engineer unnecessary systems in an attempt to solve these. The interviewer should have asked more probing questions about alternatives considered and the reason why this specific approach was chosen over others. There was also a total lack of the system's topology as well as no data modeling.
TC also displayed several red flags around collaboration and humility. They leaned heavily on a small amount of domain knowledge to appear as a expert in the industry, but their absence of subtlety and consideration in their design shows a lack of experience and could lead to difficulty working well in a group. I would particularly would have liked to see how TC reacted to pushback or critical feedback to their design.
In addition to the high-level misses in this interview mentioned above, several of the details were also wrong or misguided. The estimations given on traffic made incorrect assumptions about client behaviors (such as daily users vs total user population), and no consideration as to the actual capacity of the components used and whether or not partitioning was necessary. The choice of partitioning by ticker and then using round-robin load balancing being competing ideas, etc.
Strong no hire.