A System Design interview with a Meta/Facebook engineer

Watch someone solve the design online judge problem in an interview with a Meta/Facebook 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 Online Judge

Interview question

Design Online Judge, given a problem, allow users to submit code, test code and get result of submission.

Interview Feedback

Feedback about Aerodynamic Tortoise (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

4/4

How was their problem solving ability?

3/4

What about their communication ability?

3/4

Overall hire for E4. Weak hire for E5. ✅ What went well: 1. Good functional requirement 2. Good non-functional requirement 3. Good quantitative analysis 4. Core puzzle: talk about how to secure the code execution (requires hint tho). Decided to use containerization. 5. Deep dive: Talk about securing the app with VPC 6. Deep dive: talk about using API Gateway for authentication, throttling and load balancing 7. Deep dive: talk about push and pull model on how to send submission result down to client 8. Good data flow 9. Complete solution 10. Good component responsibilities ❌ What can be improved: 1. Overtime by 4 mins, and didn't get a chance to talk about data API and data schema. Tips: 1. Easiest way to sound smart (and have opportunity for deep-dive): user → LB → API gateway → service (don't forget to mention API gateway) 1. API Gateway allows you to put these following deep dive: authentication, security, rate limiting, throttling, transformations, analytics and monitoring 2. Keep functional + non - functional + quantitative analysis down to 10 mins, no more than this. 3. On quantitative analysis, you can use quick numbers: 1. 1MB → 1e6 2. 1M DAU → 1e6 3. 1 day → 86400 sec → close to 100, 000 sec → 1e5 4. Usage on computing QPS → 1M DAU → 1e6 / 1e5 → 10 request/sec. 5. Usage on computing storage -> 1M DAU * 1 MB * 5 years -> 1e6 * 1e6 * 5 * 400 -> 1e6 * 1e6 * 2e3 -> 2 * e15 4. You can talk high level design + API design + data schema + data flow at the same time.You can save 5 - 10 mins by doing this. 5. Persist all the discussion into writing / drawing.You don't know when your interviewer will actually get a chance to write your feedback 1. They might get into other meeting after your interview and only get the chance to write feedback 4 hours after the interview 2. By that time your interviewer will forget whatever you're talking about 3. So write / draw down your discussion 6. Master your drawing tool.Practice with excalidraw(cuz Facebook uses excalidraw) 7. Stop in each milestones and ask question: "am I going to the right direction, or do you want me to go deep into somewhere else?" 1. For example: stop after discussing non - functional requirement 2. But don't ask in every assumptions that you have to clarify. Cuz this will waste a lot of time. Every minute counts! 8. Your biggest enemy is not your tech skill.It's usually time. Remember that you only have 35 mins. Benchmark: - 1 - 3 in 10 mins - 4 - 6 + 8 in 20 mins - 7 in last 5 mins if you have time(this will get you to E6) Framework: 1. Functional req 2. Non - functional req 1. Reliability 2. Scalability 3. Security 4. Latency 3. Quantitative analysis 1. Number estimation(how many users, how many time use cases, read heavy vs write heavy, read to write ratio) 2. QPS / TPS 3. Storage consumption 4. Bandwidth(not always important) 4. High level design + Data Flow 5. Data API(REST - GET / POST, GraphQL).Both request and response. 6. Data Schema + Data Store 1. SQL vs NoSQL 2. Object storage 3. Database partitioning / sharding 7. Optimization —> important for E6 + 1. Authentication 2. Monitoring 3. Mobile specific knowledge 8. Most important: Core Puzzle, somewhere between 3 - 6 Example: 1. Parking: https://www.youtube.com/watch?v=NtMvNh0WFVM 2. Facebook News Feed: https://www.youtube.com/watch?v=5vyKhm2NTfw 3. Spotify top K song: https://www.youtube.com/watch?v=CA-ei3mOCf4 4. Rate limiting: https://www.youtube.com/watch?v=mhUQe4BKZXs 5. Design Online Judge: https://www.youtube.com/watch?v=eg0nlYcbLpo

Feedback about Digital Cactus (the interviewer)

Would you want to work with this person?

Yes

How excited would you be to work with them?

3/4

How good were the questions?

4/4

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

4/4

1/4

Interview Transcript

Digital Cactus: Hello.

Aerodynamic Tortoise: Hello. Can you hear me?

Digital Cactus: Yeah, I can hear you just fine, I'm not sure why I cannot log in I'm sorry for being late.

Aerodynamic Tortoise: Yeah sure no worries.

Digital Cactus: So you are here for a systems interview right?

Aerodynamic Tortoise: Yes, exactly.

Digital Cactus: Cool. I have 3 questions before we start.

