Interview — 2026-09-02

Hey.

Can you hear me?

I am. Good afternoon.

Awesome. How's it going?

It's going all right. I hate doing interviews, I'm not gonna lie.

All good. All good.

Hello. On the rack and you know how it is.

No, it's not good. I'm the same way, so. Make this as seamless as possible. Don't worry about that. Yeah, so I guess since we started a little late, I'll definitely give you that time back. Don't worry about that. But yeah, I guess how this interview will go is we're just going to do some quick intros, like a 10-minute intro. And then about 40 minutes for the system design. For the rest of the time, if we have time, we are going to use some kind of AI agent to maybe try coding it out and see. If your system design could work. Does that sound good?

Sure.

Awesome.

Uh, just to clarify, this is about to be like an hour long, or that's— it's expected to be about an hour long?

Yeah.

Okay.

Exactly. Cool. Let me give you— yeah.

Um. Yeah, I was gonna ask, do you mind if I drink something, uh, while, while I'm doing

Totally wait. Yeah, go for it. Yep. Cool. I guess I'll get started on the introduction. I'm Ryan and I work with Hee on Tacit Awareness. We're a recruiting firm and we're recruiting for Ascent, which is a request recording platform for gamers, and then they send that data to power world models. I guess before that I worked at Google and Amazon and also Apple. And I also, I guess, went to med school or I dropped out of med school. So we're looking for like unique talent. And we thought you were a really good fit for Ascent, so that's why we're here today.

Yeah. Can I ask what med school you went to?

Brown Med School, if you're familiar with the Brown pre-med program.

Oh, no way. My, my, uh, my buddy's going there right now.

Oh shoot, what's his name?

Uh, his name is Jason Nguyen.

Jason Nguyen. Okay, okay.

I think he graduated in '22 from Berkeley and then went into med school.

Oh shoot, okay, okay.

Yeah.

All right, I'll definitely shoot him a message, I guess. Yeah, that's awesome.

Maybe, maybe, you know. I would imagine there's also a lot of Jason Nguyen, so maybe you're thinking of the wrong one.

It's a very common name. Yeah, yeah.

Yeah, I'm not sure how much you have seen about me, but I guess small introduction about me is my name's Seth. I graduated from Berkeley studying data science and economics. And for about the past decade, I've been kind of running my, my own company.

Okay.

And she's doing contracts here in the Bay. Actually, it doesn't pertain to the Bay, but most of my clients are in the Bay. I've landed some pretty big people and contracts, some under NDA, but I guess the ones I can say is I've worked with I've worked with like Google Gemini and I worked with Facebook Bard and all that. Mostly my contracts are in like the human data aspect of it, but I've done some more higher level stuff on some other contracts.

Yeah. Oh. That's awesome.

Yeah.

Cool. Um, I guess. Since we're done with intros, let's get straight into the system design. Um, are you— have you ever done system design interviews by any chance?

Yeah, I've done quite a few.

Okay, perfect. I guess like you're pretty familiar with how it goes. I'm just going to send you— I'm going to paste a Codepad in the chat. Let me know when you can see it.

Yeah, most of the ones I do are in person, so I normally have like a whiteboard and stuff.

Oh, okay, interesting. It's fine, we can, uh, we can just talk through it, um, high level and jot down some notes.

Yeah.

Cool. Do you see the screen?

Cool. I do.

Awesome. Does it let you type, by the way?

Uh, yes.

Cool. Awesome. Okay. So I'm just going to delete this. Um, let me see. We're not going to code here, so. I don't need to worry too much about. Language. Um,

Had me worried. You put up the Python 3. I didn't know.

No, don't worry about it. I wouldn't scare you like that. Let's see. Um, I guess we could just type, type in here.

Where's the whiteboard? Uh, drawing mode. You see that?

Oh, did you want to use the drawing mode?

I mean, if we're doing system design, I sometimes I like to draw out systems for like what I'm talking about.

Oh, okay, interesting. Yeah, that— I mean, whatever, um, works for you. That— okay, I can see it. Cool.

Okay. We'll see.

Yeah.

So

So I guess I'm going to paste the problem in the editor here.

The code editor, yeah.

Yep, so let's see. Okay. So I'll just give you like a couple minutes to read it and you can ask me any questions.

Let's see, when it goes to design a simplified version of a sense gameplay recording puzzle like the other one we shot. Okay. Um. Okay, a couple questions.

