Technical product manager interview (How does Calendar work?) with Google PM

[Music] hi there everyone welcome to google product manager mock interview session today my name is prakhar and i'm working as a senior software engineer at google my role is today as an interviewer and my candidate is cat hi everyone my name is kat and i used to be a product manager at google on the responsible ait thanks cat and if you're good then let's start with our technical uh interview and today's technical question is how does google calendar work um could i take a quick moment to just think about um how i wanted to frame the answer sure it [Music] awesome so the way i'm thinking about it um is to first sort of define the requirements for google calendar and just to clarify with you what use cases i should focus on and what non-functional requirements i should look into the next is to sort of estimate the user and sort of data load that we expect and see how we can sort of design our system around that and then we can go into some of the larger api and database design how does that sound to you it sounds great yeah let's start with that yeah awesome so in terms of the feature requirements um i'll sort of talk a little bit about what a user might expect from a google calendar so the most basic event i can think of is to actually create an event on the calendar um and to be able to send people invites for particular calendar events a user might also want to load up the calendar so they can see what they have available all of the different events they have for the day or for the week and then they also might want to be able to sort of cancel and modify the meeting as uh their plans change throughout the day um another feature i can think of is around uh meeting reminders um so being able to set a meeting reminder for maybe an hour before the meeting just so they have time to prepare um there's also a use case that i use a lot personally at work which is to check other people's calendar for availability sort of compare their calendar to mine to make sure we can find a slot where we're both available um i'm assuming that that seems to be more of an advanced feature and is out of scope for the question is that correct yeah that sounds okay yeah that should be okay yep awesome um is there anything else um in terms of functional requirements that um i should be considering in designing this question no i think the ones which i've taken sounds good to me and let's start focusing on those and let's try to come up with a set of apis and you know estimations for the same yeah that sounds great it's important to discuss the use cases and ask clarifying questions this helps to make sure you're not missing any important functional requirements and limit yourself to four or five as you'll have only 35 to 40 minutes to cover the same um so really quickly i'm just going to touch on some functional requirements um these aren't super specific they're sort of very basic ones but i figure they're worth mentioning because they would be important in the actual engineering and api design um so the first is i think for a question um or for a product like google calendar having high availability is extremely important because um a user should still be able to take other actions while their calendar notification or their new event is pending so being able to still work with the platform and of course things like reliability and consistency are also really important so being able to um know that their data is going to be preserved the event isn't going to move um without them actually modifying it is extremely important makes sense yeah that's correct that's good yeah cool that sounds great um i won't go too deep into sort of uh as i mentioned before the capacity planning but just flagging a couple of things that um especially a product like google calendar will need to think about down the line because um of the scale of this product and the number of users who would eventually onboard onto the product um it'd be important to think about you know the number of daily active users we're expecting and the size of the data that would eventually need to be hosted on the google calendar platform that sounds good to me yep cad gave a good overview of functional requirements and also talked about some of the non-functional requirements which includes availability consistency scalability latency depending on your design these non-functional requirements are important from technical interview as it shows that you're not just thinking from a product but also from an engineering point of view great awesome so in terms of users a good way to think about the problem and i think i'll just do this on an order of magnitude rather than diving super deep into the numbers so let's say for example that um we start off with a hundred million total users um we could potentially say that about 10 million users are daily active users for actually creating meetings um i'm sort of just making an assumption that 10 of the users um will actually be using the platform day-to-day um we could maybe assume that an active user will schedule two to three meetings in a day so that's 20 to 30 million meetings um and then lastly uh maybe a user will receive four to five meeting invites in a day okay and if you can talk about the a little bit about the you know updating the events as well like how many users are you expecting to modify or update the meetings yeah i think it would probably also be around one to two times in a day so i would think of it as similar to a user scheduling meetings um but sort of a user thinking ahead to some of the meetings that they have in the future and also if meetings conflict for example then they would need to actually change the meeting make sense make sense yeah the number sounds good to me and uh yeah if you can talk a little bit about uh what are the important parameters you will calculate for this this design i think for um actual capacity planning that that we have a sense of the number of users and the activities um the last remaining parameter we would look at is around um sort of how much storage space each of these events would take on the system and then ultimately we would multiply that by the number of users on the system to get an estimate for how much storage or server space we would need to process um that information so um we could maybe uh make an estimate of around a thousand bytes per user um so thinking about like actually storing the information for each user um in thinking about google calendar perhaps information about their account um information about you know some of the events they have stored and ids connected to each of those events etc um and then another item we would have to think about is also uh sort of the calendar invites themselves and the information associated with that um i can dive a little bit deeper into what specifically that information is but it might contain information around you know the time of the event the attendees yes um and just making sure that we have the time zone and other small considerations right as well um so i'll make an estimate and say that that's around maybe 2000 bytes for storing that information it seems to be slightly more than a user since there's a lot of information associated and that we might want to add to something that users can store with a calendar invite um and so i won't go through the math unless you think that's something i should do but we would want to sort of multiply those numbers a thousand two thousand bytes with the number of users we estimated and also the number of calendar invites we estimated per day and we could also do that on either a monthly or yearly basis i think that should be good enough and i think we can move forward so i got a good idea of how exactly you're trying to align the numbers and calculate the numbers so i think we're good it's good to talk about estimations you can start with assumptions like daily active users meetings created per day average number of users attending the meeting etc and you can also talk about the qps and capacity planning on a high level you don't need to spend time on actual calculations let's let's move forward from here yeah awesome that sounds great um so in terms of the actual detailed api and um database design um i'll first talk through some of the apis that i think we would need to design in order to create the full user end-to-end experience with all the features we talked about earlier and then second maybe talk through in detail some of the actual database design components of each of the databases that we expect um the user to have to communicate with does that sound good to you yeah that sounds great yeah let's start with that yep [Music] great so in terms of uh the apis we need um there are some basic ones for a calendar or for another google event that uh we would need just to start the process for example something like a login api so that the user can use their google credentials to validate um their google information so they can sign in um there would also need to be an api for creating an event so that seems to be one of the most important features that we would want to design um so that might take in some information like the user that's trying to create the event any other invitation details for the user ids of those invited um and potentially also more details about the event like the name of the event where it's going to be happening a description any links to documents um that might appear in the event um and be able to send that off to the server so that the event can be created makes sense um another api could be the check calendar event um so as i mentioned before a user will want to see everything that's upcoming on their calendar for a certain week or month um and so that would probably take in a date range um that the user wants to see their calendar for and then also we'll have a list of all the events um so we can query the event information and show all of the events at the right times with the right titles um on the calendar very nice yeah that's very important yeah correct and especially the date range is important because you want to start display all the all the all the events within those ranges that sounds good yeah what else yeah and i think specifically for date ranges uh we could have some preset date ranges so for example for one day for one week um in one month i think that's pretty standard for different calendar apps moving on to the next use case i talked about which is updating an event a user would want to be able to update any of the details or list of invites um for a certain event so perhaps that api could take in the event that the user wanted to update and then actually be able to modify all of the different uh fields inside of the event um and a user should be able to delete this event as well um so there should be an option for whether this is a modification or whether this is an actual deletion of the event um so that it can be wiped from their calendar as well as the calendar of the invitees to this list as well so um i think having a list of user ids for everyone who's invited to the event is important so that not only the entry on um the user who's modifying it uh its calendar will be modified but it will also be modified on everyone else's calendar makes sense yeah awesome is there any um one of these apis that you'd like me to dive in for or think a little bit deeper about for um you know what the database and back end would actually look like yeah so if you can talk a little bit more about how will you create an event and what all details will you store on the database side for this events that will be great and yeah i mean we can take it up from there and we can try to come up with a high level architecture design once you're done with our data model yeah great sounds good in terms of the event um i think that first every event should first have their own unique event id um so that other um objects in this database can easily query by event as we have seen this is really important for example for view calendar so every event should have a unique id associated with it in events there's also the notion of an organizer so the person who's actually creating the event in the first place um they have a sort of special role in being able to actually modify the event and move the event around um so we should probably store their user id as a sort of special field so as organizer id for example um so that they can easily uh we can easily verify that the person who's changing it is the organizer um to give them permission to do actions like actually modifying the event um it makes sense we might also want to as i mentioned earlier keep track of some of the actual fields that will be displayed to users in the event so the meeting link that the organizer inputs any details about the information that's actually displayed in the description page the list of other user ids that are the other entities of this event it will also need to have sort of a start time and an end time um and with that comes sort of duration of the event or maybe we could just store the start time and the duration of the event just so we can display that easily um and then another thing we didn't talk about like user permissioning too much but now that i'm thinking about sort of organizer versus not and giving user permission to edit the event i know current calendars that i work with have an option where you can enable anyone so anyone on the user id list to be able to update the calendar event and not just the organizer and i've actually found that to be a very useful feature because um people might want to add you know links or whatnot to the event um and so there might be another um sort of field maybe a boolean that will store like um you know user modification allowed um so this would mean anyone in the user space um who's listed as an invitee or attendee would be able to modify the event as well and it'd be off if the organizer did not want that feature available yeah very good observation and yeah it makes sense to totally include that field as a part of your table yeah that makes sense okay cool so i think this sounds the data model sounds good to me and now can we talk about the different components which we'll have in this complete system uh it will give us a bigger picture of how we'll design each of the components and how we'll place each of this component and how the calls will work how will be the workflow so if you can walk me through that i think that'll be great great sounds good um so i'll sort of stop start at the very top in terms of um client and sort of their client actions um so first we're gonna have a client who's going to you know through modification of the ui call some of these methods and if we uh later in the interview want to talk about sort of a load balancer layer um between the client's actions and what actually gets sent to the servers we can also do that to figure out how these requests from the client are actually directed to the different backend processes first we have clients who are interacting with the front end um that will end up calling some of these methods uh that we have designed earlier in the api um so for example if a client clicks on a certain uh section of the calendar then that might trigger automatically a create event api call um and then that api call will interact with the database that we designed so the user will input all of the information on the actual front-end ui and then once they click post then it will post to a web server depending on load balancing and whatnot that we want to discuss later and end up in the database as a database entry and then in terms of other uh events that the user can call um we'll sort of have to retrieve that calendar event information and either modify it or delete it or maybe add a user attendee to it so that's how some of the other methods uh like edit event uh or delete event might work and then finally the other main api call is around actually just displaying the calendar which i probably should have started with um so when a user actually opens up calendar what will happen is uh the front end will sort of query all of the events that are available within the date range that we talked about um in that specific api call and then all of the different events that fit that criteria um will sort of be pulled from the database and then uploaded to the front end um so the user can actually see all of these different components um but yeah that was a super high level view of what the different components could be if there's anything you want me to dive more into i can talk more about the load balancing layer or any of the specific events as well walk your interviewer through api design data modeling and high level architecture if you are running out of time just pick a table and talk about the fields you will store as a part of that table like the way cat did at the end of the section it's a good idea to walk your interviewer through the high level architecture by taking an example of one of the apis so cat if you can walk me through the high level flow how how each other you know the components uh will work for one of the api and if you can talk about sharding replication and scaling for this i think i think that will give me a more insight on how how the system will work yeah sounds great um i'll first give an overview of how i think uh scaling and sharding might work and just give an overview of the options that might happen at each of the different stages that i talked about um and then we can dive in maybe for create uh event uh more deeply to see how it would interact with the different scaling and charting components and also the different components of our front-end uh back-end and storage system does that sound good to you sounds good dummy yes great so in terms of scaling um there are two different ways that we could scale the system to handle more users as our calendar uh app scales so first is horizontal so we can always add more servers to the system as we have more events and more uh users who are on the platform um but this would mean that we would need to sort of allocate and add those uh new resources into the system into consideration as we decide uh which new server to sort of send them to um so there's the added complication of that and the other way is through vertical scaling um which means we would sort of upgrade our systems to be able to store more information so upgrading old servers for example that might not have as much storage and processing capability to something newer could be an option but that also means that we would need to replace the system and there may be some downtime where that server may not be used and we would need to figure out redirection um for that period of time while the server is being replaced um so those are two options that we could go with as we think about you know actually scaling uh the app as time goes on in terms of sharding we have a couple of other considerations and options as well so sharding basically just means at each stage figuring out where to actually send the request or um the database query etc to since as we mentioned before we're going to scale to have potentially many servers across many of these different functions um so we could do range-based charting so basically just uh you know deciding to do uh have specific servers for specific uh regions of users for example so all california users maybe separate that into a few different regions given california so populous so that's a really easy way to do it the only issue is that we might have very different sized populations based on how our app grows it might be that you know a lot more people work from home in california and so we might have an outsized um sort of uh shard that we have to reapportion over time uh which could be difficult if the product is scaling really quickly and the other way is sort of hash based starting where we could hash the user id or event id for example and then decide to apportion that to different servers that does have the benefit that we can you know create a set number of buckets and decide you know where we want some of those to fall um and so that could be very useful um especially as we are going through a big scaling phase um to utilize but obviously there's the added computation of doing the hash um and then also matching the hash when we actually retrieve that information so there's also different trade-offs there amazing amazing this is good yeah yeah this sounds good to me if time permits discuss scaling sharding and replication strategy cat did really well on this one as she walked me through multiple options and talked about the pros and cons of each one great um so i know you had a second part to the question as well regarding how this would play into an actual um user request um so let's sort of talk through um what would happen when a user actually creates an event well actually i think we did a high level for create event so maybe now we can talk about uh actually just viewing the calendar i think that one's really nice because it interacts with many different um objects including both event objects and potentially user objects as well um so we can talk through that if that works yeah we can talk through that yeah that'll be great so um first the user uh will you know type calendar.google.com and they will have um sort of the page come up um there will probably be some default setting for uh what the calendar view is that the user has set before um so that's the duration for um the date range basically for what the calendar will show and as we mentioned before that will be like one day three days or maybe seven days um and so that will request uh to sort of view calendar will be first funneled through a load balancer to decide um you know where that request to process is gonna go um and so that will basically trigger the front end portion uh which will sort of need to decide where to send the actual back-end request so it can retrieve the information that's necessary to draw the ui elements um of the different events uh for the calendar um so now that we've passed that first stage we would probably need a second stage load balancer to decide which of the back end um sort of service web servers that we want to send the request to so specifically for a request like view calendar we would probably mostly be looking at the calendar event sort of servers that store the information regarding the actual calendar events and so for that we need to potentially pass through another load balancer layer to decide how to actually get the information about each of the different events in deep storage and so based on the way we've done our sharding we could either look to a specific region or we could look to a specific hash number for those user events um to retrieve some of that information um so that information once retrieved from the storage uh would be passed back to the front end um by which it would draw and populate a lot of these uh ui elements for calendar events um and then um that information would ultimately be returned to the user and then the request would sort of be complete for the um create calendar or sorry not create calendar view calendar event yes that sounds good to me i think you've talked about the complete flow and you've talked about each of the elements which are important and the good part was like you were able to relate it with your sharding strategy like uh with the help of load balancers so that overall sounds good to me uh anything else which you want to add as a part of this design any closing notes on this yeah i think um this i know how i had talked about sort of overarching uh non-functional metrics um and we talked about how like latency is not as important as things like availability i actually think that maybe for the um like view calendar event or like whenever a user first uh sort of goes onto the page and expects to see all the events that they have displayed um latency is probably particularly important for that function because it would be you know really uh annoying for a user to have to open a page and just wait for all of the events to populate um so i think if i could sort of go back and redefine some of these metrics um i would think about the functional metrics differently for each of the um functions that we have so i agree for create event it probably doesn't matter as much um as long as it posts within you know 30 seconds one minute and the user can still do actions on the calendar it works um but that same 30 second to one minute um timeline for uh sort of viewing the calendar wouldn't work as well that's correct that makes sense okay sounds good and any any any product matrix which will track is a part of this this design uh to know how your product is progressing yeah i think for um these uh for product metrics i would look at a few things um one is just the number of daily active users to figure out if there are any sort of big overarching problems with the product so if we see a drop off suddenly for example day to day then that might indicate that there's some basic functionality like view calendar or whatnot um that's not actually working um i would also look at um an funnel for some of the user actions to see whether there's drop off for some of the core user functionality actions that we've identified so is there drop off after creating an event the user creates an event maybe has a really bad experience and never comes back to the platform again or potentially for calendar invites as well perhaps the invites weren't sending or whatnot so we might experience some drop off after some of those major events [Music] another thing i would look at if we could build this into the system that we just described is actually just logging some of the latencies and availability metrics so that we have those on hand so how long is it taking the calendar to load how much time did it take before the user is able to create another event after creating one event i think could actually be helpful as well just to make sure have a good check that the systems are working properly that the hashing is working well and that things are not taking too long to retrieve and then as another baseline we'd also want to monitor just failure rates as well so for example if an event didn't post why is that if they weren't able to pull all the events from the database on a view calendar event why that is and looking into and making sure that there aren't any anomalies from from that cat concluded her design by talking about the different reliability metrics it's a nice way to end your design and gives an edge as you're thinking about how will you maintain your systems after descending them make sense okay guys so that's the end of the interview and i think you did really you did a really good job in uh you know dividing your answers into four different stages you started with the requirements part then you went on to the estimations you talked about the numbers about the daily active monthly active and uh you know how how many meetings they'll create on a daily basis and then you give me some insights on how will you calculate the qps or the capacity and how much data you will need to store you talked about uh the events as well like uh like how much each of the event uh will take on the storage site and then how will you multiply it so that was great and then you walked me through your design uh where you talked about the flows and the apis and you talked about the modeling and the component and i think the way you were able to relate sharding and scaling with one of the flows i think that was really good because i was able to see that you have a complete understanding of all the components and how the actual uh you know how the data flows from right from the client till the back end how do we fetch the data from the back end or from the databases and retrieve it and you know send it down to the entrance and then how the data is rendered on the client so that's good and then you talked about the metrics so i think overall you did a good job and you were able to cover all the important components of this design awesome thank you so much parker okay thanks a lot everyone and thanks uh thank you so much uh cat for uh being a part of this interview and i hope uh this interview is helpful uh helpful for the people who is watching this and both kat and i are interviewer and coaches that i got an offer so if you're interested you can contact us and find us there and thanks and have a good

Channel: IGotAnOffer: Product management

Views: 2,953

Keywords: google pm, technical question, calendar, mock interviews, productmanagement, google mocks

Id: uhtREgMnOFw

Length: 35min 15sec (2115 seconds)

Published: Mon Aug 29 2022