Aerodynamic Tortoise: Right. So the first one, I guess my name is Leon. I'm just currently a software engineer mostly in backend at Adobe. Yeah, well, I have been there for like, almost three years. Most of my background is in backend. Also, I did have some full stack and frontend experiencing, during my college time, but for now, just mostly back end development. For the level targeting by Well, I guess it's E4/E5 at Facebook. And my personal goals, definitely E5. Currently, I am L5, which is basically is dear to, at Amazon with the kind of promotion case targeting q4 at for a senior engineer, so pretty much on the way for the five E5 at Facebook.

Digital Cactus: Sounds like a plan. And the other thing is, if you've done any system design interview before

Aerodynamic Tortoise: Not really. I just, my first mock interview was actually today during the day with my friend, but not a lot of experience with the system essentially overall.

Digital Cactus: Well, as long as you have some, some prior experience, so you know, like, what's the framework you have to talk about. So that's fine, I guess. Cool. So before we start, I want to set up expectations real quick, right, so the interview is going to be 45 minutes at Meta. But the first few minutes is mostly about greeting or restroom break. Ultimately, the goal is so that you are not nervous. I hope you are not nervous right now so we don't have to waste those minutes, I can tell a joke if you want.

Aerodynamic Tortoise: No its fine.

Digital Cactus: I don't actually know any jokes.

Aerodynamic Tortoise: Haha.

Digital Cactus: So the actual interview itself, then is really just 35 minutes. Right. So now it's :07. Let's try to finish by :42 and use the remaining time for feedback, sounds good to you?

Aerodynamic Tortoise: Sure, sounds good.

Digital Cactus: Okay. So since you are between E4 and E5, I'm going to use the question that is typically use for the people in that level. So which is, Online Judge. I assume you've done leetcode before?

Aerodynamic Tortoise: Yeah, sure.

Digital Cactus: So I basically wanted to build that right, which is you know given a problem, then you can you know, submit code, test code, get result of submission, and so on, like all this stuff. So, basically, I want to send me online judge.

Aerodynamic Tortoise: Right. Sure. So we'll go?

Digital Cactus: Yeah go ahead.

Aerodynamic Tortoise: So before we will continue with the problem itself, I just want to set up some sort of agenda here. And in terms of how I see the interview going, so I'll just start with a kind of a requirements gathering. Then we'll just continue with some high level designing and deep diving into one of these areas, like scalability, availability and stuff. So actually, before we begin, I'd like to clarify the actual priorities for this interview like, what is the most...What are the parts that you're most interested in, in terms of technical design. Is it just like, scalability, calculations, all this kind of stuff?

Digital Cactus: I think in this case, what will be most interesting will be like, how are you going to execute the code safely? Because I could theoretically, you know, gives you like a malicious code after submission. And that, that might have like, any connections with the database, and I can theoretically drop the database, if I have like, you know, this this code. So the other one, I guess, is the higher level design. It's probably like less interesting. The particular deep dive like there is something that's pretty interesting. Other than that.

Aerodynamic Tortoise: Okay. So basically, as a CEO, we are mostly constrained on the security of the execution of the code. And overall, high level design, right?

Digital Cactus: Yeah.

Aerodynamic Tortoise: Okay, cool. So. Okay, cool. So then let's start with quickly going through the functional domain. So we seem like the users should be able to submit the code, and as a result, where they will get just a result of the submission rate. So as I understand users will just submit codes, and as a result, they will be just some sort of result for the submission. Okay. This make sense for you?

Digital Cactus: Yeah, sure.

Aerodynamic Tortoise: Okay.

Digital Cactus: Like what about like, actually, like listing the problem?

Aerodynamic Tortoise: This is sort of what was the Oh, you mean, like retrieval of the problem?

Digital Cactus: Yeah. So you might want to check out the problem as well, right?

Aerodynamic Tortoise: Yeah, exactly. Sorry what was it?

Digital Cactus: Yeah, yeah. Just this one, just you want to check out the problems, not just submit problems, just submit the solution?

Aerodynamic Tortoise: Yeah, for sure. So we'll just get the problem first, of course, and then will submit solution portrayed. So okay. And I believe that's pretty much it for the overall functional requirements, like, again, in the problems trying to solve it. Also it like, will, the user will write it locally, I guess in the web browser, right. So we'll just have clients based in somewhere in their like web platform or browser application right? Okay cool so then in this case, they will just get the problem read it and then try to create some local codes. And I assume they will execute this remotely. They will simply because in a code will be executed actually on the server state right.

Digital Cactus: Mm

Aerodynamic Tortoise: Okay, cool.

Digital Cactus: Can you just write it down?

Aerodynamic Tortoise: I think it's good on...

