Dima clearly has more pre knowledge about co-editing and voice recording but his interview style is more free style with mind games sometimes and is hard to follow; while Bruno show cased a more traditional system design interview style. Curious what interviewers recommendation on these two different approaches.
Thank you for this! So true about the sys design videos out there, prepared for weeks before recorded. Totally unreal, but still useful of course. This gives everyone a more realistic picture, giving hope to less experienced folks. Being on both sides of this kind of interviews for years, I can say that this is 100% real, this is what it really looks like.
I really like Dima's cogent and coherent explanations given on the single source of truth event bus ( with open-source MQs :-) like Kafka ) coupled with the sharded-by-partition/topic snapshots infrastructure pattern ; he really demonstrates how to knock out in this case four birds with one single stone : (A) To minimize the complexity of replaying linearized totally ordered events when working at scale (B) To minimize the passing of large chunks of code over API network calls even at the trade off of additional infrastructure (C) Thirdly, to extend a system of replayability with two different modes for the code execution nodes : timestamps ( the snapshots ) or offsets and partitions/topics ( the event bus ) (D) Fourthly, to predict ahead of time issues that can arise with sticking to just a single global event stream. And two major discussion points drove these bullet points : the need for replayability followed up by the need to minimize the complexity and the resource costs of replayability when systems scale up.
Dima's explanation of CRDTs and when it's applicable, and how it might not be necessary for this given problem constraint was effortlessly explained. Great segment!
Awesome stuff! Some constructive criticism: Each candidate should get at least 45 minutes and the scope should’ve been much smaller. Would have had much more time to go into normal details that you normally do in a system design interview. Most of my criticisms really just originate from the lack of time. It would have been great if Bruno could have touched on the db schema, the choices of technology for each part, how to scale the system (he does go into this during q&a which is nice). All of these parts are missing, not because he didn’t know them, but rather due to the nature of the problem. Just from what he did during the 30 minutes its hard to realize hes as strong as he is. The part Dima did well was talk about which technologies he would use and knew specific terms. The communication on the actual design and time management left a bit to be desired though. I honestly still don’t fully understand his drawing (is the left part the frontend or a service? If its a service how do we communicate with it? What is this local and cloud db and what are we storing on it? Why are the requirements just in a box inside the component?) I mean, I can kind of guess what was meant, but it should be more clear and explicit imo. I would love interviewing io did a round 2, but instead gave more time on a single problem and drove in on how they would handle scalability, ensure reliability, justify technology choices, show the important parts of the schema, and touch on latency/machines needed since these are the key compenents of what you get graded on in a real interview.
Thank you so much for the detailed feedback! We’ll do our best to incorporate some of these wonderful suggestions in our future iterations. That being said, be on the look out for part two in which Dima and Bruno go into much further detail about their designs from this video!
I want to point out that in real sysdes interviews, there is always a tradeoff between time and showing off everything you know. Picking your battles is a good analogy here and that is why one should always try to identify what is interesting about the problem and then cover it before trying to do anything else. In any case, thanks for your comments. :)
The interaction between Dima and his interviewer plays out as though Dima is the interviewer's mentor; he's clearly knowledgable but there's few concrete things said by Dima here. The whole event sourcing bit is a side note at best.
I thought Bruno's overall strategy is a safer generic approach to a system design interview. Keep it high level, finish the overall solution early. Leave room for diving into the details at the end. Dima's approach seemed to chew up a lot of time doing gymnastics or trying to impress rather than just spending the first 10 minutes laying some basic solid foundations to score the easy low-hanging fruit points on the board before flexing later. Anyway. Good video. Useful preparation. Thanks. Both of them are clearly very knowledgeable with a ton of experience.
Bruno missed the mark on the second question, I think the interviewer wanted to hear about ensuring the sequential editing of data. i.e. versioning or diff based editing.
Saying something is trivial like how Dima did is a big red flag. The guy also says jibberish the majority of the time instead of going into the main points
Thank you for the constructive criticism! Dima is always happy to have people challenge him and his points. Feel free to join us on discord, we’d love to hear more about your perspective.
Yes, the peers should be connected directly to one another. However, there are several server peer implementations such as Wowza server and MediaSoup that allows servers to join and record. Unfortunately, WebRTC is not guaranteed delivery so you might get dropped packets.
![Two Ex-Google System Design Experts Compete: Who will design the better system? [Part 2]](http://i.ytimg.com/vi/PU_sgwZvm6s/mqdefault.jpg)
![Two Ex-Google System Design Experts Compete: Who will design the better system? [Part 2]](/img/tr.png)
Dima clearly has more pre knowledge about co-editing and voice recording but his interview style is more free style with mind games sometimes and is hard to follow; while Bruno show cased a more traditional system design interview style. Curious what interviewers recommendation on these two different approaches.
Very impressed with Bruno's structure, and Dima's details
Thank you for this!
So true about the sys design videos out there, prepared for weeks before recorded. Totally unreal, but still useful of course.
This gives everyone a more realistic picture, giving hope to less experienced folks.
Being on both sides of this kind of interviews for years, I can say that this is 100% real, this is what it really looks like.
Yes, you may be an excellent enginner but to face an unseen problem..it takes guts
I really like Dima's cogent and coherent explanations given on the single source of truth event bus ( with open-source MQs :-) like Kafka ) coupled with the sharded-by-partition/topic snapshots infrastructure pattern ; he really demonstrates how to knock out in this case four birds with one single stone :
(A) To minimize the complexity of replaying linearized totally ordered events when working at scale
(B) To minimize the passing of large chunks of code over API network calls even at the trade off of additional infrastructure
(C) Thirdly, to extend a system of replayability with two different modes for the code execution nodes : timestamps ( the snapshots ) or offsets and partitions/topics ( the event bus )
(D) Fourthly, to predict ahead of time issues that can arise with sticking to just a single global event stream.
And two major discussion points drove these bullet points : the need for replayability followed up by the need to minimize the complexity and the resource costs of replayability when systems scale up.
Dima's explanation of CRDTs and when it's applicable, and how it might not be necessary for this given problem constraint was effortlessly explained. Great segment!
The video we didn't know we needed. Thanks!!
Awesome stuff!
Some constructive criticism:
Each candidate should get at least 45 minutes and the scope should’ve been much smaller. Would have had much more time to go into normal details that you normally do in a system design interview.
Most of my criticisms really just originate from the lack of time. It would have been great if Bruno could have touched on the db schema, the choices of technology for each part, how to scale the system (he does go into this during q&a which is nice). All of these parts are missing, not because he didn’t know them, but rather due to the nature of the problem. Just from what he did during the 30 minutes its hard to realize hes as strong as he is.
The part Dima did well was talk about which technologies he would use and knew specific terms. The communication on the actual design and time management left a bit to be desired though. I honestly still don’t fully understand his drawing (is the left part the frontend or a service? If its a service how do we communicate with it? What is this local and cloud db and what are we storing on it? Why are the requirements just in a box inside the component?) I mean, I can kind of guess what was meant, but it should be more clear and explicit imo.
I would love interviewing io did a round 2, but instead gave more time on a single problem and drove in on how they would handle scalability, ensure reliability, justify technology choices, show the important parts of the schema, and touch on latency/machines needed since these are the key compenents of what you get graded on in a real interview.
Thank you so much for the detailed feedback! We’ll do our best to incorporate some of these wonderful suggestions in our future iterations. That being said, be on the look out for part two in which Dima and Bruno go into much further detail about their designs from this video!
I want to point out that in real sysdes interviews, there is always a tradeoff between time and showing off everything you know. Picking your battles is a good analogy here and that is why one should always try to identify what is interesting about the problem and then cover it before trying to do anything else. In any case, thanks for your comments. :)
The interaction between Dima and his interviewer plays out as though Dima is the interviewer's mentor; he's clearly knowledgable but there's few concrete things said by Dima here. The whole event sourcing bit is a side note at best.
I thought Bruno's overall strategy is a safer generic approach to a system design interview. Keep it high level, finish the overall solution early. Leave room for diving into the details at the end. Dima's approach seemed to chew up a lot of time doing gymnastics or trying to impress rather than just spending the first 10 minutes laying some basic solid foundations to score the easy low-hanging fruit points on the board before flexing later. Anyway. Good video. Useful preparation. Thanks. Both of them are clearly very knowledgeable with a ton of experience.
Bruno missed the mark on the second question, I think the interviewer wanted to hear about ensuring the sequential editing of data. i.e. versioning or diff based editing.
52:40 event sourcing is great
Dima totally confused me, (even by saying its impossible to design it) , mixing FE and BE. Bruno was more organized and clear.
real gigachad in intro
So did they pass?
Nope
Saying something is trivial like how Dima did is a big red flag. The guy also says jibberish the majority of the time instead of going into the main points
Thank you for the constructive criticism! Dima is always happy to have people challenge him and his points. Feel free to join us on discord, we’d love to hear more about your perspective.
without looking, my guess is he rose up the levels thru promos and not hopping
The short clips saying exactly the same thing is entirely unnecessary
isnt WebRTC a p2p protocol - how does the audio get to the server than?
Yes, the peers should be connected directly to one another. However, there are several server peer implementations such as Wowza server and MediaSoup that allows servers to join and record. Unfortunately, WebRTC is not guaranteed delivery so you might get dropped packets.
Dima not sure...Bruno is awesome