Does the user need to be able to edit clips? So if they record like the last 30 seconds, do they need to cut 9 seconds out of it? Cut the last 9 seconds out of it. Like, would they need to be— does the system need to be able to like trim clips or anything like that? Oh, I see what you're saying. I guess let's just say for now, no, but like the user needs to be able to like create clips from the video. Clip segments. Um, And when it says upload video on demand or upload clips of their gameplay, I assume they press a hotkey, it records the last 30 seconds. Does that upload right then and there or does it upload when they want to later? Does it upload while they're still playing the game or later? Yeah, I guess like that's up to you to decide, but I guess like the, um, what needs to happen is that when they finish the entire recording at the very end, like it should be saved somewhere so that they could view it later. Um, okay. And I guess like I just want to make sure that I answered your other question for the— with the clips. So like, I guess like what we're kind of thinking here is that there's 2 types of different videos that needs to be stored. First is like the video on demand that we're talking about here, and then there's also like a hotkey. That you kind of mentioned with for clips. Where you press the button and then it records like from the start to that point that they press the hotkey on, if that makes sense. Mm-hmm. Okay. Okay, I guess when I first dive into this, I mean, I guess the first thing I want to do is list the functional requirements of this app versus the non-functional requirements. Okay. Um, So some of the functional requirements that I see from this app are users should be able to save the last n seconds of gameplay. Uh, by pressing a card key. Yep. Users. Should be. Able to upload. A clipping get. Uh, Or upload a clip. Do they get like a shareable link, kind of like Metal? A shareable link at the very end, or what do you mean by that? Like, um, Like, I don't know if you've used Metal, but I'm just more familiar with it. But like, for example, when they clip something and they want to share with friends, they get like a shareable link. That in this program because I don't see a mention of other people watching their clips only themselves. Let's just say for now we don't, but we could also add that later if we have time. Okay, so users should be able to upload their clip. Users. Should. Be able to browse and delete their own clips. Um. And then users should be able to save bots. And users. Should be able to upload their bots. Um. That's the ones I can think of now. Maybe I'm missing one, but we can come back to that later. Sure. For the non-functional requirements, I think that the most important one is probably the system. Or the app should not cost. Any lag and frame rate or minimal lag should not cost. Or should cost. Minimal. Frame rate, lag. Probably the most important one, just because if you have any lag, the user will probably just uninstall the client. Um, uh, Uh, the system. Should prioritize. Durability over availability. Um, and by that I mean, uh, it is much worse to lose a VOD or a clip of a client than it is for the system to be down for like 10 minutes. Yeah. So I think it's more important that we have 100% accuracy in recording the client's VODs or clips than it is to Um, be up 99.9% of the time. Yep, that's a good assumption. Um, Uh, there's gonna be a lot of data. A lot of data in this, so, and most of it's probably not going to be watched. Like, um, I don't watch every single VOD that I have or every single clip that I, that I have. Yeah. So the, the system should stay economical. Assuming Most clips or VODs do not get watched. Um, Sorry, what do you mean by economical here? So, uh, like having a bunch of video, yeah, um, and a bunch of clips and a bunch of, uh, VODs is like really expensive. It is, yeah. Uh, how expensive it really is. So a good example would be A good example would be like, for example, It costs time and money from the system to have multiple different encodings of the same video. Yeah. So a common thing is when you load up Metal, you can watch A clip and then you can choose, is it 480p, 720p, 1080p? Yeah, it's really expensive to host all of it at once. Yeah, most of that wouldn't get billed unless, uh, the clip gets watched, you know, at least once. Right. So there's no need to build that. We could do like a lazy, um, adjusted bitrate ladder. Uh, until like the first view. Got you. That makes sense. Think like small optimizations like that. In order to make it less expensive. Yeah. Another good example is clips that get watched a lot could stay in hot object storage and then the ones that maybe are Yeah. Makes sense. So that's kind of what I meant by it should stay economical. Um, I don't know how important this is to Ascend, but I think that it's reasonable that— so people want to record games. And so I think that's a good thing to do. Is that I think that clips should be able to still be clipped even if the app or your GPU crashes. Mm-hmm. So I think that that should be a non-functional requirement because I think that that could be an important aspect. Again, if a client's game crashes, They'd want to record that and not just lose it. Yeah, yeah. So I would say that like clips should be like, I would even I wouldn't say that it's recordable or catched. Cashed. Even if the game Crashes. Or the game GPU crashes? Yep. And uploads. Should be resumable. Even if. The clients. Internet. Or even if something interferes. I think these are. Pretty basic. Functional and non-functional requirements for an app like this. I can't really. I mean, again, maybe I'm missing a thing, but I think that I can go back to it later if I am missing something. Um, So. Um, yeah. Where would you like to start next? Do you mind or just kind of— Yeah, I guess like where are you thinking? Do you think that these are enough requirements to think through like the actual design, or do you think there's extra things that we might need to consider? Um, I guess the only thing would be maybe like the text when the user starts playing a game is probably one that I didn't capitalize on. Um, I'm not actually too familiar with the Sense actual product. I haven't used it before. Yeah. So I might be missing something there, but most of this should cover Recording their gameplay, uploading. Video and clips. Yeah. Storing these video clips and like video pods clips and game information for them to watch later. I think that most of this should essentially cover it. Yeah, I guess for the detecting a clip. That would probably be in a functional requirement, but the text when the user starts playing. Yeah. We can just assume that like. When they start playing a game, we have some internal tool that can detect that. You don't need to design that. Detection system. So. Yeah, there's a couple— just to quickly overview it, there's like a couple ways to do it. Probably the, the. The easiest way to do it is just to look at current processes, but. Yeah, I think most other, like, Metal and all that have preconfigured settings for most popular games. Yeah. Like, are able to detect them. Yeah. Um. So. I guess to start. In terms of like being able to record the last seconds of gameplay and seconds of gameplay by pressing a hotkey, yeah, I think one of the biggest things that Has allowed this to happen is that we are able to encode video straight from the GPU. Yeah. Um. I don't know if that's out of scope for what you were looking for, but it does talk about like the creating paths for clips and stuff like that. If you could advise me if that's like out of scope or that's what you're looking for. Yeah, we just want you to Like kind of design the API layer that would potentially get that done. You don't need to worry about like, um, like if it's done through the GPU. Oh, okay. All right, if I don't have to worry about that, then we can skip that. But yeah. Just being able to do it through the GPU is much better than doing it through the CPU. And that's the only reason why we can actually do this without causing huge frame rate issues. Yeah. So I guess that's kind of this one already completed. The minimal frame rate delay is actually all done through the encoding on the GPU, just passing a pointer essentially. Okay. Yeah, we can also go back to that if you have extra time, but just want to make sure you have enough time for the key components and stuff. So I think that there are 2 essentially main databases that the client has to deal with, right? They either have to deal with where do they store their metadata and then where they store their video. Yep. And so I guess I can start drawing. Can you see my drawing? I can see your cursor. Yep, I can see it. Cool. So I guess a big thing is The client desktop is pretty important in this. In this kind of system, right? This is where everything kind of lives. This is where they— it's their hardware that they're recording. It's initially stored on this piece of hardware. I'm trying to think of like what else. But it's, again, this is like the kind of like the main system, I would say, of of this, and then it connects to 2 main things. So it connects one to the API. So I can send arrow, I can do squares. And it connects to the API. And so this is in charge of essentially where they upload their metadata. Okay. You know, this is connected to another database. In this case, I would probably say like a Postgres database, and I can explain that in just a second. That'd be great. Yeah. And then this is also connected to And object storage. So this is the whole, like, obviously all their videos and stuff. And so What I mean by this is you don't actually want to route any video through your API because that's very, very expensive. And, uh, Sorry, it's very expensive and it will cause lag in other aspects of your service. Okay, uh, when you're uploading, I mean, let's just say, so you gave me an example of Uh, where is the scale? 200,000 monthly active users, 30% of them record any given day. So we're talking about 60,000 daily active users. And even if we assume like an hour per user with VODs and clips recording at source, so like 1080p 60 FPS, we're talking So we're talking like something absurd, like 50 gigabytes of video per user. Uh, that, that would be routed through the API. So, so routing through the API is like really bad. Uh, what you— they would probably do. Is they would, um, They would post. To. Um. They'd post to the API. The API gets, using credentials and stuff, gets signed URLs from the object storage. Those signed URLs from the object storage get sent back to the client where it gives them like a direct access to upload straight to object storage with their videos and stuff. And that avoids us going through the API. And then Postgres is going to hold our actual main schema for a clip. So if you know. If you want me to draw the schema real quick, but like we'll have clips and then we'll have like, you know, clip ID, we'll have owner ID, we'll have. Duration of the clip, we'll have created at. We probably have uploaded at just to keep a track between when clips are uploaded to and clips are created. We'd probably have I'm trying to think what else. They probably want a storage key. Like some key that allows us to know where it is in object storage, because that's our main thing for viewing the clip. And then if we want to, I don't know if we want to. Prioritize. Straight up deleting it, or we want to prioritize soft deleting it so that we can run, learn from that data. But you could also have a deleted_at, which is just a variable that would show if it gets deleted and if it does, I think we can do that. We can do that. We can do that. And then we can also do like a delete event as well as like when it gets deleted. But, and then like, you know, we can either archive these, the ones that get deleted, or we can like keep them for a little bit to learn off of them and not actually delete them from our, from our system yet. Cool. Yeah, that sounds good. But again, the main thing I want to say is the client desktop, it records this gameplay footage, it gets sent, it posts to the API, the API gets signed URLs using credentials from the object storage where they can upload the video directly and the rest of the metadata and things from, from that get sent straight into Postgres. And the reason why I chose Postgres is just because versus something else, like I think MongoDB would be fine as well. Sure. But the thing about Postgres versus things like, I don't know, like DynamoDB or Cassandra, Andrea, is that I don't think that we're at the right point. Like, we're not actually writing per second that often. So I think that Postgres wouldn't be overloaded. I think that I would only consider switching if the writing index starts affecting the latency, but really I don't think that we are like, we don't have that many writes to warrant switching over to something like Cassandra or something more known for their writes per second. Yeah. So I think that Postgres is completely fine. Until we run into any issues. But even then we could like talk about like sharding and things like that. Okay, interesting. And how are you storing the videos versus clips? Is it all under the same kind of Entity, but just defined by the duration. Is that how you're storing it? Yeah. I mean, my idea is that if we are able to determine the duration of it, then that is able to easily determine whether it's of I think that the main thing is that you can a complete VOD versus a clip. Archiving them completely, right? Things like that. But yeah, my general idea is that the duration would be able to tell us. You could just have a straight up variable that says is clip. And it's like, I mean, you could just tell like whether a hotkey was pressed to save it or whether it's just saved because it's running in the background. Sure. I think either one is completely fine. Yeah. But either, yeah, again, either one's completely fine. Okay. Uh, Yeah. Um, Yeah, I guess like one thing, have you thought about was like, um, when we're sending these clips to, let's just say the object storage to store, are you storing the entire clip? Or how are you like storing it in the object storage? What do you mean? Like, are you putting it just as like an MP4? Well, I mean, like ideally you would probably put it as like the actual, like you don't need to put the complete wrapper in it. Like you could just put like the codec in it. Yeah. Yeah. You could even do something like running AV1 on certain systems just to further increase efficiency. But no, you don't need to store entire MP4s. That's pretty inefficient for If we're like, there's no need to host a complete wrapper of the video. You just need to host the codec of the video to understand what's actually there. Okay. So I guess like before it goes from the client desktop to the object storage, it goes through some kind of like encoder, right? Well, yeah, but that's, uh, that's through GPU encoding. Like the encoder is in the GPU. Oh, okay. Got you. That's why I was like asking about it earlier. So at least from my understanding, the only reason why this is even possible is because of things like, do you know NVIDIA NVENC or NVENC? No, not really. Okay, so NVIDIA NVENC is a GPU encoder that That obviously like encodes frames. Straight on the GPU. Yeah. So what the GPU has is a GPU texture that captures frames. Okay. So kind of like a software recording. It's a little bit, you know, obviously more It's pretty basic, but it captures these frames and then you pass the pointer directly into NVIDIA NVENC. So we're talking about like normal CPU encoding stuff is like 20 to 30% frame rate lag. So if you have 100 FPS, you'd have like 70. But with NVIDIA NVENC, because you're passing so little data through And so if you have a lot of RAM, you would actually only have like a 5% loss or something. Oh, okay. And so that GPU encoding already happens on the client desktop. You don't actually need to do anything outside of that. Gotcha. From my understanding. Yeah, okay. I mean, I'm sure you know more about this than I do, but I trust you. I think the fact that you're thinking about this, um, I think that's great. Um, also another thing, are you thinking, did you also consider the reliability part or like the, like what if like the app crashes and then like where does that, how do you handle like app crashing? And then you still have the clips for the client. Yeah, absolutely. So in terms of the app crashing, now my biggest thing with this is I'm not actually sure how efficient this would work on pods. Okay. Yeah. What you can do is instead of just having it on the VRAM of the GPU, you can actually save it to disk because most of these clips will be around 30 seconds in length. If I do like quick bitrate calculations, It's like 1080p 60 FPS clips are like 10 megabits per second. It's about 30 seconds. Yep. You have about 300 megabits. You have about 40 megabytes roughly of clips. Okay. In this 40 megabytes, you can save that to the disk simultaneously. Sorry, maybe I should explain how I would determine clipping. It'd be like a queue. So it'd be like a buffer, like that's a circular buffer. That makes it so that this is the last 30 seconds. And time moves forward. And every second that's added at the front, this end gets cut off. Yeah, that makes sense. And so because of that, there's only about 40 megabytes that's actually being stored in terms of the clip. They should always be running. Okay. And in that 40 megabytes, they should just be kind of And then we also have a buffer at the end, which is essentially a buffer of 40 megabytes. So we're able to it to disk as well. These 40 megabytes to the disk is essentially nonexistent. So it'll only record the last 30 seconds of gameplay. Awesome. Okay. Yeah, that's exactly what I was looking for. So you have like a queue before, like a queue, and every time you clip it, it goes into the queue, and then the clips in that queue go to the object storage and the API, right? Yeah, I think it's important that the disk is in that system as well. Because if it's just straight up in the queue, that's only living in VRAM and on crashes that would disappear. So you need to actually have it living in the disk. Sure. Otherwise, unless your disk also crashes, like your entire computer crashes and then you can't do anything. Okay. But if only the app crashes or your GPU crashes, you would still be able to save the clip if it's living in disk simultaneously. Okay. I think it's like very minimal in terms of like— Interesting. Okay, that sounds good. So I think for the most part, let me go over this. That goes over saving the last second. That goes over uploading, unless you want a little bit more about uploading from me. Browsing the leaks, really simple. I mean, you would just have essentially the ability to view the clips based off of Owner ID and then just be able to delete them, like an auth for the user to delete them if they're like the owner. Very simple, something like that. Okay. Saving VODs. I think that my system works really well for saving clips. I think that VODs are slightly larger than I was anticipating for this type of system. Okay. But I think that technically this system should work with saving VODs as well. My only worry Is that saving VODs takes a lot more VRAM than saving clips does. But I think that because it's constantly recording anyways, That like, because the GP is constantly recording anyways, I think that VODs are covered. Mm-hmm. We haven't really talked about the uploading parts much. Because I asked the question whether they should be able to upload during game or whether they're uploading during gameplay or whether they're uploading later. Yeah. And I don't remember your answer. Can you repeat your answer? Yeah, I guess like they just want the clip or the VODs at the very end. It doesn't really matter whether it's up to you whether you want to do it during the gameplay or whether you want to do it at the very end. I think just doing it after the gameplay is much easier. If you do it during the gameplay, you have to consider factors like how much— we have to throttle how much upload is actually happening. Because they're playing a game and you don't want to interfere with that. So you have to throttle how much upload is actually happening. You have to think about how much video you're actually uploading. And then you have to also be writing to disk how much You want to make sure that they're not uploading too much. So how is possible is a lot more complex than just saying you can upload the clips after your game is done. Sure. If they do it after the game is done, then we no longer have to really worry about throttling. Crashing because the clips still live on the user's system. Things like that. Sounds good. Do you have a— is that fine with you? Yeah, that's fine with me. I mean, we can also go back and design it differently if you wanted to, but let's just cover some other components first. Do you, like, how is this API being called? Like, what do you imagine? Is this like a POST API and also like what's being inputted into it as well? Yeah, so it's gonna be a POST API. Things that would be inputted into it is— I can just write this out. Yeah, that'd be great. So it'd be a POST, like clips or something. Okay. And then what would be inputted into it would be like clip ID, game ID, like things that the server cannot know, right? Like what game it's running from. What clip it's running from. Or what the clip ID is, sorry. And then essentially it would get returned. The other things that I was talking about. So it would get returned signed URLs from the object storage that it needs to upload directly to object storage. Um, Sorry, I'm trying to think. It would get returned like uploaded at, which is like the time that it would be uploaded. I guess this would also send created at. Because it's like authenticating the user, there'd be like the owner ID, things like that. So it would just be a POST API. Okay. That's straight at the— that is at this API. That makes sense. I guess like, let's just say that, you know, I guess in the beginning I told you that the user would save the last n seconds. What would change if like the user needs to save, let's just say there's 2 hotkeys, like a start and end. How would that change the system? Um. So instead of, instead of a hotkey that saves the last n seconds, there's like a start and an end. Yeah, exactly. Yeah. Well, I guess then the queue buffer would have to be changed. It's no longer like a circular kind of ring. It would just be like a start recording here, end recording here. Yeah, I mean, okay, I think, I think the rest of the system should be fairly similar. Again, I think this system would work for both VODs and clips. Yep. Uh, I can build it out a little bit more. Sure, I guess I can do like a full— so like here you'd have like a job queue. And then when we have like, you'd have a, like a, this would be like where we do the like lazy ladder, like kind of transcode. Yeah, yeah, yeah. And then you'd have like, this would be connected to an event handler, like when people like view it and things like that. Yeah. So this is like an event handler. And then the client desktop also has to be connected to the event handler because it can do things like view its own clips and such. And then this would also be connected to a, let's just say a viewer. Mm-hmm. And then in order to actually view the clip, you would actually have to connect this to a CDN that sits in front of object storage. Because you don't want to actually people, like you don't want people getting into object storage directly. That's pretty bad. Yeah. And then this would, I don't know how to do curved lines, but this would, if there's ever like a cache miss or something like that, it would have to point back to object storage. And I think that this would roughly be the entire system. So you would have to have a CDN that sits in front of object storage, and then you would have to have a CDN that sits in front of object storage that would have to point back to object storage to access the files or the transcodes that you created. But just to go through it real quick one more time. Yep. So you record on the client's desktop for N seconds. Sure. So you save the clip or a pod or whatever, and then you call the API. This API creates signed URLs using credentials from object storage. It returns that back to the client. It saves a bunch of data about Where this clip is from, how long it's from, when it was created, when it was uploaded. And stores this metadata inside of a Postgres database. From this object storage, it gets a job queue. To. From this object storage, it gets a job queue such that it can be, you know, we start creating a viewable kind of experience for the user. Most of these clips will not get viewed at all. So I think it's important to mention that we don't do expensive things like transcoding it multiple times unless it's a popular clip or clip That gets viewed multiple times, which is why I connected to this transcode. So on the first view, it would transcode in another 1080p, 480p, 720p, and that would save probably about 50%. So it's like 80% of storage itself, and then this gets stored back into object storage if it's a popular clip. If you are a user and you want to view the clip, then you need to contact the CDN, which sits in front of object storage. The CDN will give you essentially a viewable signed URL, and then you're able to look back into object storage. Awesome. I think that that should be roughly the system for most of it. Just to go over. App should cause minimal frame rate delay. I talked about that with the GPU. The app should prioritize durability over availability. I talked about that with saving the clips to disk instead of straight up to RAM. Yeah. Should say economical. I talked about that with With the transcoding and other object storage possibilities, like saving in AV1 instead of H.264, depending on whether the hardware requirements are met. Clips should be cached even if the game starts GPU crashes. I'm saying cache to disk. And then upload should be resumable even if something interferes, and I think that's also saved. Yeah, you could. Oh, with uploads, I think a small improvement that could be done is I was talking about getting signed URLs back from the API once it's called. I think that you should actually get multiple of them. So like a 30-second clip should have like 6 of them so that you can upload the clips in parallel in chunks to the object storage. Storage, and then we can save the the we can save that also to disk because that's also very minimal minimal. But save that to disk in case it comes to a crash. And it doesn't get lost. You can resume upload. I think that this is especially important for something like AVOD, which takes forever to upload. But again, you're able to just save it to disk so that even if your RAM crashes, your VRAM or whatever RAM crashes, you are still able to resume uploading. Awesome. And then again, uploading in parallel chunks, which is more efficient than trying to upload over one signed URL. Yeah. I feel like that— yep. And I feel like the last thing you said kind of covers this, but have you ever considered the case where like, this is an edge case, right? Where like maybe some gamers would like spam the start and end. So you would have like a bunch of clips like coming in all at once. Like, how are we going to handle that? Again, I. I don't think like when you say a bunch, like we're talking like. Let's just say over the course of an hour, it's like 100, which is like an insane amount. I think that's still way under what this database would support. I mean, we're talking like a Postgres database should be able to To handle like roughly, I mean, even like 100 writes a second without much issue. Okay. So I think that as long as we get the signed URLs from object storage, we're uploading in chunks and it's being stored properly in Postgres database without being Like having to call multiple times or trying to route the videos through the API, then it should be able to handle somebody spamming like that pretty fine. Awesome. You would also probably include like a limit for free clients. You don't want a free client to have 100,000 clips on your system, or you don't want a free client to be using a terabyte on your server. So you'd actually probably have like a limit to how many times they could clip in a gameplay session or how many times they could save clips. Like, online, like on your system. Yeah. And that, but that goes into like pricing and like trying to like maximize like how much, you know, how much, you know, that goes into like profit. Yeah, you don't need to worry about that. Sorry. Yeah, awesome. I think that's pretty much all my questions, but I guess like one, maybe like one extra question is like, since you're familiar with like Metal, do you think this is a system that is like Comparable to what you use with Metal? I would imagine. So I know that Metal does other things other than gameplay clips. Other than— I think they do a little bit more. I don't— I think that the biggest thing is We didn't really talk about generating a link. Mm-hmm. Um, which I think is a pretty big factor of Metal. Okay. One of the things about generating a link that we didn't really talk about is that, uh, one of the things that Metal does really well is they create links really quickly. Okay. And that's pretty Yeah. So like, for example, I'll play Apex Legends or I'll play League of Legends or whatever game. Sure. And I do something insane and I want to clip it and show it to my friends. Like, look, look, look at me being good at the game. Right. I'm able to do that almost instantly while I'm playing the game. Oh, okay. And we didn't talk about that here, but my educated guess on how They do that is that when they upload a clip to their storage, they actually encode it to the lowest resolution or the lowest rendition that they can. Let's just say 480p. And this caused— this is about 5 megabytes of video versus like a 1080p 60 FPS clip is about 40 megabytes. Yeah. But if you're uploading a clip, if you only upload the 480p version first and then you get a generated link from Metal from that, that should be like, no joke, like less than 10 seconds or like less than 8 seconds from creating the clip to uploading and getting a link. The important thing is that it doesn't stop there because you're going to obviously send this link once it gets views, or actually before it even gets views, it'll still be uploading the source 1080p 60 FPS, but I wanted to generate that link fast, so it encodes the 480p first, and then once it gets its first view, then it'll encode or transcode or rendition the other You know, the other resolutions. So 480p, 720p, 1080p. But I think that the important thing here is that it's prioritizing speed by uploading the smallest file that it can to create a link. Create a link such that it feels instantaneous and then it does things lazily in the background. Because it already did the important things, right? It already uploaded it and everything like that, but it does things lazily in the background, like uploading the source video while you're still playing, and it still allows people to watch the clip even though So for the first, you know, let's just say 30 seconds, it's in really bad quality while you're uploading and stuff. It allows you to get an instant link to share. Oh, okay, cool. I would say that that's probably the one thing that we didn't touch on that I think the Metal does really well. Obviously, I think the important thing about Metal is actually how much gameplay they have. That's pretty valuable. Awesome. Yeah, cool. This is exactly what I was looking for. Okay, I guess like, um, we have like about 10 minutes-ish, maybe 13 just because we started a little late. Um, yeah, did you want to like Try making a small prototype with like the AI assistant to see like. If this, if you're like this icon here. Yeah. I'm also open to if you have like your own IDE and you want to share your screen with that, that's also fine as well. It's totally up to you. Yeah, I, um, I mean, I tend to use Cloud Code. Yeah, that works. I would say that my thing is we probably won't get through a prototype just because. Yeah. We don't have enough time, but don't worry about that. Like, I just want to see like what you're kind of thinking in terms of like coding it out, what you would like kind of input into an AI agent, that kind of thing. Yeah, absolutely. So let me— can you see my screen? Yep, I can see your screen. So I guess initially, let me just make a file for this, make directory. Meta. Or recording. Project. I guess the first thing that I like doing with Claude, so whenever I work with Claude, the first thing I like to do is research with Claude. Let me check on what I'm on. Let me switch over to— I hope it's slightly faster. Okay. But the first thing that I do is research with Claude. So I would do like, you know, you gave me kind of a basis already. Yeah. Like, we want to design a recording software that takes gameplay VODs and other stuff. So I would pretty much I mean, I would pretty much copy this and just say like research. Into. Oh, it didn't let me copy it. But again, the first thing I want to do is give it context. I mean, we talked for 40 minutes. Yeah. And it's missing that context. Yeah. Um, No, wait, research into Okay. I don't know, am I? No, you're so good. Um, all right. I need to log in. So again, we talked for a while, but the first thing I like to do is research with Claude. In a normal workflow, I research with Claude pretty thoroughly. Obviously, it kind of makes it like my system design intuition and then Claude's Claude's. ability to gather information and be a good code. I mean, Claude is like quite, quite intelligent, as you may know. Yeah. So I don't Ignore what he says. Like, I code, I research with him. If I see something that's like something that I disagree with, like let's just say Claude is starting to say like we should route the video through our API, I would push back on that. Yeah. But it's like a mix of like researching with Claude. Horrible time to have a login again. All good, don't worry about it. Happens all the time. Okay. So, um, After I researched thoroughly with Claude, I asked Claude to write a plan, so I use plan mode. I think it's really good. Um, but I create a plan, I read it thoroughly. And then after I agree with the plan, I mean, if I disagree, then I'll talk about it more or I research more. After I agree with the plan, then that's when I start coding. I tend to use a lot of subagents in my day-to-day Claude now. So I have one subagent that's focused on the API to a Postgres database. I have one subagent that's focused on the object storage section. But I have— I don't try to have one agent do everything. And then once this plan is done and again, I agree with it, then I start coding. But that's basically my general workflow with Claude. I wouldn't really call it live coding. Yeah, it's more of like you plan it out, you make your research, and then you code it out. I mean, I've done interviews where I've done all the research in the last 40 minutes and Claude has no idea what we just talked about. Yeah, I wish you'd like heard everything and has all the context. Yeah. And so, I mean, I've done interviews where like they have Claude usage in the interview. Sure. It just feels a little bit awkward because I don't think it mimics my real workflow. Yeah. And again, I use Claude like a lot. I tend to max out my max subscription every week. That's awesome. Yeah, just because I just, I just use it all day, every day. Yeah. Sometimes I use terminal, sometimes I use the app. Yeah. My only difference between using one or the other, I don't know if you care at all, but my only difference is that when I have to restart my computer, so if it's a multi-day project and I'm using the terminal, I lose the memory. Exactly. Yeah, that's exactly my workflow. When I use the app, so on small projects that are generally less than a day, I'll use the terminal. On long projects that are generally more than a day, I'll use the app. And that's pretty much the only difference. Totally. But I have a bunch of, you know, I use a bunch. Yeah. Oh yeah, cool. I don't want to wait for— I don't want to have us to wait for like Cloudflare to start up. Yeah, I think this is going to take kind of a long time. Yeah, I don't want to like waste your time as well. What we want to do is, I guess, take everything you kind of mentioned today in our interview, and then in 24 hours, if you can give us a small little prototype, it doesn't Need to be like really like working functional, but like a small prototype of like what you kind of develop in the system design interview, and then send over like any. project that you developed, how you would kind of change the design that you've initially thought of? Yeah, if you can send that over to us, that would be great. Yeah, I guess my first question would be something along the lines of what are you guys looking for? Like, is it more impressive if I design a little bit of everything, or is it more impressive if I have like a super bare bones app? Can press a hotkey that actually records and uploads. Yeah, like I think something that would impress us would be like something that actually works over like, I guess like a vibe. Like I can design some like nice front end. That doesn't matter to us. You don't need to do that. Yeah, like we don't really care about front end. Like that's for designers. And so if you can just design like a system that works, that would be insane. So, okay. So if it, yeah, where do I even send that to? You can just send that to my email. Like you can put it in GitHub, send it to my email, or I guess like what would work best for you? I mean, I could just upload it to GitHub. If it actually ends up working, I'll probably just put it as a pinned project. Yeah, that'd be awesome. Yeah. Okay. And do you care? I mean, do you care if it's like Like my plan was to, you know, when you said that my plan in the next 24 hours is like, oh, I just created a clipping software that works for League of Legends that creates an uploadable link. Yeah, that'll be exactly perfect. Okay. Yeah. Yeah, sounds good. Do I get feedback on how I did in the interview? Yeah, no, I mean, I'll be honest, I think you killed it. There's a lot of things that, like, for example, I'm not a gamer, so you covered a lot of the bases that I think is great that you come from a gamer background and you know, like, the tools and you've used Metal, so you know, like, the requirements. So I think it's great that you kind of listed out the functional requirements and non-functional requirements in the beginning, and then you went through your thought process behind the entire system, and then you kind of went through how this would work. And some trade-offs with reliability, why you use certain databases, how you would design the API. So I think everything went really smoothly and I would definitely give really solid feedback to the team. Okay, fantastic. I always ask for feedback after the end of my interviews, either on call or like in an email. I think it's really important to learn from. Yeah, totally. Is there anything that you think I could have improved on? Anything that you could improve on? I think that's more important than like language to me, you know. I guess like this is more of a preference thing. So I don't think that like I would— I'm not going to mark anything on my feedback or anything. I guess whenever I do system design and I create an API, I would always want to list out what kind of API, what are the fields of the API, and what are the outputs. Like the post clips, tech clips, things like that. Okay, that sounded very understandable. I was like, I hate, hate API. And that's kind of why I tried to avoid it. I tried to explain it as best as I can, but I just hate that part of the system design, to be honest. Yeah, yeah, I totally get that. Yeah, okay, sounds good. Thank you so much. Yeah, and if you can send over like anything that you build after, just send over to my email. If you want to create like a demo, that'll be cool as well, or like how I think it's just like, yeah, I think it's just like, you know, we could use your software. That'd be pretty cool. So yeah, absolutely. Again, thank you for your time. You made it, you made it feel pretty seamless even though I was pretty nervous. So thank you a lot. No, no, not at all. And it was nice meeting you. Yeah, really nice meeting you too. Yeah, if you have anything else, just, uh, shoot me an email. Um, yeah, thank you so much. Cool. All right. Yeah, if there's nothing else, then, uh, I guess have a good Yeah, you too. Thank you so much. All right, see you. Have a good one. You too.

Hey.