Digital Cactus: I'm gonna tell you why it's very important for you to just write down everything.

Aerodynamic Tortoise: Yeah, sure. Sure. I'm just clarifying to you just just make sure

Digital Cactus: It's number 5 for you.

Aerodynamic Tortoise: Okay, cool. Okay, so and then. Okay, cool. So and then so basically, for the other non functional things. Do we care about the scalability availability right now is all just to, we'll talk about later?

Digital Cactus: About scalability, you can talk about it later.

Aerodynamic Tortoise: Okay. And if we will...

Digital Cactus: You should assume you will have to write that kind of scalable system. But like, you know, you don't have to go deep into it at the moment. If that if that's the question.

Aerodynamic Tortoise: Yeah. So I'm mostly targeting trials...

Digital Cactus: Oh by the way. Let me also give you tips number seven for you, just in case so that like you know, like how to do timekeeping.

Aerodynamic Tortoise: So yeah. Yeah, exactly. So I'm just trying to understand the scope of the problem and how scalable we're targeting like whether it's going to be a small system or just a system that should support a large number of users. For now, I will just notice that it should be scalable and we'll go from this. And, like, less than the least, I should we. So my assumption is that when the user, so search of the problems should be consistent, so whenever the user should get the problem, and tries to submit the code, we actually probably will not store this code we just executed. So I'm curious about whether we want to do want to concentrate most on availability first, or consistency. And my suggestion would be here to be like availability, because we don't really have anything to, much data to consider here. So is it write down assumptions case, like availability over system several.

Digital Cactus: Sure, I guess.

Aerodynamic Tortoise: Okay, cool. So alright, so this case, I'm pretty much okay with the non functional requirements here. So do you have anything to add? Or am I missing something?

Digital Cactus: Again about the security, the non functional? Basically on server side but how do you do it safely?

Aerodynamic Tortoise: Yeah, so it will be securely secure. Securely executed right? Okay, so All right. So, do you want me to do any kind of estimations like traffic and what we're targeting in terms of the scale right now, or can we do later on ?

Digital Cactus: Yes Please.

Aerodynamic Tortoise: Okay, sure. So

Digital Cactus: You can do it later. But like, eventually, you'll have to talk about it.

Aerodynamic Tortoise: Yep, sure. So I assume that if we target in a large scale system, let's say we'll have you know, what 10 million daily active users does make sense to you. Overall?

Digital Cactus: 10 million, sure.

Aerodynamic Tortoise: So and let's say, for the stimulants, we will have a distribution of like, okay, 10 million users and we will have some sort of a, probably peak time between, I don't know maybe 5 and 8pm. Actually, if it's in a global system, we probably may assume that the traffic will be distributed equally, as let's say, at the peak time, we will have, like 4% of the traffic for one per two hours, right? Maybe some of the North America regions, between five and 7pm, most of the user, so who is actually using it does make sense for you?

Digital Cactus: Sure.

Aerodynamic Tortoise: Okay so in this case, if we have 10 million daily users 40% of two hours, then we say like 20% of a peak traffic will be within one hour. And in this case, if you multiply 20% to 10, millions, it will be just like 2 million per one hour, which is equal hour, reach kind of or equal to 2 million by 360. So we're targeting somewhere around like 600. Let's say overall traffic, like GPS, or GPS, like GPS, and GPS, combined. And we can talk a little bit more about the right versus rate, distributor ratio. So and I believe that in our case, we will have more sort of overwrites transactions to the service to submit rather than getting a problem. Or actually, it could be Yeah, it will be more like, let's say 60 or 60 70% submissions and 30% Since the submissions and 30% will be getting the problem, right. So and if we doing this kind of thing, then we'll say like, we are targeting around 420 TPS for all By submitting a problem and around 184 GPS to query the problem sets. Okay, so, so far, so good.

Digital Cactus: So far, so good. Yeah.

Aerodynamic Tortoise: Cool. So, yeah, in this case, what we can see is that okay so what we can see overall, this system doesn't have, we assume that it will not have very large traffic at the beginning, because 600 QPS this to be as kind of a manageable overall in the system, but we will still make it in there when we will create the system in a way that is going to be scaled for further traffic, okay. So as it for storage bandwidth memory, I'd like to estimate this once we are done with this some sort of data or storage models, but for the approximate things for bandwidth, especially because we're going to submit some texts, text to the service is assumed. Okay, so we'll just treat this as a some sort of a text. Let's assume that it will be on average, like for submission. It will be on average, I would say, like, 30 kilobytes from top of my head. And for problem statement, it will be somewhere around 10 kilobytes of text. Does that make sense?.

Digital Cactus: Okay.

