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

An Interview with an Amazon engineer

Watch someone solve the calendar system problem in an interview with an Amazon engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Calendar System

Interview question

Design a Calendar System for 100 Million Users

Interview Feedback

Feedback about The Mighty Platypus (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

3/4

How was their problem solving ability?

3/4

What about their communication ability?

3/4

1. Slightly Towards hiring. 2. Can improve on functional requirements. 3. Can do better job in overall design. 4. Needs more practice. 5. Talk about operational excellence towards the end of the system.

Feedback about Phantom Dictaphone (the interviewer)

Would you want to work with this person?

Yes

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

The Mighty Platypus: I'm a software engineer. I have about 12 years experience, something like that. It's hard to say exactly how many years because I started when I was very young. But yeah, so I'm targeting like level 5, level 5, level 6. We'll see what type of leveling actually makes sense at Amazon. Facebook's in the mix. Google's not hiring right now. But if I could, I would be applying and doing that over there. And yeah, that's, that's a. That's about it.

Phantom Dictaphone: So there has, so there is a big difference between hiring bar for L6 and L5. So I want to be very like, I want to understand, like, for example, at Amazon, are you going for L6 or L5 FD2.

The Mighty Platypus: So that would be now five. Okay. Okay, cool.

Phantom Dictaphone: Quick intro about myself. So I am presently a G3 at Amazon, have around 11 years of work experience and I've been with Amazon for almost six, more than six years now and have taken close to like 200 interviews in Amazon.

The Mighty Platypus: So.

Phantom Dictaphone: So yeah, that's about me.

The Mighty Platypus: Yeah. Are you a. Sometimes I have stats on it. Are you, are you lenient? Are you hard? Like, what's your. What's your.

Phantom Dictaphone: I am, I will not call. Call myself as hard. I'm like, pretty much what I have realized. Like, I'm just at the bar basically. Like, if I basically judge someone as like that, okay, not hire, the chances of that person actually hiring is 99%. No. And I mean whatever I have seen in my interviews is like probably the decision is basically the same. There was one or two instances where like I've seen like I did graded someone else, something else and the person like person was hired or not hired.

The Mighty Platypus: Okay. Okay. Interesting. Yeah. So.

Phantom Dictaphone: I'm not lenient. I'm not super hard. I'm just.

The Mighty Platypus: Okay, okay. It's an okay place to be. Yeah.

Phantom Dictaphone: Cool. Let's get started. So this is a system design interview. Correct.

The Mighty Platypus: Yep.

Phantom Dictaphone: What we want to do is I believe like everyone has used calendar systems. Correct. Like you must be using it in your company. You must have used Google Calendar. And so many different. We use calendar systems. One of the things that we do on calendar is basically create meetings.

The Mighty Platypus: Correct? Yeah.

Phantom Dictaphone: So what we want to do is we want to. So consider the calendar is given to you. You want to basically add a functionality for event management which is basically meeting creation, meeting, like all the, all the things related to meetings.

The Mighty Platypus: Okay. Okay. So events, so calendar system. Right. And so we're going to go through functional, non functional requirements here. So here we go, functional requirements here. A we're going to say create event is probably one of them that I'm thinking of. Let's. Because you explicitly stated that creating an event in this process. How are you thinking about the, the event creation process? Are we actually doing anything special? Is it just going on someone's calendar or are we like making sure. Doing any validation of any type where that overlaps another like event and we can't schedule it or what are your thoughts there?

Phantom Dictaphone: We can schedule it. Nothing like that. I mean like even in your calendar, like if someone is busy, let it be busy. Like you, you still want to like you still want to send out an invitation, Correct?

The Mighty Platypus: Okay, so let's say. Yeah, you mentioned invitation invitations as well. So when I create an event, do I'm assuming I can create an event for somebody else as well. So essentially like create an event for user and then user ID and then also for. There's gonna be like a time start.

Phantom Dictaphone: So what do you mean by create an event for a different user? I mean like you can create an event and you can invite people for the invite people like you cannot.

The Mighty Platypus: There we go. Yeah. Okay, so invite invite to event and then this. Let's see. Basically when I create an event, it gives me back an event ID here. And then when I want to invite to an event, then I provide it an event ID in order to add that person to that event. So then user ID and then there's going to be some, some APIs in order to register what event this person is registered to. So get events and then that's going to be like user id. There's also going to be like how do we feel about authentication here?

Phantom Dictaphone: Because don't worry about the authentication. One of the requirement that I think is important over here is on the calendar system, if I want to see my all the events for today or all the events for a week, I should be able to see It.

The Mighty Platypus: Okay. Or yeah. So even for a month. Yep. So start time and then end time are going to be inputs then. And then the result back is going to be like an array of event IDs and then maybe the metadata that's associated to the event ID as well. So that would be like event IDs along with. So event ID here, let me make this an object and then that object here, like start time and time. So yeah, this is, this is good. I can see where.

Phantom Dictaphone: I mean like someone should get a notification, correct? Like the meeting.

The Mighty Platypus: Yep. We can have like a notification system as well. I'm thinking like, you could, you could have like a notification system that this notification essentially like has to get events. And then when, when the events are.

Phantom Dictaphone: Like, you can decide on it. I mean, like, you can decide on the design later. But like we need to have a notification system.

The Mighty Platypus: Yeah. Okay. So notification system. I'll add that as a note here. So, notes, notification system. Let's go over like scale of this thing because if we're recruiting an event system and it's for everybody, so let's assume half of the world's population is actively using this calendar system. So it's like 5 billion people.

Phantom Dictaphone: Such a high number. Let's assume like all together right now is 100 million user. And 100 million users have already registered. But it is a growing system.

The Mighty Platypus: Okay, so 100 million users. And then let's say, you know, 10% of these people actually create events on a daily basis. So that's going to be like 10 million users. And these 10 million users, maybe each, each item here is going to be its own like level of scale. So like creating an event I think is going to be significant. So we should do like a back of the envelope, like conversion here or get events. I'm going to give you daily active users. So it's around 10 million daily active users.

Phantom Dictaphone: And then.

The Mighty Platypus: Let'S say people are creating like 10 events a day, let's say. I think that's reasonable considering a lot of people use it on their daily function to create meetings and such like that. I think things are going to grow with that. So yeah, let's say 10. So 100 million events a day. And so 100 million. So 10 million DAU. And then 100 million events. And let's calculate the queries per second on that. So queries per second would be like 100 million events divided by the amount of seconds a day. So 100 million. Let's do seconds in a day.

Phantom Dictaphone: Seconds in a day.

The Mighty Platypus: It's about 100,000. So 100 million divided by 100K is. It's about a thousand.

Phantom Dictaphone: One thousand. Okay.

The Mighty Platypus: QPS. And that's, that's pretty significant I would say. We're doing like throughput analysis here. So that's our throughput. We could also deal with the scale of the database as well. So if it's 100 million events. 100 million events, you have to store the user ID time start and time end. And then probably as well if it's like if it's been accepted or not. So boolean there, it's pretty negligible. But I think I should call that out because if you invite to an event then you're assuming that that person needs to accept or decline it. So I create user ID. Let's say like 8 bits for the user ID, 8 bits for time start and time end. So 8 times 8 times 8, you're looking at 64 times 8. So let me do that real quick. So it's 512 and then 512 times we had 100 million events throughout the day. So it's. And then 100 million, 100 million. Let's see, we have kilo mega kilos. A thousand mega is around a million. So you are looking at like a half a gigabyte a day. So one half of a gigabyte a day. Let's multiply that to like 365. So it's, it's pretty, pretty large. I'd say three. You're looking at petabyte scale over like a few years of it in action. So it definitely warrants like sharding and things like that. So when we go into non functional requirements, which I believe that we should venture into, that we have partitioning which means we have to choose between consistency and availability and just experience. So questions for you. I mean like how do we feel about eventual consistency here? Because I'd imagine like, like, like you said these, these things, it's okay if the user like accepts an event after the fact, but it's, it's okay to load up. It's more important that they know what events they have. Right. Rather than having every single item on that event accepted and unaccepted and just like readily available for you. So yeah. How do we feel about looking at consistency over or sorry, availability over consistency.

Phantom Dictaphone: I think consistency is more important over here. Is it?

The Mighty Platypus: Okay, cool. So we were more concerned about what, what events.

Phantom Dictaphone: But I want to, I want to still give you right over here and you tell me, you tell Me one thing. Like the important thing that I want to know is like consistency is important when you are saying availability. Like are you. So if you are dialing down or like maybe like not thinking about availability a lot, how much, how much are you thinking about? Like what's the sacrifice that you are trying to do?

The Mighty Platypus: Yeah, yeah. So the sacrifice that I'm trying to do here is I'm trying to get the output here. So, so this 1000 qps below like a 200 millisecond load time for like a calendar.

Phantom Dictaphone: Why do you need 200?

The Mighty Platypus: Because that's around how long it takes to load up a webpage. And I do need.

Phantom Dictaphone: Sorry, where do you need a web page of this one?

The Mighty Platypus: Good question. I'm thinking when a user wants to get their events and actually like looks at what events are happening for them.

Phantom Dictaphone: Is like most of the time people, let's assume like not just web page but people do it on like let's assume that you have like a. What do you call Outlook or something like that.

The Mighty Platypus: Mm. Okay. Okay. So. So we could do a few different things here. Yeah, if it's on Outlook then even.

Phantom Dictaphone: In webpage you can do a lot of other things to make it faster.

The Mighty Platypus: Yeah, yeah, you can cache things and things like that. I'm just thinking because then it would take longer for the cache to be refreshed. So we are sacrificing things like.

Phantom Dictaphone: But, but, but what I'm trying to understand is 200 milliseconds super important versus the availability.

The Mighty Platypus: Yeah, it's the, the, the availability is probably the, the 200 milliseconds. Right. It needs to be readily available in order to grab that. The consistency is if that data is correct. And so that's, that's kind of where my head is at the. I guess consistency is like if an event changed for some reason you. You'd want that change to show up pretty immediately on the front end instead of the, the other way around. So there's the trade off. Right. You have to. Would you rather it take a little while for the page to load right when you want that change or do you want it to not take a long time to load and then just have it readily available for the events that are there? So okay, yeah, I think so Maybe let's go back and say that availability is more. Or sorry, consistency is more important because of like we need to make sure that these events are actually correct and with the right updates. So yeah, what I'm thinking is like.

Phantom Dictaphone: Just want to give you this feedback that in actual interviews, these decision is led by the interviewee, not by the interviewer. So generally like in actual interview I will probably probably say you decide.

The Mighty Platypus: Okay, interesting. Yeah, yeah, definitely a trade off because you know, like it's. If you're. If you want to get your events as compared to get your events quickly as compared to like having a correct set of events, like there has to be a good balance point because you don't want to wait two days for your data, but you want it pretty soon. So maybe let's go through the high level design here and then these things will kind of be flushed out as we go through it. We can still have some solutions for different systems because getting the events may be a completely different system or like approach than if we were to upload events. So I think it's overall just gonna come out. So. Okay, we have over here the. And I'm not completely used to this system.

Phantom Dictaphone: That's the toggle whiteboard. So if you go to toggle whiteboard you. Oh, you are already there.

The Mighty Platypus: Okay. Yep, got it. Yeah. So users are here, right? And then these users interact with our APIs and let me actually grab all of our functional non functional requirements here. Oh nice. Okay. So that, that we can reference them and just use them at different level. Interesting. Okay, so users are here and then what, what ends up happening is we want to interact with a load balancer in order to get all of our user data. So I'm going to start with the get events here first. So the get events flow because I think it'll become clear what's actually happening. So here and then we have this load balancer here. This gives us the ability to scale pretty well and then the users then get it from our data store. So a lot of different options for your data store. I would say like what's probably a better option is something that, that gives that high availability so when it's updated it's actually updated correctly. So or sorry, high consistency so it's actually getting from the correct source. So what I'm thinking of here is probably, I want to say a relational store because we're going to have all of the different events that need to be queried with different time zones. Relational stores are really good at pre indexing all that Data. So like MySQL and things like that load balancer and then this hits our actual like our database actually like it's going to be our server because our server is going to want to do some, some extra stuff like authentication and whatnot and like that just kind of you need that layer between the two. There might be like some caching that we want to do here as well or like some queuing. But yeah, maybe not so much with the get endpoint. Maybe if we want to do like a priority based system where we have a hotspot or something like that, then the server's more important. So the server over here. So here's our database layer. So it's a relational database store. And then the relational database, we can actually go over the schema rather quickly. So I'm going to do that. So we have.

Phantom Dictaphone: Why did you decide on relational database?

The Mighty Platypus: Just because of the available or the consistency aspect of it? Because we wanted this to be a reliable system and have the reliably get the data as it's being updated instead of a quick system. So if I was getting a consistent data set, then I'd have a key value store because that key value is just o of 1 and then it's readily available. And right there consistency is a little bit different. Where you want to say all right, hey, give me all of the data, give me the data that's for this time range and giving me it most up to date instead of it like being not up to date. So that's. And also a relational data database is good at storing time series data because this, this is very much so time dependent. You have time start and time end. So getting the, getting the events that are like starting at this time and ending before this time for these users and then it brings back a set of data. So relational database, it separates it out so you can actually separate like a, you're going to have like a table of user IDs and then you have a table in order like true normalized fashion, user IDs and then user events. And then you have like time start, time end for the user events and you're going to pre index that other table, not the user IDs but the events table so that when you query it with like time start A timestart B it actually grabs it correctly. And there are other optimization techniques that you can do for that database that gets you even closer to the time series sets. There's new technologies that are coming out as well because there's some cool stuff. So yeah, let's do that, let's do like user id. This is one of the tables, user id. And then like I'm going to do the event ID over here and also what I'm going to do here, I'm going to label this users do you.

Phantom Dictaphone: Want to do a separate, like not here probably like, like database design. I want to go deep dive into the database design.

The Mighty Platypus: Yeah, definitely. So like that's kind of what I'm doing over here. The, I'm creating the tables over here. So this, this entity over here is actually the, like this is our database, so relational database store. And I want to do a here we are so database, so user events. And then we have event id, User id. And then over here I'm gonna recreate this over here. And then I'm going to say like event ID and then time start. And so this is, this is important because if, when we separate the two, then we can do like a really great indexing technique to like sort or index at some point. There's complex indexing algorithms that we can plug into. But I think sorting is just fine because once we find the start date that we're looking for, we basically iterate to the time end for these event IDs. So we join these two tables and then we actually do the actual events. And this is great. This also prevents some duplication because we know we have user IDs that could be associated to many events. And so it's important that we normalize.

Phantom Dictaphone: Can you tell me one thing when you say user events? So this is what exactly it is? This is the user ID and each event for that particular user id.

The Mighty Platypus: Yes. Yeah. So this user ID and then the event ID for that user id. There's also another table here that I should call out which would be like, just like users, the users table. So this would be like user ID and then like first name. So like their meta metadata attached to it. So like this is your user table. So all three of these would be joined if you wanted to get back that data. It is, it is important I think like this is going to be interesting here because most of the work here is going to be indexing this events table, making sure that these are sorted and when we replicate all of this data, because it is high volume that we need this to do. So partitioning, we could probably partition by the time start and time end or something of the sort. But we're going to need to plug this into some consistent hashing because that's also an issue that does come up. So you could do it on some more consistent and store hash outside of this that hashes a time start and time end so that it's evenly distributed across all of these things. But I'm going to say that could be a whole nother diagram in of itself. And I think what we'll do here is, I just want to call that out. That could be an issue. Now this is our get events, our get events flow. And then we can label some of these. We need to have another whole entire flow for actually storing these events. So when a user comes in over here and actually that is what that label is going to be. Let's do another flow for not get events. But this is going to be create events. So create events that's going to go through a load balancer as well. So pretty, pretty similar, maybe even the same load balancer, but for like I just want to kind of call out that it's a different flow. And then here's the server itself that it goes through. And then this server here, it actually uploads to the events database the event id time start and time end and then also event uploads to the user events table. So yeah, I'm thinking about the hashing here and why it would be important. I think user id, if it's like a UUID that's just like auto generated randomly so it prevents collisions and things like that, I think we could partition pretty well by user id. It gives us some consistent hashing. As I was thinking about it, if we do have a user ID for whatever reason that has millions of events, like let's say a promoter, then that could be an issue. But I kind of, I think we're okay there because we're if, if a user has like a thousand events hotspot and maybe we have like a mapreduce algorithm or something of the sort. But yeah, so create events down here. So this, this grabs a bunch of different data. So maybe a little bit different. This is our time start and time end invite to event event ID and user id. If I create an event which is down here, I'm basically sending through the user ID and event id. No, it passes back the event ID back to this system because we're creating it. So this user created this event ID and then this event. So this actually may need a different table that's like an invites table which changes our design a little bit. So we just have a different table altogether. Because these user events here, this user ID created this event ID and this user user ID has this meta. Now we have another table that access, kind of like a taxonomy table where it says this user ID was event in invited to this event id. So kind of like user, can you.

Phantom Dictaphone: Can you not get it from somewhere? I mean like from the data that you already have?

The Mighty Platypus: Yeah, I mean, good question. We could replicate it. So every single time we create an event, we say that these users here are invited to event id, so basically saves it. And then maybe we, we have an extra field here, like is created or has been created, so you know who owns that event. Okay.

Phantom Dictaphone: Okay, tell me one thing. The owner information, like the creator of the event, event id, in which table it should lie in user events or.

The Mighty Platypus: Somewhere else it should be its own table. Because that table, it would prevent duplication because not every single user ID actually created that event.

Phantom Dictaphone: Can you define that table, what that table will look like?

The Mighty Platypus: Yeah, definitely. Events. What we call this, like event creator creator table. And then like it would be over here and then it would be this user id and I think that's it. So over in the event id, so very similar to the user events here.

Phantom Dictaphone: Why can't you put it in events table?

The Mighty Platypus: You can, but here, like, you could add another field here. You could say like event ID and.

Phantom Dictaphone: Then like, not here. I'm talking about this one.

The Mighty Platypus: Oh, okay. You could also add it here. Yeah. And then the denormalizing. Or it would be also normalized. I was just thinking that it might be simpler to like divide out the tables if you're doing a different indexing algorithm, just to like kind of show.

Phantom Dictaphone: But, but, but, but you can, I mean, like. Okay, tell me one thing. If you have multiple indexes on a table, is it a bad thing?

The Mighty Platypus: No, it's not. It's, it's actually fine. It does separate it anyway. Yeah. So I think we're okay, like created user ID or like, like owner ID actually is what we would say. So owner ID and then we should be good to go because that's, that's normalized already. So if we wanted a query like for this, this who, what user ID and for what event ID for that owner id, then we could query that out and then it would basically give us the events that are owned by that owner ID and the time start and time end. Let's see, we have our get events flow. We have a create event here. Get events. Actually, it's the same flow over here. There's nothing different that we're actually doing.

Phantom Dictaphone: Okay. So in the interest of time, it seems to me like most of the things will work. Tell me how a notification will work.

The Mighty Platypus: Yeah, so a notification would work as a, basically a cron job. So a whole entire service over here would just exist. So this would be like the notification service, and this notification service would like run a job every, every so often. And what we could do is as well as like replicate the, the actual processes here. So like it would distribute out like at scale because we have like 100,000 events. And we would say like daily notification job tier would run and this would be either its own service or it would be like fanned out to different servers. So you'd have just a bunch of them and then it would just run like either some SQL or some type of logic in order to grow, grab what we need from the database. And since this is partitioned in a way where all the user IDs are partitioning the whole entire system, we should be okay. Although I think partitioning it by time start would give us some more efficiencies. But I think it's okay because it would distribute it pretty evenly across the whole entire system. So this daily notification job here would just have a bunch of updates there. And then this notification service most likely would be. There are many different types of notifications that you could do. And so you'd have a different system supporting each. Like if you're doing push notifications, for instance, usually that's an outside service that you'd have to make like a rest call to. Or if it's an internal service, it could just be like a flag in the database that set. So it really depends on what you have. I'm making the assumption that.

Phantom Dictaphone: Let'S do one thing. Let's zoom into notification service and let's assume that you are going to send an email.

The Mighty Platypus: Oh good. Yeah, that's great. So if it's an email job, then that's that email function. So it would, you know, we're actually writing the program now to actually do that because I think it's important to outline what type of call is asynchronous and what type of call is synchronous in nature. So like the first step would be like get the data. So like query, query for events 1 day, day before event. So this takes time. And this would be a synchronous operation. And then the second one was like.

Phantom Dictaphone: Let'S say I want to send notification 15 minutes prior to the meeting.

The Mighty Platypus: Okay, so let's say 15 minutes, 15 minutes before event. So this, this job here would have to be like distributable. So it would be 15 jobs, 15 minutes before event. And then you'd say like, you know, like limit 15 for users before event for users. And then this, users here you could actually distribute with.

Phantom Dictaphone: Let me ask you this question. So is it a cron job or is it like Cron, what's. Can you tell me first of all, the frequency of the cron job.

The Mighty Platypus: Yes. Yeah, so the frequency, the cron job would be pretty much every. It wouldn't be every 15 minutes. You have to do it consistently. So like every. Every minute or so. So. And then I'm gonna relabel this. This is going to be cron job every minute. Okay.

Phantom Dictaphone: Let'S say you run a cron job and you did a query for a query for events that are in next 15 minutes. And let's say the query takes longer than two minutes, three minutes than what?

The Mighty Platypus: Yeah, then that's a problem because. And the reason why I wanted to kind of break apart the logic here is because the users at the query really should be hyper optimized for that situation. So, like in this range of IDs, right, so you're only querying for like user ID between A and Z. And then this is distributed into like 1000x or however many jobs that it actually takes to execute all of those queries for all of those user IDs. So it is optimized so that the query itself takes very little time. And since we're partitioned over here on user id, we should be good to go.

Phantom Dictaphone: And then are you going to, are you going to do. So you are partitioning on user ID and your index is on.

The Mighty Platypus: Yes. So I'm partitioning on user ID and then there's an index on time start and time end. Because we do want to make sure that everything these are ordered in a way that you can actually grab that data. So it's a little bit weird, but I do think it does make sense to partition by user ID and then do the indexing by time start and time end. Because we're making some assumptions as well that a user ID has a finite amount of events. We could do a back of the envelope conversion on that to say that someone has 365 times 10 events a year and we're never really querying outside of that range, so we should be okay. And then that is enough to fit in memory so that we don't have to partition again based off of the user ID and the time start time end of their event, if that makes sense. Like we should be able to index within the machine itself and not have to worry about like indexing overall. Is that okay?

Phantom Dictaphone: Yeah, it's okay.

The Mighty Platypus: Yeah.

Phantom Dictaphone: Let's continue.

The Mighty Platypus: Okay. All right, cool. So cron job every minute. Query events every minute for 15 minutes before the events and range ID range of user ID and then this is really important like user ID. Like I don't know how I would like write this out, but basically I would say like start ID and then end ID and then this would fan it out. Then we push it to a queue. So this queue is important for the nuxt system to really do its work because sending out an email, that takes time and you want to basically this queuing service, you want to grab it pretty immediately. So I'm thinking something like Kafka or like Kinesis or something of the sort in order to take those and push them out. So push the queue, queue's over here. And then this would be like our email service that then would be on top of this queue. And this is important as well because this email email service actually has like it like is it fans out and fans down every single like time that it's needed. So if the queue grows past a certain level then you know you're going to need more email servers. So you could replicate and start really doing more with that, start grabbing more from that queue. So it gives, that gives a little bit of buffer between the two. This is where it gets interesting as well. Email service is quite complex because it's based off of your Internet service provider. And once you start making those requests out to email, there's a lot of logic that goes into it, like bouncing. What type of behavior is actually done there with bouncing? So you want to retry it a few times if you're handling all that logic and you're not actually sending it out to another email service like Google. So it depends on how much of that logic you want to handle. I could assume that it would get very expensive as well if you just offloaded all of that logic to a random service writer, like let's say, I don't know, Salesforce Marketing Cloud, for instance, that could handle all of your email sends. But like, you know, there's other competitors as well. So if you handle it in house, you could save on costs at scale. But so you know, it depends on what, what management and what we're, we're looking to optimize here. But I could, I could tell you that it gets kind of complicated real quickly and you don't want that to stop your jobs from executing because as you said, like if this fails for a minute, then you just lost all the notifications for the people. So yeah, that's, that's what I'm thinking here. What are your thoughts like? So I'm talking about trade offs.

Phantom Dictaphone: Yeah, I can, I can, I think like we are almost at time. Let me focus on the feedback and then we'll go from there. Sounds good.

The Mighty Platypus: Yes, please. Would love that.

Phantom Dictaphone: I think you are there. Okay. But still there are few things that should be improved for a L5 engineer. I would have probably said like not very conclusive. Like I will be. I will say that positive to higher but not slightly positive to higher. So we have something called like we have spectrum where basically we say not able to make a decision. Then we say slightly able to hire and strong higher. And then we on the other side we have spectrum which is not hiring. And so probably I would have said somewhere between not able to make a decision and so I will say leaning towards hiring. Okay. The reason, the reason I will say is you know the concept, you did it well. I think while gathering functional requirements, you were okay. I think you can do a better.

The Mighty Platypus: Job.

Phantom Dictaphone: Requirement over there. Also you were okay. I mean like actually non functional requirement. You did a better job than functional requirement. Then the second thing that I felt was missing was like specifically calling out These are the APIs you want to create. You kind of did it in functional requirement, but I mean like you kind of mixed it. So that's basically like little bit of can be little bit of concern for someone that okay, you. You think it in that direction. But I think it can be okay. It cannot be okay. So again that's what I'm calling out. Like there are some few points that you can improve on. Okay. Third thing is actually your database design was good. I. I was thinking like you might mess up on one or two things, but you handled it well. But you needed some guidance over here. So I think whenever you get a guidance from your interviewer in your system design, it is actually considered a little negative.

The Mighty Platypus: Ah, okay. Yeah.

Phantom Dictaphone: Overall you. You basically like for the CRUD operation create events and all you were on the correct. From the notification service, you were again on the correct track. But you could have done better job. So basically like cron job. Every minute makes sense. Every 15 minutes. Like for just for 15 minutes. Next 15 minutes, not sure. Maybe you. You just grab it for next 30 minutes and put it in the queue. And email service generally basically have functionality where you can say okay, send it at this time. That can be done. Other things that can could have been done. Like when I told you email service, there are multiple steps in email. While creating an email, finding out the eligibility, then creating the content, then actually sending, sending out the things. This could have been divided into three different sections. One queue, another server, just for creation of a email template. Another. Another queue, then another server. Just the email that will help in fault tolerance. Then third thing is about maintenance. Like we did not discuss anything about maintenance. How will you basically do operational load? What are the things that you need to worry about? What are the business metrics that probably you will worry about? What are the system metrics that you will worry about? So talk about all those monitoring.

The Mighty Platypus: Yep. So.

Phantom Dictaphone: So I will tell you what what happens is like specifically in Google, Amazon, Facebook meta interviews versus compared to like what is actually available outside. I'm not sure if you are already in one of the faangs, but what I have realized previously that like you go online, you do groking the system design or any of the books, but it does not tell you exactly what is needed for like L5, L6 interviews for system design. Yeah, for L5 you can get pass. But not for L6. That's a. That's a problem that I have seen. So you. You need to put in little extra every single time like talk about operation load. So just to tell. Tell the fact that you are not just thinking about at this moment, you are thinking about long term.

The Mighty Platypus: Okay. Okay.

Phantom Dictaphone: But again I think if you do couple of more practices. Practice sessions. Also one more thing you need to be. You were little over time. Generally you get around 40 minutes for system design.

The Mighty Platypus: Okay.

Phantom Dictaphone: We almost spend like 50 minutes.

The Mighty Platypus: Yeah, yeah, yeah. Okay.

Phantom Dictaphone: Okay. So you need to be aware about your time.

The Mighty Platypus: But no, I appreciate it. Yeah.

Phantom Dictaphone: Decent job. I think like. Yeah, as I told you like this will be more of a leaning towards higher. So.

The Mighty Platypus: Okay, so question for you on the functional then. So I had some struggles with it. So of course I think you definitely caught on to that. I jumped into creating these different endpoints and these different method calls. Is that okay to do? Like should I have waited or like.

Phantom Dictaphone: I think I will.

The Mighty Platypus: Sorry, please go ahead. I.

Phantom Dictaphone: Sorry I interrupted you.

The Mighty Platypus: No, please.

Phantom Dictaphone: Yeah, I think again this is in very interviewer to interviewer. I will tell you very, very frankly on that I would have not mind it in actual interview because like eventually you caught up on all the requirements that I wanted to do. But there are chances that there might be a requirement for which you don't need an API.

The Mighty Platypus: Correct.

Phantom Dictaphone: And you could have handled by other things.

The Mighty Platypus: So.

Phantom Dictaphone: So for example, I will call out in this. The function requirement should be that you should be able to do all the CRUD operations. Correct.

The Mighty Platypus: Okay.

Phantom Dictaphone: But you did not anywhere.

The Mighty Platypus: Yeah, I didn't. Because you have create, read, update, delete. Right. And we have create kind of have an update, but that's not like edit event. Yeah, yeah, you're right.

Phantom Dictaphone: So, okay, so for example, that kind of situation will might happen even in your actual interview where like you might have not caught that requirement.

The Mighty Platypus: But.

Phantom Dictaphone: But you just basically said, okay, these are the APIs.

The Mighty Platypus: Yeah, yeah, okay, okay. So like your suggestion would be like, next time I go into functional requirements, I do go through all of the crud.

Phantom Dictaphone: Not just all of the crud. What I'm saying is functional. Consider functional requirement as talking to your product manager. While talking to your product manager, you don't write the API, you basically just talk in English, write down what that particular person wants from you.

The Mighty Platypus: Yeah, interesting. So like functional requirements, if I were to redo that or do that in a better way, we would say we have an event management system and you want to create events, you want to get the events.

Phantom Dictaphone: In Amazon way. The way to think about function requirement is what does a user want? Yeah, what will user get?

The Mighty Platypus: Yeah. So me as a user, I would load up Outlook and I would see all the events that I'm invited to and I would have the button that would say, click click here to create event and it would ask me the start time, start, end and who's invited to the event. And then I would click submit and it would notify those users.

Phantom Dictaphone: So write your requirement in terms of customer, like what does the user will get? And based on that, start writing lot of other things that. Okay, now, now like While discussing the APIs at that moment, you basically say, okay, for this requirement, this is the API I need. Oh, for this I don't need an API. This can be handled by this.

The Mighty Platypus: Okay. Okay. Yeah, interesting, because I remember going through it like you gave me the hint of ask about the notification system, so definitely I missed that. But it was good that you guided me and told me about that. So I would say that would have came out in that question where I create an event and then my users are notified. And then you would probably. You as a product manager would be like, yes, I need some type of notification system so that my users know when they're invited to events or if there's a reminder for an event, like 15 minutes before the event.

Phantom Dictaphone: So yeah, yeah, okay, so solidify the requirements early on and then design everything. I mean like, you got the, you got the points that. Okay, I will be leaning towards higher only because I will tell you, like the only reason that you got that leaning towards higher was your database design was correct. Like it is a tricky Database design, lot of people fail on that. And the other thing is your design was almost there. Like, but if. If. So that's why I'm saying it was leaning towards higher. And if I. If it was a L6 interview, definitely not.

The Mighty Platypus: Okay. How. How could I have done better at the high level design?

Phantom Dictaphone: I think. I think like, if you have written down the function requirements better and followed the correct steps, you will have done it better. That's it.

The Mighty Platypus: Okay.

Phantom Dictaphone: So people don't realize it, but gathering the requirement and working from those requirements changes your design a lot.

The Mighty Platypus: Yeah. Yeah, definitely. Okay, cool. Yeah. This is very enlightening and I super appreciate it. Like, it's good stuff. It's. How. How far away do you think I am? Like weeks, months, years?

Phantom Dictaphone: Like in terms of L5 interview?

The Mighty Platypus: Yeah. Or. And do you think I could get to L6 if I. If I.

Phantom Dictaphone: You have 12 years of experience, you can actually interview for L6. But I think for L5 you are like, should not take more than like two. Two more sessions. Like, if you do two more sessions, like a mock interview, I think you should be there. So like, just take like 15 days, 15, 20 days. For L6. I do see a gap. For L6, I think it will. Can take like three months of time.

The Mighty Platypus: Okay.

Phantom Dictaphone: If you want, you can read this design that I have written. So this is a design for this particular system. So you can have a look on it.

The Mighty Platypus: Yeah, that'll be great.

Phantom Dictaphone: And it. It tells you like, how much time you each section for requirement, high must term for estimation. So it tells you all those things.

The Mighty Platypus: Okay, this is great. Yeah, fantastic. Availability and then consistency. Prefer availability over consistency. Yep, yep. Kind of. Kind of went through that. Good stuff. All right, cool.

Phantom Dictaphone: Anything else before we go?

The Mighty Platypus: No, yeah, this is great. Thank you so much again for your time and everything. So. Yeah.

Phantom Dictaphone: Cool. All the best. And enjoy your day.

The Mighty Platypus: Have a nice evening. All right, bye. Bye.