An Interview with a Google engineer

Watch someone solve the design facebook events problem in an interview with a Google 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 Facebook Events

Interview question

Design the Facebook Events Service

Interview Feedback

Feedback about Absurd Bandit (the interviewee)

Advance this person to the next round?

How were their technical skills?

3/4

How was their problem solving ability?

2/4

What about their communication ability?

3/4

Strengths: * Good Knowledge * Good Problem solving on the fly * General idea of system design interview and structures Things to work on: * Time management, try to get to the HLD Faster * Beware of your language, it's a really bad signal if you use foul language when under pressure or being questioned on your choices * Read up on more common design problems and most importantly how to solve them at scale , few things that will help are: 1. Watch in order of upload :https://www.youtube.com/@SystemDesignInterview 2. Read : https://www.amazon.com/System-Design-Interview-Insiders-Guide/dp/1736049119

Feedback about The Grey Dictaphone (the interviewer)

Would you want to work with this person?

How excited would you be to work with them?

4/4

How good were the questions?

3/4

How helpful was your interviewer in guiding you to the solution(s)?

4/4

Good at hints, patient, and gave some quick solid advice about the internal process at google

Interview Transcript

Absurd Bandit: Hello?

The Grey Dictaphone: Hey, can you hear me all right?

Absurd Bandit: Yeah, I can hear you. Okay.

The Grey Dictaphone: All right, perfect. How are you doing?

Absurd Bandit: Yeah, not too bad, man. How are you doing?

The Grey Dictaphone: I'm good. All right, if you're ready, let's get started. Before we get started with the actual system design block, I ask a few questions just to gauge the the level that you're targeting and things like that, so that I can probably ask you a question which is relevant to your level and also judge you for that level. So I copied a few questions on the main text. If you see it, you don't have to type the answers out, but we can just spend 30 seconds on them, maybe.

Absurd Bandit: Yeah, no worries. I don't know how to sum up my experience because I have a nontraditional background, but I've been getting paid to write software for, like, four years, and it's mainly been at startups, but I've done all kinds of stuff, definitely a generalist. And the companies I'm targeting are just like, bigger, more established tech companies. It'd be great to get a job at a fang company. Obviously, Google is a dream for everyone, but just bigger and better, just in terms of quality of four. Four and then level is mid level. Yeah, four years of experience and level is mid level.

The Grey Dictaphone: That sounds good. And then would you say you're closer to five or more closer to four? And I'll tell you why I'm saying that at Google. For example, I mean, the reason why you match with me is because I have worked at Google in the past two years. Google will almost always try to down level you depending on how many years of experience you have. That's not saying that a person with three years of experience or four years experience can't become an L Five, which is essentially their senior. But it is also on the other side that if you have three years of experience and you're aiming for L Five, they're going to judge you much harder than they would someone with, like, five years or six years of experience. So that's why I'm asking that question, because if you're closer to five, I'm going to also see how you stack with not just L Four, but also L Five.

Absurd Bandit: Yeah, it's a thin line between l four and l five Right. There are some people with ten years of experience to get L Three roles at Google and people with three years of experience to get L Five at Google. But I think probably I think the safer bet is L four because okay, I already passed my coding screens, so the tech screen, so my onsite is waiting for they're waiting for me to schedule my onsite, and I'm going to do it when I'm ready. And the thing that I'm mainly getting ready on is system design.

The Grey Dictaphone: Okay, that makes sense. Cool. Let's get started then, I'm assuming. Is this your first mock with interviewing IO.

Absurd Bandit: I think this is my first with interviewing IO, but I've been doing mocks lately with people that work at fang companies and just engineers that are more senior than me and smarter than me. So not my first mock, but my first mock on the site.

The Grey Dictaphone: Okay, perfect. So, yeah, what we do is we switch over to the whiteboard. There's a button on the bottom left. It's essentially an excalidraw running inside the intervention IO website. And that's what we're going to use for the system design. So let me know I'm just going to type something. Let me know if you see what I'm typing.

Absurd Bandit: Uh, yeah, test type.

The Grey Dictaphone: Okay, perfect. So what we're going to do today is let's see. So for L four, let's do Facebook events. I know, I mean, you're doing Google, but I'm asking a Facebook events question. I can generalize the term, too, but I think Facebook events is easier to explain.

Absurd Bandit: No, sorry, I'm not on Facebook, so I'm trying to get yeah, you're fine.

The Grey Dictaphone: That's what my next question was. If you don't know what it is, I'll give you a 62nd elevator pitch to kind of explain what you're building. Okay. Think of Facebook events as a normal calendar application, but with additional features. So just like, you have your Outlook iOS or whatever, Android calendar, so you have all the functionality of that you can schedule. Instead of a meeting, you're scheduling an event. So you can schedule an event. You can invite other people. They can RSVP yes, no, maybe you have the basic functionality of the calendar, like notifications, reminders, where a notification is more like, hey, XYZ invited you to the 4 July barbecue party, so you can click on it and go to the app and then RSVP yes, no, maybe. The second part of it is reminders, which is like this interview. If this was an event on Facebook, you would get a reminder an hour before saying, hey, your interview with interview IO mock interview starts in 1 hour. That's the part that comes from a basic calendar. Now comes the additional Facebook features. The first one would be, each Facebook event gets its own Facebook page, where all the people who are part of that event, invited to it, rsvpds, whatever, can interact with each other. So they can create posts. They can post pictures, basically start threads and talk to each other. The second part would be, which is the last one would be, an event will have much more metadata than a normal calendar event. So you have the name, location, description. But for a Facebook event, you can also attach because you're creating a Facebook page.