Aerodynamic Tortoise: And actually, your problem statements here as well. Let's assume that we will have finally, maybe we'll have in our database, let's say 100k problems. Which translates to, multiplied by 10, which translates to 1 million kilobytes, which is kind of a one gig of data to store in terms of problems itself. Okay. So, so far, so good. So the basic storage, it's kind of a small, so it's cool. Not much of the DDB or storage constraints right now. Does this assumptions for three kilobytes per submission and problem makes sense to you?

Digital Cactus: That's per day, oh I mean per second right?

Aerodynamic Tortoise: It's, for now, I've just seen it like this is per problem like submission. 30 kilobytes per submission or per request, and this one as well. So in this case, what we're seeing is that if we have 420, TPS for submissions, it will be approximately 13 megabytes per second of bandwidth. And here, what we have is that we have 10 kilobytes, and 180 QPS. So it's around like 10 megabytes per seconds. And in total, we're expecting like, let's say 15 megabytes per second all bent. So it's kind of manageable overall based on this assumption. So it's not the system initial doesn't require a lot of computation or network capacity and computation in terms of traffic itself. But again, as I said, we will try to make it scalable in case if we will have more in the future. As for memory, we can just talk a little bit later once we define our cases and data models. So I'll just skip it for now if that's okay with you.

Digital Cactus: Okay sounds good, just a real-time feedback here. So you are going in the right direction and your explanations are correct, but you should have done this 6 minutes earlier. Sorry.

Aerodynamic Tortoise: Okay. Okay. Okay. Sounds good then yeah.

Digital Cactus: Going back to number seven. You don't have to keep asking me like, you know whether this is correct or not just keep going. If it's wrong, like I'm going to interrupt you.

Aerodynamic Tortoise: Okay. Okay. Then let's continue with The high level design. So I guess I will use the X colour drone, right. So let's start with the our client here. So let's say we have a client as a web browser. And then we will have client customers sending code to our service. And our service will actually have the let's consider the first flow of getting the problem statement. So let's say we will have some database with the problems. So initially, the flow will be like, customer sends request to the service, and then it goes to the database and it returns with problem right? Then second floor would be like, actually submitting the code. It will, the before will be pretty much simple as well. Client will just call the service and service will decode somehow and then return the result of the execution whether it's actually one more thing I'd like to assume is that the problem will be submitted and service will just respond with the like, either for hundreds if something malicious is going on, or Yeah, I guess 400 status codes are issued to people now. And then if something if everything is okay just respond with 200 with the some sort of a decision on the problem itself, whether it's successful or not. Now, let's continue with more digging. A little bit more. Moreover, how we will make this system scalable. So first of all, for our client service communication, we will just add an extra component like let's say API gateway, or actually one more thing I'd like to clarify, is it okay, if I just refer to some cloud services as an example of some system components?

Digital Cactus: Like what?

Aerodynamic Tortoise: for example, using lambda for several executions of the code

Digital Cactus: Sure, I guess.

Aerodynamic Tortoise: Okay, sure. So let's just start with the extra layer. For our scalability proposes, it will be just API gateway, which will be responsible for things like throttling, authorization, and load balancing assurance. So like, it will be just a first point of load balancing the traffic overall. And once we pass the throttling authentication stuff will go to the service itself. And we will either return the problem to the user or execute the code. So just a few things on actual security, if you'd like to discuss straight now, one of the things I'd like to consider is actually creating these two services, actually, all of those services in their own private containers, just to make it secure in case if we miss something, or in our submission, payload validation, shall we'll just create some sort of private containers for each of the layers we have. And it will be just like, the C# stuff like Virtual Private container, and for the separate for each of these layers. So the proposal this is actually just to make sure that if anything, something goes wrong in one of these layers, like a public, we're like, we will constrain what could go out of this container in what could go in. So for example, for this API gateway layer, we will say that inbound connections can be from any public resource, like maybe not from every public resource, if you both have our own sort of, so we will be able to check whether we'll be able to generate some sort of authentication tokens on client side in our web application. And yeah, so we will define some sort of a authorization there in this case. So we will say like, Hey, for these kinds of opposition, talking to or signatures, we will allow the traffic from those source points and then we will allow the outbound traffic only to this service, which will be responsible for computations. And for now, what retrieval of the problems we could further divide this service into two like service for problem statement service and so like this service and then we will have a separate one like problem or like code execution service service we also into separate private containers. So, and again like I said we will, for this particular code execution service private container, we will make it possible for inbound calls to be only from API gateway. And we will restrict any outbound connections if necessary. And actually, one more thing today just considered is that when we will execute the code, we will need to some sort of do some validation or testing of the code, right. So, in this case, we will actually need to communicate to some sort of database, which will contain a test set and with the with the input and expected output, right. So, for now, I will just create it as a separate database, actually, yeah we can just do one database for now. And we'll see how it goes. So, this database will be responsible for storing problem sets as well as problem. In part of this problem set for each problem, we'll have some sort of a test set with input and expected output. Okay, so All right, what else we can go through? Do you want to go deeper into the security stuff?

