We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free
interviewing.io

An Interview with a Microsoft engineer

Watch someone solve the design gaming leaderboard problem in an interview with a Microsoft engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Design gaming leaderboard

Interview question

Design a real-time gaming leaderboard

Interview Feedback

Feedback about Functional Torch (the interviewee)

Advance this person to the next round?
Thumbs upYes
How were their technical skills?
3/4
How was their problem solving ability?
3/4
What about their communication ability?
4/4
The interviewer followed the templates that is expected for any big tech : - Functional Requirements - Non Functional Requirements - Estimation - API Design - High Level Design - Data Model - Build on the cloud - Others Overall, the interviewee did good but there were few areas where he could improve and I provided the feedback esp. on discussing tradeoffs, going deeper discussions on major components and improving on the pace. He can also use the examples from this site as well - https://github.com/donnemartin/system-design-primer

Feedback about Monadic Phoenix (the interviewer)

Would you want to work with this person?
Thumbs upYes
How excited would you be to work with them?
4/4
How good were the questions?
4/4
How helpful was your interviewer in guiding you to the solution(s)?
4/4

Interview Transcript

Monadic Phoenix: So we'll spend one hour for this mock interview and I guess this is going to be a design interview for Microsoft. First five minutes you'll tell me about your brief background and then next 45 minutes we'll deep dive into one of the design questions and at the end, five to 10 minutes, I'll give you feedback on how you can improve on these design interviews.
Functional Torch: Yeah.
Monadic Phoenix: Does that meet with your expectation?
Functional Torch: Yeah, definitely. Sounds good. Looking forward to it.
Monadic Phoenix: Okay.
Functional Torch: Yeah, so I'm currently working as a staff engineer and I have industry experience of around 13 years. I have worked at operating system level, also networking level for the past eight, nine years. I have been working at working in the backend domain developing web services. Half of it was spent in a monolithic architecture and my current job is microservice architecture, responsible for owning a platform which is a suite of microservices which are highly available and reliable. I own the payments platform currently, so I'm responsible for supporting the payment method management, transaction management and the risk management on the transaction and their lifecycle for the application at my company.
Monadic Phoenix: Okay, sounds great. So just to level set here, so what level are you applying at Microsoft?
Functional Torch: So I am targeting principal at the moment.
Monadic Phoenix: Okay, so that's L65, I guess.
Functional Torch: Yes. Yeah, I'm targeting principal at the moment. I have a. I have, I've already had one round of integration view and I have the following rounds, the full loop next week. Yeah, I've been preparing for some time. I have also given like real interviews and mock interviews and over the past couple of months and yeah, just want to use this opportunity to.
Monadic Phoenix: Yeah.
Functional Torch: As possible before the final interview.
Monadic Phoenix: Yeah, absolutely. Yeah, makes totally sense. Yeah. So if you are targeting for L65 and above, I guess there is going to be a separate system design interview.
Functional Torch: Okay.
Monadic Phoenix: Yeah, sounds great. Okay, so let's start with. So the. Do you want to toggle to the whiteboard or do you want to start from this note?
Functional Torch: I can start with the whiteboard, but yeah, I can toggle to the whiteboard and start there. Yeah. Okay, I'm on the whiteboard now. Okay.
Monadic Phoenix: Yeah, so let me put the question here. So yeah, so today we are going to design design real time gaming leaderboard. Yeah. Okay, so this is, this is, this is the design question for today.
Functional Torch: Okay, so when we say real time Gaming leaderboard. This is an online system, right? Like where multiple players may be playing across the world. And is this for like, so this. So this is either for a tournament or just in general when folks are playing video games?
Monadic Phoenix: Yeah, that's a good question. So let's say for this one we'll limit this to tournament or for competition. Yeah.
Functional Torch: Okay. Okay. So the scope is for tournament and competition. Do we know how many players would be participating in this tournament or competition on average?
Monadic Phoenix: So let's say like there's a. Average of like we can say that there's a 5 million daily active users.
Functional Torch: Okay. Okay.
Monadic Phoenix: Yeah. And let's say each player plays 10 matches per day on average.
Functional Torch: Okay. Okay. And, and in this tournament. So when, when I think of a leaderboard, typically this leaderboard is like, if I can draw here, you know, you have, you know, you will have players here a little bit ranked, right? So player number one, player number two, player number three. And typically you will see like top 10 players and then somewhere in the, in, in the middle it will be your rank to be like whatever the, the current player.
Monadic Phoenix: Right.
Functional Torch: So, so basically this leaderboard. So if I understand correctly, this leaderboard one will need to show top. So sorry, top 10 ranked players in the tournament. Right. And I'm assuming that these players may be playing different games. Right, so it's like across the overall different games that, that happens is in aggregate, Right. Or do we want.
Monadic Phoenix: Yeah, that's a, that's a good question.
Functional Torch: Ranking as well.
Monadic Phoenix: So for this, it's an interview question. So let's limit it to like one game. But this is since a tournament, so it happens every, let's say, we can say, I think month.
Functional Torch: Okay.
Monadic Phoenix: Every month. Right.
Functional Torch: Okay. Okay. So it's a single game tournament, but it happens once a month.
Monadic Phoenix: Every month.
Functional Torch: Yeah. Okay. Okay. Now and so I need to see the top end ranked. And then, you know, users use their, their own rank on the leaderboard. And along with the rank, there would be some score available, right, that you would, that they would see.
Monadic Phoenix: Yeah, yeah.
Functional Torch: Each layer needs to be there. And what else do we want to show? Is there anything else we want to show in here?
Monadic Phoenix: I think this looks good ranked. Maybe you want to show the player like a username or name, whatever.
Functional Torch: Right, yeah, that is. Yeah, that is definitely. Yeah, so yeah, that was kind of implicit. But I should call it out, right?
Monadic Phoenix: Yeah.
Functional Torch: Okay. And with respect to happening Once a month, 5 million daily active users. So when you say daily active users, they are the, these 5 million like players on the leaderboard. Right. Like these are actual players, right? Not like. So there are some tournaments that happen where, you know, tournaments are happening and then those tournaments are being streamed. So they are like, you know, more viewers of the tournament than the actual players. So are we, when we say 5 million daily active users, this is just a number of participants in the tournament or this is just a total set of everyone who is actually viewing, who may be viewing or playing in the tournament.
Monadic Phoenix: So these are the players who are playing.
Functional Torch: Okay.
Monadic Phoenix: 10 matches per day on average.
Functional Torch: Okay. And. All right. And so these are the ones who are also looking at the leaderboard. Like there's no separate view number for the viewership of the leaderboard. Right?
Monadic Phoenix: Yeah, that's a great.
Functional Torch: That's what I want to get.
Monadic Phoenix: So we can. Yeah, yeah, we can make an assumption that there are like a total users. You can say that there's like a 25 million monthly active users.
Functional Torch: Okay.
Monadic Phoenix: Out of that. Yeah.
Functional Torch: Okay, okay.
Monadic Phoenix: And out of that it's the average of 5 million daily active users who play that. Yeah, 10 matches per day.
Functional Torch: Okay. Okay. And so, and it's the problem says real time gaming reward. So like one of the requirement is that, you know, it should like the updates, the rank updates should happen real time. Right. So basically there is no stale data. Okay. Excuse me. And, and so that basically means that, you know, this, this should be a very low, sorry, low latency system. And given that we are assuming that 5 million daily active users are there. So needs to have to be highly scalable and. Scalable and available. Okay. So any other non functional requirements that I could capture here? And when we are saying this leaderboard is just a dashboard sort of thing that automatically updates, is there also like a requirement or implicit requirement for someone to be able to search somebody else and see their rank or whatever?
Monadic Phoenix: No, I think we can keep it simple. Like 10.
Functional Torch: Okay.
Monadic Phoenix: 10 is enough. Yeah.
Functional Torch: Okay. So I'll just call it out. Okay. All right. So if this is what we want to do now, If I have 5 million 25 million days non free active users. 5 million daily active users, each user is playing 10 matches per day. So number of matches per day is 50 million. Also do we know the duration of each match or that is relevant? I was just trying to see like how many matches may be happening per second or you know, like in that dimension. So to be able to figure out like how many updates we would be expecting on the back end.
Monadic Phoenix: You mean the.
Functional Torch: Each player, you know, I mean players playing 10 matches per day. All right. So there's like 50 million matches happening through that day. Okay, yeah, yeah. I mean if it's. If it's happening throughout the day, then yeah, it doesn't matter. So yeah, yeah, right. I don't know why it went back to. I lost connection. I'm sorry, are you able to hear me?
Monadic Phoenix: Yeah, I can hear you.
Functional Torch: Oh, okay. Yeah, I kind of lost my connection here.
Monadic Phoenix: Are you able to hear me?
Functional Torch: Yes, now I'm fine. Okay, so if you look at, you know, so 50 million per day over, you know, 100,000 would mean. So 500, approximately 500 QPS. So you can say 500 matches per second. So are basically every. Because every match may potentially result in update for leader for the score. So basically 500 updates results are going to the back end system basis. Okay, so now for. So if it's a real time system, this. Yeah, so if it's a real time system. So this. If I were to draw some pieces in here so I would have my. This is my client which is displaying the leaderboard and I have my web server and this web server would be behind a. So what. Because I want real time update, my client will need to have a persistent sort of two way connection. So I could have something like a websocket open with the backend servers and a. So the. The server. The server that is the server that is. So this is like providing this backend service is like what is providing me. This is like a leader service. Right. On the other hand, and on the other hand I will have you know, match games happening. So there is this interface game client which is whenever a match happens it reports to the game server. I should call it like a result collector which will get the results from here and these results will then be these results. I mean the game client has to just send the results to the result collector and then it doesn't have to wait on the response. And then this result collector can potentially write to a. Not sure where is the. Yeah, write to some sort of a database for the results. And now because these are going to be fast updates. So I'm thinking that there will be some sort of. So yeah, let me. There may be some additional sort of system needed that will help with updating the leaderboard in real time because data database writes could be slow. So yeah, so what I would need is like this leadership leader service is going to read. Yeah, it's. Sorry, it's probably going. So I probably would need something like a broker.
Monadic Phoenix: We can keep it simple for MP1, right?
Functional Torch: Like yeah, yeah. Okay. Okay. So yeah, I mean it. What I'm thinking is that in real time, if we need to do updates, then this result collector should. So yeah, I mean at the very basic. This leadership service will read from this database, you know, update the scores that it has, you know, and it will keep some sort of cache which it will be like a result cache. And so this leader service will read from the result cache and if there's. Yeah. And updated. And then this if they. Sorry, excuse me. So how would. The client does not need to get the whole leaderboard all the time. What it can do is it can keep a cache on its side as well and the client can read from here. And because we are saying that there will be a.
Monadic Phoenix: Yeah. To keep it even simple. Like we can make an assumption that let's say if I am a user, I just joined a tournament and yeah, if I win, if I win the game. Right. Then then only like we need to do we need to update like my point. So that. Let's say my. If I get one point and if I am then my name should be on the leaderboard. So yeah, we can make it. To start with, we can make it as simple as that.
Functional Torch: Okay. Yeah. So yeah, so this result collector is going to write to the result store. The leader service read from the results store and the client. So for the user for which the game has just finished, client will fetch the score from the leader service and get. And you know, update the leaderboard and keep it in cache. And so that's how I will update the current user score now. Yeah. Does that, does this look okay?
Monadic Phoenix: Yeah, I think I. Yeah, it. Yeah, I think it looks good. So just if you can explain, like let's say if I as a user join the tournament then. And then if I score a point and if I go to the leaderboard, then where does that flow look like?
Functional Torch: Yeah, so. So I can type it out. So user place the game, replace the game. Then game client user plays and like you said, wins the game. Actually instagame game plan reports go to collector and result selector rights to the db. Now in this case the client will then reach out to the. So wait a second. So yeah, so the result collector will notify. Yeah, and that is one error that I missed. So result collector will notify the leader collector notifies either service of an update service post. You know, pushes the update to the current. Let me move it a little bit on the side and then. Yeah, this is. Yeah, this is how the interaction would be now. Okay. Yeah, yeah. Now, now if you want to have to like scale it. Sorry, I got something deleted. Okay, so now if you want to make this working for like you said, 5 million daily active users, this leader service will need to be, will need to be distributed in that there may be multiple instances of this leader service running. And yeah, so because the result character is directly pushing the updates to the leader service, you know what we. And because there may be 500 results going in per second, we will need some sort of a broker here which will, you know, queue in the results and pushing to the leader and that way the leader service can update its scores. And because we're using websockets, these clients will have dedicated connections to the servers. So we'll want to distribute the connections evenly. So we will need a load balancer in here which will keep, it will keep track of the, which will. Yeah, which will keep a mapping of the connection of the client and the backend server and you know, relay the traffic appropriately and result cache. Yeah, so if we're interested in like top 10 leaderboard, then result cache is something that definitely makes sense in that. And yeah, I mean maybe client doesn't even need to keep that cache in that this result cache will have the top 10 scores and you know, it will be updated only, you know, anytime there is an update that is resulting in know a change in the, in the leaderboard status. Right. So if a new player needs to be moved in or you know, any individual or among those top 10, there is a rank change, the cache can be updated quickly and then you know, and at the same time that result can be referenced back to the client whenever there is an update happening. So that way the leader service tool doesn't have to reach out to the database to you know, get to get the top end results. I'm still thinking if I need the client cache for now I'm going to take it out. So yeah, what else do I need here?
Monadic Phoenix: Right. Like if you want to talk about persistent. So what are the options and trade offs you are making for the persistence? What is the technology?
Functional Torch: Yeah, so in here the persistence it seems like you know, we are having around 500 matches per second. So potentially, potentially these many writes are happening in the database and then when we are, There are around 5 million daily active users which will be around. Yeah, I mean that these, so the reads are going to the equivalent here. So yeah. And the leader service also needs to like write the, the scores onto the database. So there is not a lot of, there's not, not a Lot of the, sorry, joins and, and relational database. Yeah, like there's not a lot of need of joins here. And because the results that we are supplying are directly happening through the leader service, we can keep a NoSQL database here which is just like a column store and it will have eventual consistency for the most part. So in my database I will have a. Of course I'll have a user table. So which will look like user id, name, score, rank. Right. And I mean for the scope of this problem, I don't think. Sorry, for the scope of this problem, I don't think I need anything. Any other table user ID would be. It's the partition key. So. And There are like 5 million daily active users, 25 million total active users. So we will definitely need to scale this database out into some form horizontally. We could do partitioning based on. So we could do partitioning based on just for this case, typically your leaderboard that the top players in the leaderboard will also be the ones who are playing more often. Right. So basically their updates may, may be happening more often than you know, other players. So like we could end up with some sort of, we could be, we could end up with hotspots if we are doing some random part is random partitioning. So I'm thinking and we could identify like we could start with just. We could start with yeah, random partitioning initially. But you know, like I said, we could end up with hotspots. So we could do sharding based on, you know, the more prominent players. So we could have you know, dedicated partitions for specific group of users who see more updates so that we are able to manage that load. So yeah, we'll need partition random. But aside from that, because this the users are distributed around the world. You know, we could also do you know, region based partitioning. So like you have few, you have a few different data centers in different regions in US like East 1, East 2, West 2 and then you know, some, some in China, some in Europe. So that way you can distribute the data and the updates based on the proximity. So that will. So yeah, maybe instead of random I could do location based partitioning. And on top of it. Yeah, like for hotspots, for hotspots, partition, repeat dedicated partition for top.
Monadic Phoenix: Okay.
Functional Torch: Yeah.
Monadic Phoenix: So one portion here is because this is going to be monthly, right? So how do you read? Like how do you keep track of that monthly dominance? Right. So because it's going to be monthly and let's say January comes January for end of January, there could be a different date Leader. Right. But as soon as the February start, new to now and started now. So how, how are you planning to keep track of that in your persistence?
Functional Torch: Yeah, that's a good question. Yeah, so I will. I would need to keep something like a. Okay, so in that case, I need to like each record need to be identified for each month. Like if the tournament is happening per month. Right. So, so yeah, I mean, we could say month and year. Year. Month and year would be there to keep track of that. Right. So that way for every user, I have the ranking on for that month and the year. Right. And. And so anytime there are updates happening, you know, I look up the user and so I will need a composite key instead of just the partition key on user id. So I'll need a composite key where, you know, it's the user ID plus the month and the year. So I only specifically update that. That row. Okay.
Monadic Phoenix: In that case, so what about like, would you hit the wall early? Like, how do you do the. Because now if you. I believe you will have only one document, right. In your. No SQL and everything, you'll dump there. So that's a lot of record in one document. Right. Like, so how do you do it? Like a sorting or how do you handle that? Like, because as soon as a new month will come in, most likely, like the older leaderboard or older record would not even be used. Right?
Functional Torch: Yeah.
Monadic Phoenix: How are you planning to do the.
Functional Torch: Yeah, yeah. So what we can do is. So that's a. Yeah, that's an interesting question. So if we want to. So if this, you know, if the leaderboard resets every month, which is what is expected here. Yes. The data from the previous month is going to be lost. Right. Is not going to be useful. But if we want to keep it for analytic purposes, we can, you know. But yeah, is that, Is that a requirement? Like, I didn't ask for it earlier, but is that something we want to deal with?
Monadic Phoenix: Yeah, most likely, as you said. Yeah, we want to keep it, but more as a passive. Right. Because I think we kind of agreed in the functional requirement that. Okay, it would be every month. Right. So as soon as February goes and when I go into the leaderboard. Yeah, the February month leaderboard should show up. Maybe there is a way, like, I think that's a good requirement. Like if I specifically go to the January leaderboard, maybe it will show it. But I think that is not something we agreed on that could be like a further mvp. But for now we are just focused on the current month. Yeah.
Functional Torch: Okay. Yeah. So I mean of course like the, when the month comes in, you know, the cache will need to be cleared out and all that. And from the user perspective, like if you're, if you're considering only like, you know, persisting this data for a month, you know, we could add a TTL to this, to each record. Right. So anything beyond 30 day. But yeah, actually we will need some sort of janitor which will clean up this data after a month. Like they can tombstone it after a month, but then again storage is not completely gone. Right. So I'm guessing that we're looking for something so we can optimize that storage that we want here. Right? Okay. Yeah. So if.
Monadic Phoenix: How about, have you think about like creating a new table, let's say in the SQL like a table every month, like as soon as a tournament starts, you create a new table. Like have you thought about that? What would be the trade off there versus this?
Functional Torch: Like creating a new table. Yeah, I mean creating then creating a new table. I mean we, we can very easily, you know, just, you know, say okay, we'll spin up a new cluster for, for this month and you know, the. Retire the, retire the previous cluster and then clean it up and then have it reused for future. Right. So that is there. But, but that's. So it is achievable. We will just need to be, you know, doing that provisioning beforehand. But, but if we do it that way then definitely it's not something that is going to like impact the current month's flow at all. It's just that, you know, for. So basically we will have to provision same amount of storage that we had for the current month, the next month. Right. And then as soon as the next one comes in, we, you know, change, move the linkage to the new, to the new table and you know, just retire the old table and you know, just you know, keep cycling these two clusters through. But if like in that case we don't even need to keep track of the month or year in the table itself because we are saying, okay, the month here is the table itself is like for a particular month. Unless we want to store this data for future, which is not MVP requirement.
Monadic Phoenix: Yeah, sounds good. I just want to pause here, I think add just a few more questions and then maybe we can end. Because the time is. We don't. I want to make sure that there is some time at the end for me to give you feedback. A few questions more on edge case. How do you handle like a tie? Let's say if there are two Users which has the same rank or point. Right. Like, so how do you handle that?
Functional Torch: I mean, break that. That is something that the leader service will have to like build, you know, the business logic on. Right. It could be a business rule around like who, like they could be, you know, players who are finishing the match sooner. Right. They are winning, but they are also like fast compared to other users. So the speed of, with which they finish the game. It could be a tiebreaker. Right. Another thing would be, which would require additional persistence and data would be, you know, look at their history, the user's history, like how, how often they have been on the leaderboard and what their rank has been. So we could, you know, relate their. Use the database data from their previous ranks from their previous tournaments as a tiebreaker for the current one. Another thing that we could do is. Yeah, or alternatively, right, we could assign, you know, same rank to multiple folks with the same score, which is also something that, that is very common.
Monadic Phoenix: Okay, yeah, sounds great. So if you were to design this like so in terms of cloud, what are the technology you would choose for this different component? Right, like for client game, client collector. Just at the high level. We can talk about that.
Functional Torch: Yeah. So this result collector is just, it's just a microservice here in the backend. This broker is like a message queue. So this would be something like Kafka where you know, just user collection pushes the notification. The broker then, you know, does notifications into this leader service. This leader service doesn't necessarily need to be, doesn't necessarily need to be microservice. It could be like a lambda function this broker is invoking every time there is an update. Then this lambda function, all it does is just updates the rank for that specific user. And then you know, connects, goes to, connects to. And then you know, pushes that result into the, into the database and the cache and, and then, you know, then that result will have to go back to the client. So this will be like a lambda.
Monadic Phoenix: So if it is a lambda, do you think there can be like a user experience? Can it delay it? Because I think we want no latency, right? Like.
Functional Torch: Yeah. So I mean, I am thinking of lambda for this one because it's going to be a lightweight thing, right? All it has to do is like wake up and you know, just update and then go away. I. I do not think there would be any. But yeah, the thing about. Yeah, the disadvantage of having a lambda would be, you know, not having a persistent connection with the client. So the real time may not be Always real time. So I. I get your point. So maybe not.
Monadic Phoenix: Yeah.
Functional Torch: Yeah. So this will be just. In, in that case it will be something like a microservice, you know, the back end microservice. And it's also be a microservice. And then like I said, this will be no SQL database. So I'm thinking like Cassandra here.
Monadic Phoenix: Any particular reason you chose Cassandra here?
Functional Torch: Not necessarily. I mean, it's not really because here we are only just, you know, doing updates on the score and rank for a particular username for that month. There's not really any additional requirement, but because there are updates happening very often. So that's why I chose like the column family store versus.
Monadic Phoenix: Okay.
Functional Torch: Makes it object store or you know, document store. So. Yep, now for the cache, it is again going to be a lightweight cache. It only just a second. If I were to write this cache. Yeah, I, I don't think we need like a. It's just a in memory cache. So not.
Monadic Phoenix: Will that be sorted like. Or what kind of data structure are you planning to use in the cache?
Functional Torch: Yeah, it. If we are just using keeping top 10, then that task can be done by client as well. So this cache could be just a key value store. Doesn't need to be sorted here. The client can sort it. That's what I'm thinking. Update the keyboard.
Monadic Phoenix: What about the user? Right. Like if I'm the user, I go there, I'm not in the top 10. I think one of the requirements you mentioned was we would show that. Right. So how do you have that?
Functional Torch: So, yeah, so that, that is something I touched on previously. Like, so when the broker notifies the leader service of the. Excuse me. Of the result, it is going to. It is going to notify the client of the update and then at the same time it is going to update the rank in Cassandra. So the client can build the leaderboard with current place rank. How the rank is updated? Yeah, let me think. Okay, I know we're running out of time.
Monadic Phoenix: Yeah, Yeah, I think that's a. Something that you can take away and see. Like. Because I think you want to show that for every user. Right? Like how do you. I think in your cache you cannot have it for every user. So now.
Functional Torch: Yeah, it's not something you can have the cache. Yes.
Monadic Phoenix: Yeah. So maybe that's a takeaway for you. But let's, let's end it here. We have a few more minutes and then I can give you feedback and then if you have any questions you can ask me. All right? Okay. I think, I think it went well. I can definitely see that you have experience with designing end to end systems and you are able to clearly put the ambiguous requirement that I just like a one liner ambiguous requirement I gave you and you are able to clarify that turn it into deliverables there. I can see that you have that experience. And then we went through some non functional requirements there as well, which is great. We make some assumptions there which we put there I think which is great. And then we went into designing basically starting from smaller one and then you iteratively build on that, which I like. And then I think the solution is also scalable with microservices and load balancer and deploying this in the cloud and with no SQL it can scale originally as well. We covered the partition sorting and stuff like that. More for scalability and then for low latency mentioned about the gas and then using the right data structure there maybe a set or something which could be more. Yeah, low latency I think makes sense. So in overall. Yeah. I feel like you have the experience to take an ambiguous problem, design this, put the solution there and then break it down so that less experienced engineers can take it and work on it. So I see that there a few feedback I had was. Is. Yeah, I think the data like we could have spent a little bit more on the API itself. Like I think that's. That's one thing.
Functional Torch: Oh yeah, yeah, yeah. What is the API right? Like data.
Monadic Phoenix: I think data simple. Like didn't want to go into more into like all the nitty gritty but at least the API.
Functional Torch: Yeah, that was great.
Monadic Phoenix: And then in the storage I think I was not clear what is the technology we are using here. You mentioned about database there earlier. I thought it's SQL itself like the RDBMS. Then I think we kind of people are there to use no SQL which is great. But I think it is good to just spell that out explicitly so that the interviewer and you are on the same page. I think. Yeah.
Functional Torch: Yeah.
Monadic Phoenix: I think those are my feedback I have. Otherwise I feel it went well. Maybe a little bit more into cast. Like what exactly did I structure? Because if we are talking about redis here I think there are few data structure like sorted set and things like that.
Functional Torch: Yeah.
Monadic Phoenix: Even more better this design. Yeah. So yeah, I think in overall I feel like you. You did quite well.
Functional Torch: Okay. May I ask a couple of questions?
Monadic Phoenix: Yeah, sure.
Functional Torch: Do you have any. Anything on the pacing of the design? Like was I going too fast, was I talking too slow or anything that I Could change in that.
Monadic Phoenix: I think the pacing, maybe you can like a little bit like you can, you, you can go a little faster because of the time. Right. Like right now we are spending almost an hour, but in real interviews I think it's 45 minutes. And then even that 45 or 15 minutes there would be. Actually you would have only 30 minutes to talk about this, what we covered here in almost 50 minutes. So yeah, the pace is also something. That's a good point. You can, you can increase your pace a little bit and also talk about a trade off also. That's also another thing I mentioned. Like I think as Prince at the principal level, start plus level, they expect you to not just give you a solution, but also like the options and the trade off. Right. Like why you are picking SQL versus no SQL or even in no SQL, what certain technology. I think that's the expectation, especially at this higher staff plus level.
Functional Torch: Yeah, okay. Yeah, that definitely makes sense. So yeah, little bit more on the base. So do you think I spent too much time in the requirements or.
Monadic Phoenix: No, I think the requirement was. I think it pretty much covered in I guess like 20 minutes. But I think the diagram is. That's where a little bit more time. Yeah, yeah.
Functional Torch: Okay.
Monadic Phoenix: I think, I think, I think the diagram is somewhere you can save some like somewhere between five minutes, five to seven minutes, I feel like. Okay, yeah.
Functional Torch: Okay. And then when you say you know about storage, what is like a good time to go deep into the storage? Like I know we touched more into the later part. Right. And was that the right time or should, should I be like focusing on the storage in the initial design itself before scaling it up and all?
Monadic Phoenix: Yeah, I think it really depends upon the interviewer as well as the question. Right. Like in this example, yeah, storage is one of the important component. So after you go through more like a high level and you kind of agreed with the interviewer that you are on the same page with the high level design, like how many services, what is the API and stuff like that, then I, I would expect to go deeper into stories like, okay, what is the trade off between these two and then why you are picking one versus the other. But it really depends upon the question and the interviewer. Because it depends upon the question like what is the important part? Right. And also what the interviewer is interested to know and what their expertise is in so that part. So you just have to think out, like think out loud and then first like a first pass, you, you agreed on the high level design with the interviewer. And after that you kind of like. Yeah, you can ask like if there's no specific arcs from the interviewer, you can ask like, okay, which part do you want? Do you want me to go deeper into? Right. Because that's one of the expectations at this level from the design is to go deeper into one of the components, at least one, if not two days time. Yeah.
Functional Torch: Okay. Okay. Yeah, that is definitely great feedback and yeah, I will keep that in mind. I still have few more days before the interview. I will try to do more practice interviews so I can, you know, pace myself. Any other, any other tips that you would like me to focus on with respect to principal level, system design? Interview we discussed around, you know, going a little bit deeper into API level, storage level, talking about trade offs. Is there anything else that is expected from.
Monadic Phoenix: Yeah, I think the scaling is what they, what most of the big tech companies are looking for, including Microsoft. If you are building something inside the company, usually that's the difference between like other companies and big tech companies. They are looking for a more scalable solution. Right. So making sure that it can scale it to that level, like is important. So horizontal scaling, using the right data structure. Yeah. Geographical redundancy, those things are important. And using the right technology to enable that.
Functional Torch: Okay.
Monadic Phoenix: Yeah, I think that's one of the different.
Functional Torch: Yeah. And do you think I was okay in that direction with respect to scaling and technology? Yeah, I understand. Like, I definitely would need to discuss more with respect to choices and trade offs. Is there any.
Monadic Phoenix: No, I think, I think you have, Yeah, I think you, you have that experience of taking ambiguous problem and coming up with the right scalable solution. I think just as we discussed, the space, the pace and then the more about the trade off and then the scaling part. Yeah, I think you should do good. Yeah.
Functional Torch: Okay. All right. Thank you so much for your time. I really appreciate all the feedback. This was very valuable and helpful for me.
Monadic Phoenix: No problem. Yeah. All right, Best of luck to you.
Functional Torch: Yeah, thank you so much.
Monadic Phoenix: Enjoy rest of your day. Yeah, bye.

We know exactly what to do and say to get the company, title, and salary you want.

Interview prep and job hunting are chaos and pain. We can help. Really.