Absurd Bandit: Right.

The Grey Dictaphone: You can attach pictures as well, which kind of become your background picture or your title picture for the event itself.

Absurd Bandit: Okay, so there are two basically subsystems of Facebook events. So it's the calendar and then the Facebook features.

The Grey Dictaphone: Yeah, you can say that the Facebook features are essentially built on top of the calendar. And then there's one more, which, if we have time, we can do it's like an extended set, which would be being so events can be public or private. So the additional feature would be being able to search public events around you for private events. They should not obviously be accessible by anybody but who's been invited to it.

Absurd Bandit: Public events would be searchable.

The Grey Dictaphone: Correct.

Absurd Bandit: And then you within a certain mile radius, or that's, again, if we get.

The Grey Dictaphone: To that, it's more of an extended scope. We'll discuss it then because theoretically, I want to go to Boston this weekend and I want to see what's happening in right.

Absurd Bandit: So.

The Grey Dictaphone: That kind of stuff.

Absurd Bandit: Cool. Okay. So, yeah, so just focus on the calendar and the Facebook thing. So you said for the calendar, there were two parts of it. The reminder was the second part. What was the first part that you mentioned?

The Grey Dictaphone: You're talking about notifications and reminders.

Absurd Bandit: Yeah, I think that's what it was. I heard you say two things, notifications and is a so this is basically the same thing functionally for the user. Like, what the user would see would basically be just a Facebook branded Google Calendar, basically.

The Grey Dictaphone: So let me put it this way, right? You have a Facebook app, you go on it, and then one of the sub tabs, because Facebook has so much other stuff.

Absurd Bandit: Right.

The Grey Dictaphone: One of the tabs would be called Events, where you can click on it and it'll show you a list of all of the events you have. RSVP yes or no to when someone invites you to a new event, you'll basically get an iOS notification, which you will click on, and then it will open the event page where you can then RSVP your decision. And if you say no, it should not show up in your events list, essentially, right, because you already declined that event.

Absurd Bandit: Okay. All right. Yeah. Calendars are the tricky parts. A lot of technical challenges that come with calendars. Never built one personally, but been around it. Just trying to look at this and.

The Grey Dictaphone: See what's don't worry about building the calendar itself, because you're not expected to build, like, a calendar view like you would see one today if you open the calendar app on your iPhone. Essentially, the reason why I say calendar is because it's the most closest thing to explain what you're doing, but essentially you're not expected to create, like, a calendar view. Essentially, what you're going to create is maybe an API called Get Events where you will extract in chronological order all the events I am going to in the future that I've said yes, or, like, past events that I've been so that I can go to their pages and maybe, I don't know, share pictures or whatever I want to.

Absurd Bandit: Cool. All right. Just writing some stuff down. Okay. So obviously this is probably pretty high scale because facebook has a lot of users. So do we imagine that we need to worry about exactly how many people are using it? Or should we just say it's going to be a lot and we could think about it?

The Grey Dictaphone: That's your choice. I can give you a starting point. Facebook published that there are 4 billion monthly active users on Facebook. We can set a number, let's say 20% of them interact with Facebook events in one way or the other. So you're looking at, what, 800 million monthly active users.

Absurd Bandit: Okay. Obviously they're all over the so different countries. Okay. Traffic is predictable. Probably not, right? This is probably going to be if Harry Styles is in Boston tomorrow, that's going to be different for how many people are going to use it. So it's probably availability seems like the most important thing here. If I'm trying to go to one of these events, I'm not going to get mad if the database, which I can't see doesn't have the same data as the data on my app, on my device. I'm going to get mad if I try to access it and it's not available. So it seems like availability is like the most important thing for user experience here. Most important thing for user experience. Okay. Number of simultaneous events. Probably a lot too, right? Like concurrence.

The Grey Dictaphone: I hear you typing, but I'm not sure where you're typing. Are you typing on the whiteboard or on the text?

Absurd Bandit: I'm not, I'm not typing on the whiteboard or the text part. I had my own Google doc open on my computer, but I can type here.

The Grey Dictaphone: I've just never yeah, I need you to type on the tool so I can see what you're typing to. Because we'll use that for the feedback.

Absurd Bandit: Part in the don't worry, I'm just using chat GPT. I am a chat GPT. And this is the prompt.

The Grey Dictaphone: That's not the point. The point is that until I see what you're writing, I cannot give you feedback on it because there's obviously no way that I remember every word you say in the next 15 minutes.

Absurd Bandit: Yeah. Daily. This is number of daily, right? Daily active users.

The Grey Dictaphone: Monthly active users.

Absurd Bandit: Number of monthly active users. Location countries across the globe. Okay, so then this presents a tricky part because we don't want a user in Japan to have to be routed to servers in the US. Because that's unsecure or less secure. Let's say less secure, because that's less secure. So I'm just looking for the things that would just be, like, complicated. Especially complicated. Obviously the scale. There's a lot there are security considerations to make because the users are spread out. Traffic is not really predictable. It's actually highly unpredictable. Number of simultaneous events, probably a whole lot. Like, we could say probably in the hundreds of yeah, that's easily possible.

The Grey Dictaphone: I mean, I could put it at thousands. Because if you look at all the private events, things like I don't know, 4 July or whatever. You could have a lot of events going across us and parallel.

Absurd Bandit: Right.