Digital Cactus: Sure, like, how do you how to go into execute that code?

Aerodynamic Tortoise: Yes, exactly. So in order to execute the code, we actually can create a query will be just too lightweight. And okay, so when we start executing the code itself, we will need to do some sort of code a verification step, where we will just make sure that we we'll just sort of verification for the malicious code. For example, because it tries to access some public resource or public resource or external resource, or execute some SQL queries, we will be, we will need to actually prevent the any of our traffic to anywhere because we assume that the code submitted for this specific problem will be just written as a function. And we will define for our clients that in order to submit the code you will need to modify you will need to implement some sort of function as defined in the problem statement itself. And in this way, we'll be scoping the codes which will be executed. And once we will try to call this code on the server side, we will check for we will basically constrain any external communication at first. And yeah, that's one of the security measures, we will also have some sort of a let's say coordinator service or backpressure inside of each of each server that executes the actual code. By saying that let's say we will allow this particular problem submission to be a to consume at most like let's say 5% of CPU proposed purpose on this specific causes executes the problem, and we will say that this problem cannot try and more than like, I don't know like 10 seconds as an example, shall be useful be just to replication will one of the a few verification steps, let me just write it down quickly. So we will bound codes to a specific function to execute will constrain all, constraint all networking for the for the problem. We will constrain Max CPU allocated for the submission, let's say submission to 5%. And we will constrain running time, like a clock time clock time for that submission, let's say 10 seconds or so

Digital Cactus: How are you going through this?

Aerodynamic Tortoise: Sorry what was it?

Digital Cactus: How are you going through this?

Aerodynamic Tortoise: Going through what's specifically?

Digital Cactus: How are you going to do this?

Aerodynamic Tortoise: Oh sure.

Digital Cactus: What is the means to get this actually done

Aerodynamic Tortoise: Yeah okay. So, let's say for bound code to specific function it will be just on the problem statement level, we will say that hey, you need to implement this function signature, then when we get the submission with the code, we will process the submission text and we will look for that particular function to be executed we can just compile it or do some sort of a finding of this particular function, right. So, for the network constructions, it can be done on different styles, it can be done in about an application level or networking level, we can just do it on VPC specific customization level or firewall, if you wish. So, what we'll do is actually we will say hey, for firewall settings, we will see that there is no permitted permitted networking connections from this specific function negation actually, if we do this on BBC level, we may still be leaking these db connection, if somehow the users will figure out how to connect the database, they will use this kind of a hole. In this case we will need to do it on the application level. So, we will say that whatever programme we use to run the code or like on operating system level will say that, for that specific process ID is going to run the submission we will restrict all the networking communication. So, and then, for the max CPU allocation for the submission, we may create some sort of a special engine inside of the service or we can containerize as a submission, the submission itself with the configuration of allocating maximum 5% of CPU utilisation and similar will go with the time constraints, when we have some sort of engine service like Engine service or internal engine for writing the submission, we will say that that particular submission may not run more than this amount of seconds. And this kind of configuration can be also dynamically distributed either from database or some sort of other dynamic configuration service, which can be either on per level or for some problem level defined for like a per host level defined. Okay. Any further questions for this?

Digital Cactus: How are you going to So, there is going to be an API. You're going to be calling around here and here. Right? Are they going to be synchronous or is it going to be asynchronous? Executing the code is going to take a while right.