The Grey Dictaphone: Or New Year's Eve for.

Absurd Bandit: Right, right. And all year else should be what else should we be looking for here? So if we're thinking about the system so the system is obviously something that's big. It is something that we want available all the time. It is something that we want to have some kind of fault tolerance in place or some kind of way to balance the load when the traffic gets really high. Highly unpredictable. So need a way to balance the load of traffic, number of simultaneous events all year long in the thousands. I'm going to skip this for now because concurrency is super hard to understand and just focus on what the system would look like if it were only like a few users. We can just designate them user A and user B when we start drawing in a minute here. I wanted to start a timer, damn it, before I started.

The Grey Dictaphone: I wonder how there's a timer on the bottom right? Already on your 14.

Absurd Bandit: Great. Cool. Perfect. Okay, so what else is important here? So we got to be thinking about the system. Got to be thinking about the users, got to be thinking about the traffic. So the users and the traffic feels pretty good. The system in terms of the data that we're going to be storing in our database, I'm trying to figure out if it's going to be something that we want to structure or leave unstructured. I think that my gut would be unstructured because writes will be faster. But if we do unstructured, then it's going to be slower for reads. And imagine the people that are using these, like something like like if you look at all the users on like, what ratio of them are actually writing.

The Grey Dictaphone: Obviously read heavy. I feel like a lot of people who write a lot, but then at the same time, there are a lot of people who never write. Like, I don't even think I've tweeted once in the past four or five years, but I go on Twitter every.

Absurd Bandit: Day, right, but this calendar probably feels different. Like, I use my calendar every day and I'm always writing in it. And I think that anybody I would say the number of write to read ratio is higher on a calendar than something like yes, I agree with that.

The Grey Dictaphone: Yeah. Because you also have a lot of other data points, right. You create one event and you invite 500 people to it. All those 500 people going and RSVPing yes, no, whatever, is actually modifying your data.

Absurd Bandit: Right. And that's getting to the notifications and reminders thing there. So that's important. Use storing the data structured and faster for rights. Okay. Thinking about these features here. Features like notifications, reminders and then own page, interactable page, more metadata. Okay. So just take these one by one. There's only four that we're focusing on right now. Why the hell does this keep god damn it. Okay, you should be able to share your screen on this website program that I'm familiar with, notifications.

The Grey Dictaphone: Remind if you want to use a Google Doc or something, you can copy this there and just give me the Google Doc link and I can open it. Whatever works.

Absurd Bandit: Think once we start drawing, I think that would be no, no, it's not on Google Doc. There's just a cheap free website called Sketch IO. But if I can't share my screen, then I wouldn't know.

The Grey Dictaphone: I know Sketch IO. However, the issue is that when you interview at Google for system design, they're going to make you use Google Doc, and they will make you do your system design drawing in the drawing feature of Google Doc, which is a complete different thing than Excelidraw. So I always recommend I mean, this was part of feedback, but just a heads up, anytime you're going to do a system design at Google, spend at least 30 minutes drawing on a Google Doc because it is much more harder than you think compared to, like, accelerate, draw.

Absurd Bandit: Okay, that makes sense. All right, so notifications, reminders, each event gets own FB page. This is interactable. Okay? Number four event page will have more metadata because people post stuff. Okay, I'm going to ignore videos just because videos are way more complicated than pictures for now. So I'll just say they will post pictures for now. Okay, so the features and notifications so just sending, making sure that each user has a unique user ID, and when they are signing up for an event or they are rejecting an event, that they can be notified from the service. So I would say a notification service, we can leave that as a black box for now, but it wouldn't be too complicated just to know which user it's talking to. I mean, users will be authenticated by the time they're trying to get notified by something. The reminders would be similar. This is where it gets really kind of complicated down. A little bit more complicated down here is each event gets its own Facebook page. Just interactable. So if it gets its own Facebook page, that's a public page. That other people or the creator. Each event gets its own Facebook page. So we would need to shard or break down, at least from the perspective of what we're displaying to the user. And those pages wouldn't necessarily be around forever. Like that Harry Styles concert this weekend or whatever in Boston. That's not going to need to be there next weekend. This reminds me of another problem. I'm trying to remember what problem this reminds me of. Not that matters, but I'm trying to think of a way to just conceptualize what we're talking about, and it's still not sticking. So it kind of reminds me of something like Ticketmaster a little bit simply.

The Grey Dictaphone: Because why do you think that? Because Ticketmaster is completely different. They're going to get an influx of traffic when the tickets are released to buy them. You're not going to have that influx of traffic in the sense that everybody's not going to show up on your Facebook events page on Saturday because there's a Harry Styles concert on Saturday evening. Yes, you're going to have to send a lot of reminders on Saturday. That part I agree. But you're not going to get an influx of traffic. It's going to be system generated traffic.

Absurd Bandit: Right.

The Grey Dictaphone: Because your backend will trigger those reminders. Nobody's going to come and manually trigger something for Ticketmaster, it's the other way around.

Absurd Bandit: So a lot of people aren't going on each Facebook page then? That's what I'm hearing you say.

The Grey Dictaphone: They're not at the same time. They could show up later for whatever reason. But think about this way, right? Do you go and check your calendar every Saturday to see what concert you have to go in the evening? Probably not, right? You get a reminder. Yeah, you get a reminder and then you look at it. That okay, yeah, it's time for leave to leave or whatever.

Absurd Bandit: Yeah, I guess no one's going to be trying to change the same resource at the same time. What I was thinking about was more.

The Grey Dictaphone: Depends on how you design your resources, but yes.

Absurd Bandit: Okay, well probably we'll probably need like separate, I would imagine. Maybe I'm getting ahead of myself. But for this notification service, reminder service, each event gets its own Facebook page. Event pages will be able to post pictures. I'm just going to start thinking out loud a little bit about how to actually make this don't hold me in any of this, but again, just kind of thinking out loud. So obviously it's going to be good to have some kind of database, at least one just to start with. So let's just say this is NoSQL again, going off of what we said earlier. So if we wanted faster reads, we don't, but if we wanted faster reads, we could go with SQL. But we want faster writes. Also if we end up do getting yeah, I guess I can worry about that later, but okay, what else? So if there's a user A and user B over here, just calling them that because we don't know where they are. So we will need to break something down. I don't know if it's going to be the database or the data the user sends us or something else, but whatever we need to serve up to them, we do need to make sure that they get all the stuff. Let's say user one. Okay. So there could be some kind of server here that we have. Maybe there will be separate databases. There might be, these would be replicated, these would be replicated databases. You it located. Okay. And so if we just have this okay, if we had if we had something to balance the load, if we had something to balance the load, that would definitely be helpful. And we do want things to be yeah, we want things to be easily accessed. So cross this out for now. So this is something I can just balance the load and then if we had this server, once users were authenticated, so user one would go into the web page, log in, they'd be authenticated, they'd come into here. Okay, now I'm already regretting that I've done this. Where is the eraser button here? It's got to be an eraser, right? Okay, got to be that. Yeah. Cool.

The Grey Dictaphone: You can just select on this thing and just delete, press the delete button.

Absurd Bandit: Sweet, sweet, sweet, sweet, sweet, sweet. So what we're going to do is we're going to make sure that they get all these services. So I don't just want to call it service one and service two and service three. But ostensibly, if we had for now, this would be a black box, but something like notification would just be okay, the user is authenticated, they are being notified ten minutes before the next event. So that would be like a notification service. This one would be for reminders. The tricky thing about reminders would be that no, sorry, notifications. How is a notification different than a reminder? Wouldn't they both be notifications?

The Grey Dictaphone: Yes, but I am hoping for you to tell me how a notification is different than a reminder. The end goal is the same. Yeah, you'll get, I don't know, a Facebook app, notification on your phone. But how are they different inherently?

Absurd Bandit: Oh, yeah, one's coming from us and one's coming from them. Right.

The Grey Dictaphone: GS and.

Absurd Bandit: Well, notification versus a reminder. Notifications are happening all the time. And reminders are time based. They're time bound based on upcoming events.

The Grey Dictaphone: Yeah, but that doesn't matter, right? Because even reminders will happen all the time. Because your events will happen all the time. Think on the times of consistency and timeliness, et cetera. Think on those lines.

Absurd Bandit: M. So thinking along the lines of consistency, we want to make sure that this communicates with the database and this communicates with the database, but that it doesn't. You can go two ways here, but only one way to the database. So yeah, it's to make sure that the database is consistent with the notification and reminder service. That's what I would be thinking. We can't have it all, but yeah, I think that's important. Timeliness.

The Grey Dictaphone: Oh, no, I'm asking you to differentiate them both on the basis of timeliness.

Absurd Bandit: Yeah, well, this one's going to be more often.

The Grey Dictaphone: Again, I was trying to give you a hint, but let's get into it. Right. A reminder for an event that starts at 05: 00 p.m.. And you have it set to be delivered 1 hour before you expect it to show up at four. It shouldn't show up at 401, it shouldn't show up at 359, it should show up exactly at four. Whereas I create an event and I invite you, you can get a notification five minutes later and you wouldn't even know that it was five minutes late because you don't know you've been invited to an event until that notification shows up.

Absurd Bandit: So are we talking about something like a timestamp or like a scheduled job or something?

The Grey Dictaphone: No, I'm basically differentiating notifications and reminders for you. One has to be strongly consistent and reliable and timely. The other one can be eventually consistent because until that notification shows up, you don't even know that some event was triggered where you were invited to an event thing. Or for example, if I changed the time from 05: 00 p.m. To 06: 00 p.m.. Five days before the event, you wouldn't know that something has happened until you get that notification. It's not bad customer experience for the notification to show up 500 seconds after the actual underlying trigger happened. Whereas for notifications sorry, reminders, even waiting 60 seconds is bad customer experience because you expect your alarm or your reminder to work on the time you set it to.

Absurd Bandit: Right.

The Grey Dictaphone: Which will then drive and make a difference.

Absurd Bandit: Right. So I think we're talking about just the way that the contract between the machines, the way it's set up. So for notifications okay, but this helps know to make the reminders real time updates and they're written into the database, whereas we're batch updating the database for anything that's in a regular notification.

The Grey Dictaphone: Okay, why does notifications have to be in batches?

Absurd Bandit: Because it's not as important to happen instantly like the reminders.

The Grey Dictaphone: Okay, I get that part, but still, why does it have to be in batches every five minutes? Yeah, it can be backlogged. I agree with that, but I don't agree with the batching part because then you're increasing the latency intentionally by saying, hey, even if the server is literally empty and nobody's using it, I'm still going to hold you up for five minutes because I'm batching every five minutes.

Absurd Bandit: Right, so backlog it okay.

The Grey Dictaphone: I mean, you tell me. I think backlog sounds better.