Aerodynamic Tortoise: Yeah, that's true. So that's a good question. So there are two options to this like, synchronously and asynchronously in case we're going to do it synchronously customers or clients will be actually waiting for code submission to run and complete with some response, so it's kind of a viable option. The only drawback here is that we will sustain an open connection to the services to Pro to actually run the code in other options to do this asynchronously so and by synchronously What I mean is that the once the clients sense Oh, and yeah, so one more drawback of synchronous invocation is that it may be we may we this API gateway there and for the description service, they may be I highly coupled in terms of scalability. And specifically, they will be bound to the again, like maximum number of connections open. And as we know, like, for each Linux machine, it will, it could be around 60k open connections. But you if we go to the synchronous approach, we will do some sort of queuing here, so that we can offload the processing of the tasks to the workers. And those workers will asynchronously poll for this for those specific problems of submission. So, for example, we will have some sort of a message queue here, we will then send a task there, and workers on the service will be polling for it, for submissions to process them. So, once this processing is done, we could either notify the customer about the completion of this execution. So, let's just think about how we can do this. Okay, so, if we do need some sort of a cloud, if we have some sort of a web application on our client side, what we can do is actually, is actually. So, okay, I see, there are several options to this for a synchronous approach. So we can just send from our client application requests, you have a gateway, which will send a message to the submission to the queue. And then we will respond right away to the client, saying that, hey, we start your code execution synchronously. And do in queues for example, the ID for this submission or execution, right. So, then what will happen is that, workers will poll to, the message and will process this, and then we can have some sort of a separate queue, or even not a message queue or just Event Queue, which will be notified once this code execution completes. And this event queue, we can configure it in the way that this it will notify the client about the completion or client could do some poll to, for this event queue or in this case, it'll be more like a message queue. And to get this to check whether this execution has been processed or not. So, process of doing the push perm is that we will there will be less latency between actual completion of code execution and notifying the client code of our web application. The cons of this could be that we will need to store some extra data to actually know how to call how to communicate to that browser for the polling for the polling architecture we could we could scale the system more independently in case if we have a lot of executions, actually it should be prevented many case so, for the polling Okay, so for the polling will may consume extra resources on the client side because we'll in case if we're doing a short pulse, we can do a long pulse to register. Some sort of a backdoor, once the event is complete an event is managed to this execution or we can actually create an event stream directly from the event to service in the way that once the event is created for this execution to the central all the way back to the claim. So overall, I would go with the push small issue, just to make sure in case if we wanted to process those things as soon as possible. Yeah in another option is to do the WebSocket communication. So that we can just create a stateful connection to the to the server that actually expects for code execution. But in our case, it will be, I believe it will be just short term communication with the service. Not like we're just waiting for something. So usually, I'm just thinking into once more I think one point will be the best here. Because we doing the short term communication. We will not basically we were in like 10 seconds of invocation. So we can just do a one poll of 10 seconds. And if we do not get any responses from message queue, like Event Queue for this one, for confirmation, then we'll just say, hey, it's time out. So sort of a timing is exceeded. For that specific problem. There are drawbacks like networking delays, which could produce false false negatives. But yeah, it's one of the drawbacks, actually, for the polling. Does this make sense so far?

Digital Cactus: Yeah, make sense. Do you want to just quickly talk about API into schema? You are a little bit over time.

Aerodynamic Tortoise: Yeah. So for the for the API things. Let's start with pulse, which...

Digital Cactus: Just very quickly, you don't have to explain it, by the way, like you are already four minutes over time.

Aerodynamic Tortoise: Okay, okay. Sure. So for the submission, we'll just to do some sort of a rest pull is to be communication, because it will be better than our case, as we just aiming to, to create, like, overall generic communication between client and service. So we'll just create a post with the, let's say, submission, slash, the ID for this submission, or something they come up with from top of my head. But the thing that we will, is, as part of this post requests, we'll create a payload for the text, as it's going to be like pretty small, as we discussed before, it's around 30 kilobytes or so. So it should be processed pretty well as the post request is the position of your request. We will also submit like some sort of a metadata for authentication, as well as some problem IDs probably, or something that we could identify and map between the submission, payload and actual problems statement or expected test results. So as for the as for the getting the problems itself, it will just get a request for slash problems slash ID of the problem, which will return as in as a response, the problem statement, and a few examples for the problem problems actually, problem statement could include they'll see examples of test cases.

Digital Cactus: You don't actually have to explain it, by the way, like I just wanted to write down like API schema. Like you already six minutes over time, or do you want to just be done with this, and I give you the equal version. Obviously you know what you're talking about but like, it's, it's kinda useless if you talk about it beyond 35 minutes. That's what I'm trying to say.

Aerodynamic Tortoise: Okay, so are you suggestion, are your suggestions is actually just write it down right away.

Digital Cactus: My suggestion is like next time around, yes, you should just write it down right away, you don't have to talk about it, just write it down.

Aerodynamic Tortoise: Okay, I just developed this. Okay. So, okay, in case of these API's, what was your expectation overall, because when I started to do some sort of a CMS for API's, you said that I don't need to do so I got confused about it. And that's where I stalled now. But yeah. Sorry, was that?

Digital Cactus: When did you talk about the schema about the API?

Aerodynamic Tortoise: Yeah, just a few minutes ago, like in the end the interview itself, I started to talk about...

Digital Cactus: No I was just saying like you don't have to, you don't have to explain your solution. Just write it down.

Aerodynamic Tortoise: Oh, just simply write it down?

Digital Cactus: On the API, on the API. You don't have to explain like, you know, why post makes sense. Why rest makes sense. Just write it down.