Absurd Bandit: It sounds better because the latency with the batch job would not be worth it, especially the scale that we're working at. Okay. The API would be pretty simple here. It would just be for somebody who is trying to just look and see what events that they've signed up for so they know what they're going to be reminded of. It would just be from the user, like a git event. And if it's something where they wanted to go back in time and see all the old events they'd ever been to, then it could just be something like a Git past events or something like that. Each event gets its own page and it would be an interactable page. Okay, maybe not. Maybe so when the server has user two authenticated and are authorized to make an event or interact with an event, they would then be able to go here to an event page. And then once they're on the event page, there probably would be things again, there wouldn't be a million people right now and then no people 10 seconds from now, but there would be people coming all the time. And just to decrease the load on our database, we could have a cache for the obvious things that are going to be on those event pages. Like pictures of Harry Styles. Pictures of Harry Styles as fans. Or maybe like if a user logs in from Korea, there's a picture of Harry Styles eating Korean food. Or if they're logged in America, there's a picture of Harry Styles dancing like Britney Spears or something. So if we have our event service, it seems like it would be smarter to have that event service utilize a cache. So then the cache could lower the load from the event page that would be pulled up all the time, and then it could go to the database if it needs to. But we don't even need to necessarily need to have I'll just make it an option so it can make some kind of decision where there can be a simple decision tree, whether it should just be written into the database. But this is more unlikely, my cache is more likely. I think the things that would be worth talking about here are just to try to make it as simple as possible. I'm just kind of thinking about this event page. It's almost like paste bin. Again, no videos, not TikTok, not anything like that, but just a page where somebody can post a picture and do simple stuff on that page. And again, because if I'm a user on this page, the last thing I want is for it to be unavailable because then I think the show is not going to happen. So if we have a cache to serve up the stuff that users are going to want all the time, that would be a good user experience for them. And then when we decide it's important, which we could figure out at a later time, then we could actually write that data into the database to make sure it's consistent. I think we have more margin for we can relax the consistency constraint, especially over here with the event pages, because the stuff that's in the databases is going to be less important than users getting what they need quickly, trying to think about what else is going to be good here. So events can be public or private. Public events can be found within a certain public events. You can look about events that are happening. So, yeah, so this is important. So if there's two different kinds of events, it's kind of like interviewing I O, having used this platform just today. If we were writing code, we're not, but if we were, we wouldn't want it. So that there. Was no layer of separation between the code that interviewing IO has on their website and the code that we write on this page. In that same vein, we would want a degree of separation whether an event is public or private. So I'm trying to think about I've never really thought about that before, about if I'm trying to make events that are either public or private. I think what we would be talking about is authorizations. No. Like this is a security feature.

The Grey Dictaphone: No, I don't think yes and no. First of all, if you do not so let's say it's a public event. Sorry, it's a private event, right? You wouldn't have any way to access that private event, basically, unless you were invited to it because your list of events would not show you that event. Theoretically, I could send you the link to the event page and you can try and open it, but we can make it out of scope that Facebook security and authentication would take care of it. It already exists. You don't have to build that. You can't access a link that you don't have permissions to. But if on the other hand, it's a public event, you'll be able to access it because it's public. You don't have to design that part.

Absurd Bandit: Well, then can we just say it's a black box service, it's going to take care of that's. Fine. Okay, well, that's actually not even necessary. We can only make one. So this is if necessary, this would be the private ones. The public ones are already here. That's the E. It's just the regular event. That's the baseline. Private ones would be a different ones, and there'd be a black box. We could hand wave it for now, but just say that somebody would have to do some authorization as a part of making sure people only get what they should have access to. And they could do some kind of salting or hashing or some kind of security measure to make sure that that's done. They could figure that out based on the other needs of the system because this is all theoretical, but yeah. Okay. Yeah. So overall, this is a very primitive design, but if you have questions or things you want to deep dive into, I'd be happy to do that.

The Grey Dictaphone: Yeah. I mean, a bunch of stuff I want to understand. How would your reminders you said real time, but I definitely want to know end to end, how do you expect them to be real time? And by real time, my assumption is you mean on time, not real time.

Absurd Bandit: Yeah, definitely. So that's a good question. I don't know off the top of my head, I've never worked on something like that before. We just want to make sure it's low latency so that there's zero delay.

The Grey Dictaphone: From I mean, essentially all I care about is if my config is set to remind me 1 hour before the event start. A 02: 00 p.m. Event. I should be reminded at 01: 00 P.m., my time zone. You need to fill the black box of how you make that happen.

Absurd Bandit: Righteous. Is this like more of a first in, last out kind of a thing where we're just looking for the method in which the machine decides what order to take stuff? Is that what you're saying?

The Grey Dictaphone: I mean, that could be part of your design. I am asking you, on a scale of 800 million users per month, how do you build a system that essentially you have some data stored in a database, right? Again, we'll talk about how you have stored it, what you're storing, but you have a list of all the events that are going to happen in the future in a database. How do you go about notifying me who is one of the invitees in one of those events that, hey, your event starts in 1 hour, when it is 1 hour away from starting.

Absurd Bandit: That should just be a scheduled job, no?

The Grey Dictaphone: Okay, let me ask you a few questions then. Let's say it is a scheduled job. What time would that schedule? So, again, let's take this example, right? 02: 00 P.m is my event. You're supposed to notify me at 01: 00 P.m., what would your scheduled job look like? What time will it start? What will it do?

Absurd Bandit: It would probably start sooner than it has to, so it's not late. And it would probably look through all of the people that have signed up on that event and RSVP and then send each of them a ping.

The Grey Dictaphone: Okay, let's put into numbers. Right? So you're saying maybe start a job five minutes before 01: 00 P.m..

Absurd Bandit: I don't know, man. Again, 8 million a month. I don't know if you want me to do the math, but like, 800 million a month, that's like almost a million a day. Less than or sorry, a little bit more than it's a little bit more than 10 million a day. So, yeah, these are thousands or hundreds of anywhere from tens of thousands to hundreds of thousands of users that it would have to look through.

The Grey Dictaphone: Let me throw another job. You're assuming that every customer only uses your events once a month, which is not true.

Absurd Bandit: Right.

The Grey Dictaphone: I could be invited to five different events in a month.

Absurd Bandit: Right? Yeah. There would need to be a user ID so that we're not a user ID, but an event ID and a user ID. Okay, but yeah, if the machine could check the user ID and then check the event ID, they would know which user to send, which event ID ping to. But yeah, in terms of scale, I'm just going to call it roughly 10 million a month. But that's sorry, a day? But that's assuming they only do one.

The Grey Dictaphone: No, you're fine with 10 million a day. I'm fine with that.

Absurd Bandit: Now, I'm honestly not sure how long that job would take. I really don't know how long that job would take of looking at all the user IDs that are signed up for event A and then sending all of them an event reminder 1 hour before if the event is at one, and we want to remind them at twelve. Certainly somewhere between like, I don't know, at the level of system people that Facebook has, a level of people that are working on this other stuff besides this. I would imagine that five minutes might be right.

The Grey Dictaphone: Let's talk theoretically. The reason why I was asking you for a number is for you to think about it from a bigger picture point of view. So what I mean by that is on 4 July evening when you're going to have probably 10 million events happening in concurrency versus a random Tuesday afternoon in the middle of February in Alaska, the amount of events happening are going to be drastically different. So you cannot rely on a bad job to do your job. Because even if you put it at X minutes, that x is arbitrary for this conversation. Either based on your data that you have, either it will run too fast and notify me 1 hour 15 minutes before, which is bad customer experience, or it will run too late and notify me 30 minutes before, which is also bad customer experience.

Absurd Bandit: Yeah, but that's even worse to get notified late, probably. Yeah.

The Grey Dictaphone: I mean, in this case, anything which is not timely is bad customer experience.

Absurd Bandit: Right.

The Grey Dictaphone: Because there's an expectation set out of the system you're building, and the expectation is for it to show up on time. So that being said, the reason why I was using that as an example is to show you that the bad job will not be real timely because you cannot classify the parameters of the work the bad job has to do similarly. Yeah, but what threshold? Okay, let's talk about that.

Absurd Bandit: Right.

The Grey Dictaphone: What are you planning to threshold?

Absurd Bandit: We could have something where if it's over a certain amount of if an event has over a certain amount of sign ups, that it has a different job than if it has under a certain amount of sign ups. We have multiple machines. Multiple machines? We charred the database. We could chart the database into multiple machines if it's over, I don't know, ten times the normal amount.

The Grey Dictaphone: Yeah, but then Facebook is also ever growing. So how do you decide the normal amount that's to be relative?

Absurd Bandit: The number could be relative. Yeah. The second question last 90 day average. Last 90 day average. Ten times more than the last 90 days average.

The Grey Dictaphone: Yeah, okay, I get that part. But to even find out if your event has less than or more than 500 people, you'll have to query your events database. Now, to query that events database for that specific event, you need to have a second bad job. Start that querying of the number of users in that event. Otherwise, how would you even know that I'm supposed to send out notifications for event X at 01: 00. P.m. Without actually querying your list of billions of events that you've stored?

Absurd Bandit: Yeah, if we want to do it in one call, we could use something like GraphQL. Most of the times people have no idea what Facebook uses, but if they're using Rest, that's going to be different than if they're using something like RPC or GraphQL. A lot of this could be avoided if we just had GraphQL happen because this is good for customer facing apps, which just definitely is because we're going to be doing a lot of stuff user facing fast. Also, it lets front end developers make changes without requiring any work from back end engineers. So that would just help some of the stuff that we're talking about here, but probably not this exact thing. If we wanted to have the notification reminder service, be aware of how many people have signed up and then fuck, I'm trying to figure out what we're.

The Grey Dictaphone: Trying to GraphQL in the past. I've used GraphQL in the past, and I see where you're going with it. I get it. You can join two things into one with GraphQL, and I have nothing against that. But what you're not understanding right now is the part that I'm trying to basically explain you is that with a bad job, you will not be able to deliver it timely. And there are a couple of other reasons for that too.

Absurd Bandit: First, again, so we either shard the job. We either shard the job or we shard the database. Right?

The Grey Dictaphone: Okay, we have to break down. Let's skip that component right now and come to the second part, which is let's say somehow using a black box system, you're able to find out at a correct time that, hey, we need to notify user X for an event. Then you fire up a notification using your back end service. What about network latency? There's going to be some kind of network latency from your server to my phone. And again, you cannot in any way know what that network latency looks like. Right? All right, I could have WiFi and you can deliver it to me right away. I could be in the middle of mountains, in desert, and I have like.

Absurd Bandit: A cache would reduce latency, but I don't know, it could reduce latency of an expensive computer job or a network call or database query or something. So that sounds pretty good here. Probably a cache in between the calendar service and the database.