Aerodynamic Tortoise: Okay, so like just writing it down?

Digital Cactus: Yeah, exactly.

Aerodynamic Tortoise: Do I need to think out loud? Or I can just write it down that's it.

Digital Cactus: Most, thinking out loud is fine. But most importantly, just write it down. Okay, have you read my, my tips? Number five. You need to process all discussion. Like, it's more important when you're talking about,

Aerodynamic Tortoise: Okay, okay

Digital Cactus: Like, whatever, whatever the interviewer is going to get after the after the session, right? It's just going to be your writing, they will completely forget whatever you talk about, like completely a single thing that you've talked about, they will forget. So if you have any option between like talking or writing, choose writing.

Aerodynamic Tortoise: Okay, okay. Yeah makes sense then. Yeah okay, sure. And it's a good note. Okay.

Digital Cactus: So the things like things like here's your solution, right? You do everything right. But your time management is kind of awful. Right? And I have given you several tips in the between how to do time management better. Don't Ask, Don't ask questions to the interviewer. Just keep make just keep driving the conversation. If it's wrong, the interviewer will let you know if it's wrong, right? Why this is important, because you only have 35 minutes. And then, and then again, like because of this, right? Because because you're going to get into some some areas or whatever. Like, you end up you didn't have the chance to talk about it the AP and the schema? Like what is the relation between like the problems and the test case? What is the relation about the problems and the submission? What is the relation between the submission and the test case? Right? Three things are very important for this question. Right? Sure. The code execution is very important, which is I give you the credit on like, what went well, in point four? And in the interviewing.io by the way, like, I give the feedback here, in the intervening.io reader, I'm not sure whether you see it or not. But so I give you credit for like solving the primary problem that needs to be solved. Right, but you didn't check all the boxes, like the fact that like you didn't even cover the it's a good complex solution and components with this. But you have to kind of like go to the API schema, especially for this question, because they are asking why it's going to be very important, right? Is it going to be the API might not be that interesting, right? It's just gonna be like a two API, of course, and like get get on the maybe three, posting, posting the submission, getting that submission ID, like the primary if you're using calling, as you mentioned before, and like getting the problems, right. But that's schema within like, the relations between like, all these different entities, right? How is the submission correlated to like best case, especially why is it important is because you need to know what you have to pass through your content, right exactly?

Aerodynamic Tortoise: Yeah. Yeah, exactly. Okay.

Digital Cactus: Which I want to bring up one point, right? In your drawing, right? If you want to do like a compromised surface to execute some code, you got to split it up, right. So this is like, you know, container. Right executor. So why is this important is because, as you can see, this containerized executor doesn't connect to any database, your code execution service connect to the database. Like, for example, right, you can get like the, you know, the, you can request a submission ID, and problem ID from the equations and success. And then you can get like the actual code, input, expected output. So what's going to happen instead, like, you will pass the code input output into contract executor, yes, you can see that this executor will know what it is to do without actually connecting to the database. And this is where you secure this, right?

Aerodynamic Tortoise: Yep exactly.

Digital Cactus: So you gotta make it super clear of like the data flow, right? Sure. It might be super clear on your on your, in your head, right? It's kind of like apparent from like, whatever you're writing here, but like interviewer is not mind reader. Like I seen this problems hundreds of times. I've seen this interview like 1000s of times. But like, you gotta tell me like, exactly like what's happening here, right? Especially the data flow here, right? How are you going to make it exactly secure? Well, you split it into separate containers. And you actually only pass the necessary information, you don't allow the container execution to talk with different keys to talk with the message queue to talk with database like you just don't allow it. You have like some kind of manager to do it for them. So that's how you secure it. Right?

Aerodynamic Tortoise: Okay. Yeah.

Digital Cactus: But overall, like you solve the puzzle Well, right. And that's why I still give you a higher E4. But ultimately, the biggest the biggest issue to getting you to E5 is just the completeness of this. Right? The fact that you don't talk about it, that API, you don't talk about the schema. So I will say not bad for, you know, your, your first, you know, real time on system design, right? But you really need to update your time management, right? You don't have to keep asking questions to the interviewer. Like the interviewer, like, I've been doing this like hundreds of times like, we want to use to kind of like drive the conversation drive all your assumptions, right? If it's wrong, like, we'll let you know.

Aerodynamic Tortoise: Okay. Okay. So basically is understand the approach will be I'll just write down my assumptions and how I actually considered considered my consideration about the system itself. And then if something goes wrong...

Digital Cactus: Exactly.

Aerodynamic Tortoise: okay, good, okay. Because when I was like...