The Grey Dictaphone: No, but again, so that's the part where you were talking about a different section. I'm talking about network latency between Facebook backend servers and my cell phone.

Absurd Bandit: Not in terms of user. Okay, you want it between the user and our server? Yeah.

The Grey Dictaphone: I'm not worried about how you do it on the back end of the server. I'm sure that's solvable with caches and stuff. I'm talking about the exit point of Facebook servers and my cell phone.

Absurd Bandit: Yeah.

The Grey Dictaphone: How do you deal with that network.

Absurd Bandit: Latency so we don't have to store it again? We would build it around this first line of servers here, the first S, the box next to what are you going to want in user two?

The Grey Dictaphone: We build it.

Absurd Bandit: I don't know the specific brand, but we want to say that there's a cache that could serve up data that users could get quickly. You got to remember, like 80% of queries should be served by like, I don't know, 80% of queries should be served by like 20% of the popular data which is stored.

The Grey Dictaphone: Yeah, I get that part. I agree with that. I am not denying that in any way. What you did by installing that cache at S, I'm going to say at S because you technically do not own the line between user one and S. S is where Facebook starts. Anything outside of S is like outside the scope of Facebook. It's the Internet. Let's say you install a cache at S. All that did was it reduced your network latency inside Facebook. So now you don't have to interact with N, you don't have to interact with R, you don't have to interact with your SQL. All of that got reduced to, theoretically speaking, zero. Right. But that still did not in any way change the time it would take from S to user one.

Absurd Bandit: Okay, so the cache should be between the user and the first server.

The Grey Dictaphone: Then how would you do that? How can you build a cache on the Internet, which is like, you don't own any of that.

Absurd Bandit: And if you own sorry, again, this is what I originally said. It should be between the calendar service. It should be around the calendar service. So the server which is S is going to be pinged by user one. Then the server will say, okay, do I need to send this all the way to the database or can I get this done in the cache?

The Grey Dictaphone: Okay.

Absurd Bandit: And the cache will say, yes, get this all the way done in the database. This is something that needs to wait.

The Grey Dictaphone: I have a question. No, you lost me there. You said your user one would ping S, but in terms of reminders, your user one is not going to ping S. Why would the user one initiate a ping to S? For a reminder. Reminders are server initiated, not user initiated.

Absurd Bandit: Shoot. Yeah, that's a great point. It's a great point. So this is about notifications. You're right. This is about 1 hour. This is about 1 hour reminder notifications. I'm not looking at the design because it's not exactly how it needs to look. But when a user has been notified, that is a good thing. When they are notified on time, that is a great thing. So we are going to put a cache around the scheduling service so that when it is ten times more than our usual traffic, the cache will have the 1 hour reminder job that then they send directly back to the server as opposed to a whole bunch of latency by that job going all the way to the database. So that's the thing. The baseline. If it's under ten times the normal amount of traffic in the last 90 days, we can send that through the scheduler.

The Grey Dictaphone: As usual, you're trying to fix network side latency sorry, Facebook internal latency. And I'm not asking you to fix that. I'm saying that's not a concern.

Absurd Bandit: We can't put a cache between a user and the server that I know of. That I know of. Maybe there is a way no, it's not.

The Grey Dictaphone: I'm agreeing with you. Which means that that's not the way to solve this.

Absurd Bandit: Right.

The Grey Dictaphone: There has to be something else that can be done.

Absurd Bandit: Okay. It has nothing to do with the event.

The Grey Dictaphone: Let me give you a hint. Let me give you another hint. When you're flying today, if you have an event on your calendar with Google or Android or sorry, iOS, whatever, you still get your calendar notifications on your phone even though you're not even connected to the Internet.

Absurd Bandit: Oh, we can have it on the device. You have the device? Store it?

The Grey Dictaphone: Yeah. Your calendar works even if you're not connected to the Internet because your device is synced to the calendar.

Absurd Bandit: Oh, the cache. Yeah. Okay. It got the data from the cloud. Sorry. Yeah. Okay, so I don't know how that would work. I could try to limp my way.

The Grey Dictaphone: Through that kind of also at time. So I'll stop you here. Cool. That's why I was asking you, like, 20 different times. You're trying to solve the wrong thing. Think about between S and the user, and you kind of got the idea that there should be a cache, but you couldn't figure out where the cache needs to be. And that's why I was telling you. You own S. You have an app on the user device, but you don't own the link between them. The idea was to kind of somehow, without telling you, tell you to put it on the user's device, which you can, because you have an app running there. You have storage space.

Absurd Bandit: That's a good interview. Now we can go see Harry Styles in Boston this weekend, me and you. It'll be great.

The Grey Dictaphone: Okay, let's come to the feedback part, which is essentially what you paid for. So on a high level, which is what I would tell a recruiter if this was you and I interviewing at Google, I would definitely say lean higher for L four. This is definitely not a strong hire because I had to give you a lot of hints and guide you through. It would be a lean hire in the sense that if your other interviews are bad, I'm not going to try and defend you and say we should still hire them. But if all of your other interviews go really well, I would not say no. It's like a very bottlene hire. And the reason for that is three things. And now we're going to the detailed part, right? So I think you started off really well with writing down everything. You got the right idea. However, basically, I know zero about your data modeling at this point of time. The math I'm not that worried about because it's Facebook scale, so we don't need to do that math. However, when it comes to data modeling, how would you store this data? How would you divide event list, invitee list, user list, all of that stuff? Obviously, it's not going to be in a single NoSQL database, right? How do you divide them, how do you connect them?

Absurd Bandit: I have none of that more detailed look of how the data would be structured in the database.

The Grey Dictaphone: Yes, because you're interviewing for a mid level to engineer, right? Not an early on and a mid level engineer. The basic goal is you're able to do your work and draw a design for a system with some guidance from seniors on the team. They shouldn't have to solve the problem for you. They should be able to just tell you what the problem is and guide you towards where you look for a solution and then you do it. If the data modeling itself is a blank for me, then I have to do it myself. So I expected you to do that part for the system design. Similarly, I feel like there were a bunch of times when I had to stop you and say you're thinking about the wrong thing or you're going in the wrong direction. This is not even a concern right now and guide you to the right thing at mid level. I don't expect you to come up with client side caching and all that yourself without any guidance, which is what happened here. I guided and you eventually figured it out. But at the same time, I also do expect you to take the hints and take the guidance I'm giving you rather than keep going in circle on the same thing that I've already told you, not like I told you at least maybe three times not to worry about network side, like server side latency. But even then, in the back and forth, your responses were all trying to solve Facebook server side latency, which was not even not the concern here.

Absurd Bandit: Right?

The Grey Dictaphone: So definitely work on that. Take the hint and work on it. Because if you don't take the hint that's technically at Google specifically, I can tell you it works against you in terms of Googliness, that somebody gave you a hint and you just blatantly ignored it and continued with your right. A lot of companies don't use it against you, but Google does, for sure. I can tell you that from experience, the last thing that I would leave you with would also be again, I know it's a mock interview and it's like the heat of things, but definitely be cognizant about your language because someone again, this is a very hit or miss thing. Some interviewers don't care. I wouldn't ding you for it. But I personally also know interviewers where if you basically, I don't know, use the effort, do this and that, that's like an immediate, yeah, we don't want to work with this guy. Because the idea is that you're also judging this person to be that if this was your peer, would you like to work with him or not? And I don't want to work with someone who gets frustrated in a system design when questioned and goes like, fuck, I don't know what to do that way. So in a mock, it doesn't matter much, but since you paid for a Google mock, I'm telling you from a Google point of view, with some interviewers, it could be an immediate strong no hire. And if you get a single strong no hire on your record, if you get a single strong no hire on the record with someone who has more than five years of experience at Google, you are blacklisted for, I think, five years or.

Absurd Bandit: So. Don't bomb any of the rounds. Is that worse? Is a strong no higher? Because there are five levels. It's strong no weak no on the fence? Weak yes. Strong yes? Is that how it works?

The Grey Dictaphone: Correct.

Absurd Bandit: Okay.

The Grey Dictaphone: A strong no basically blacklists you. They'll ask me, obviously why am I saying strong no if it's something related on the lines of basically if you're not inclusive, if you're using foul language, if you're being like, there are some literally people who turn out to be racist and stuff, any of that cultural stuff is basically a straight up blacklist.

Absurd Bandit: Right? Well, I have a question.

The Grey Dictaphone: I don't know.

Absurd Bandit: This is not exactly relevant to me. I know we're over time, but I just had one last question. Do you mind?

The Grey Dictaphone: Yeah, go ahead.

Absurd Bandit: Not because I'm going to be a strong hire, but because I just want to know about the power of an individual interviewer at Google, let's say that you said earlier if someone's a strong hire, then you can basically fight for them. How does that work? No.

The Grey Dictaphone: So the way it works is that let's say that you did five rounds, right? And three people, four of them are saying higher and strong higher. And one is like, strong no higher. I can fight them and say no. I think that's outlier, and we need to redo this interview. And then the recruiter will reach out to you and say, hey, the community decided to do redo one round. So when are you available to redo this? On the same thing, if four people are saying no, like four people are on the fence, and then one person is saying higher, that one person, depending on how senior they are, can technically fight and say, no, I think I have strong signals for this person. What then happens is you still do another round, but you do another round with another senior, who will then decide whether to agree with someone who's more senior than the person who's trying to fight for you, whether to agree with that guy, or whether to agree with the other three who were on the fence and hence not hire that person. Because if you get all on the fence, that also leads to a no hire because we don't want to hire someone who everybody's on the fence about.

Absurd Bandit: So if you get one person to give you a strong hire, then they give you another chance and that is another round, whatever.

The Grey Dictaphone: Correct.

Absurd Bandit: Right. It's not like a strong hire person could fight so hard that you just get the offer. That's not how it works. They can only fight so hard. You get another chance. Interesting. Okay, interesting. Cool.

The Grey Dictaphone: And then also I must call out every PA does things differently. This is my PA. There could be like YouTube, for example. YouTube could do things very differently than Ads does, for example. So take it with a grain of.

Absurd Bandit: Salt is what I'm trying to this is this is cool, man. I'm probably going to stop by for more mocks, but this was a good first mock on the platform. Thank you.

The Grey Dictaphone: Yeah, I'm also supposed to so two things to call out, which I usually do in the start, but I didn't because we were like, talking about something. Everything we talked about is recorded, so you can go back and look, review it as many times as you want. I'm also supposed to give you written feedback, which I will after the call. So maybe give me 15 minutes and you should have it. And that I'll call out what we discussed on a summary level and also give you some pointers that I have, like, be it YouTube channels or books, et cetera, that you can read to basically get better at this.

Absurd Bandit: Nice. It sounds good. No rush on that. Whenever you're ready. But thank you for your time, man.

The Grey Dictaphone: All right, bye. Best of luck. Bye.