Digital Cactus: Exactly when I see like whatever you have written here is quite clear, right? Like, they the interviewer will be able to see like, Okay, this is this was what do you consider during the interview? And then like, at the same time, like, for example, if the interviewer has to kind of like, take a look a little bit and think, Is this going to be is this going to be an issue during the system later? Because like, there is really not just one particular solution like, and there is no just one particular problem statement, like, you know, in your non functional requirement in your numbers, you could have come up with different numbers. For example, one candidate can talk about, like 10 million BAU. Other candidates can talk about 1 million BAU. Other candidates talk about 100, KDAU. That was like different implication. And we will love to see that right. We like, I don't want to use my number. I want to use your number. Right. So don't ask me a question.

Aerodynamic Tortoise: Okay, good. Okay. Yeah. Makes sense. Do you have anything else to talk about here?

Digital Cactus: I think the other things is, so this is it. Right? So I think you do well on like calling out API gateway. So that's good. I thought I put it into the back. So here's the thing, like, if you do it, if you if you were able to kind of like manage your time better here, like there is even a possibility for you to get an effects, at least on a system design, even though like it might be impossible, because you've been a little bit off E4 and E5, but you know, with with this, with this details, it's all of this different deep dives that you did, right? It is actually possible to give you respect, I mean, not for this question, because this question is for E4 or E5 calibration for different questions, if you talk about like this kind of feedback is good enough. But you want to check all the boxes first, before you go deep dive check all the boxes first, API and Schema, do not forget about them. It means this functional non functional requirement, except to be exact, like this is what you this is the timing that you want to fit, right. What I mean by 123 is like so I'm going to give you the framework, so very similar to yours. But this is kind of like the the framework that I have in mind that I typically teach my candidates, so fairly similar to yours, right? But like, we just want to make sure that they are functional, non-functional. And numbers extend minutes. You did it in 16 minutes. 17. Actually, you want to do it seven minutes faster. How can you do it? Don't ask questions. Just keep making assumptions.

Aerodynamic Tortoise: Make sense? Okay.

Digital Cactus: Also, in terms of property numbers, you can do it like really quickly by doing this. And then yeah, one last thing. Number eight, your biggest enemies, it's not your technical skill, your technical skills is to be fine but it's time. Remember that you only have 35 minutes. And because of that, I strongly suggest you to watch YouTube videos because YouTube videos are time bound. So you will know like, okay, at minute 10 What should I talk about at minute 15? What should I talk about at minute 20? Right. So you know, like exactly how to manage your time better. So that's why I would recommend you like YouTube videos, I give you a list of this. Right?

Aerodynamic Tortoise: Okay, cool thanks.

Digital Cactus: Otherwise, I think you are good to go.

Aerodynamic Tortoise: Cool. Yeah, I'll definitely will try to make it faster. It's actually the same kind of feedback I got from my friends because I saw that I spent too much time on requirements itself, but it's more about these... So the reason why I spend so much time is based on my kind of expectations from the interview. And what I read before before about this interview is that it should be communication. So that's why I tried to make it more of a dialogue rather than monologue. So probably it's a mistake, okay I got it then.

Digital Cactus: The dialogue part should be like on the solving part, not about the, not when you are getting the requirements. The other thing is like, you could have talked about high level design API at the same time. Don't miss that. So when you start with API gateway, start talking about, you know, hey, I'm going to use posts, and then this is going to be like a Submit, and then request is going to be something like this response is going to be something like that. Right? And then like, when you when you hit this Event Queue, for example, I'm going to get like, you know, submit shell. And submission ID, for example, right now, well, my required, it's going to be something like this response is going to be something like that. Right? You can do it like fairly quickly this way. Exactly during the during your drawing, you don't have to split it into separate session. This is going to be making much significantly more clear compared to like, if you split it into different different sessions.

Aerodynamic Tortoise: Okay. Yeah. Makes sense. Okay, cool.

Digital Cactus: And you will save like, 10 minutes time, because you're doing it.

Aerodynamic Tortoise: Yeah, that's true. That's true. Okay, cool. Yeah. Definitely lots of feedback. Useful feedback. Cool.

Digital Cactus: Any last question? Before we end the session?

Aerodynamic Tortoise: No, not really. So in this thing, once we end this meeting, I will be able to access these notes right. I just want to make sure.

Digital Cactus: You will be able to see everything.

Aerodynamic Tortoise: Okay, cool. Cool. Cool. All right, then. Yeah, I'm pretty much got a good experience here. So thanks for the time. Yeah, for the feedback for sure.

Digital Cactus: Cool all right, man. Good luck with your practice and your interview as well. Yeah.

Aerodynamic Tortoise: Thank you very much. Have a nice day, bye.

Digital Cactus: Bye.