Real Senior Frontend System Design Interview 2026 (AI Coding Included)

Today we're going to go through a system design interview for a senior front end position. This is a real interview, one of our mentees got. Spoiler, they got the offer. It was a six figure position for one of the biggest financial companies in the world. And, can you tell us what was this interview about and what made it so special? Sure, so basically it was an interview where they were invited on site and they couldn't use anything digital.

It was a whiteboard interview and 19 the interview actually printed on a paper, the very similar graph where you can see kind of the data points of a financial asset for each stock. And again, they got this printed on a paper, they went to the whiteboard, and in this case she had to walk them through the whole process of how she will actually build this kind of component. And by the way, folks, one of the biggest pitfalls in these kind of interviews, it's people go blank because they don't have a set of meta milestones, a structured way to go through the interview.

So they don't know where am I at, what's missing, how do I get to the next step. This is exactly what Bogdan is going to share with you and this is what our mente actually used in the real interview and passed and gotten offer. The other thing, which is a little tweak is that we added AI questions as Bogdan is going to go through the interview, he will talk about, hey, is it fit to use some AI to go through this stage of the interview or not.

So Bogdan, let's get going. So the first thing we want to do is start discovering the actual requirements, because senior engineers never take a design for face value. Senior front ends, they never take any UI for face value, they can actually dig in and translate this into concrete requirements for the system, and based on those requirements, we'll actually build system. So the first step would be going into and extracting what we call in system design, the functional requirements, and number two, the non functional requirement.

So functional would be what do you need in order to do the thing that you need to do, like, oh, we need a graph, they need to see it, sorry, they they need this buttons over here. That's a functional requirement. And a nonfunctional requirement would be, does it load on every browser that our users uses? Does it load fast? Is it accessible? So if people use screen reader, can they still kind of use the component?

So it's not exactly about what you do, it's about how you do it. Are you doing it fast enough? Are you compatible enough? Is it testable? Is it maintainable? If you're building a car, functional requirements would be, does it take me from A to B? Whereas nonfunctional requirements would be how much fuel does it cost you? Which is not necessarily related to the function, but it does impact the user experience.

And so in the front end, functional requirements are usually about wire framing that UI and kind of understanding what you need, what kind of screens you need to get the function done. So basically, in this case, we'll definitely have this component and I'll ask them, am I building this inside an application, like inside a component framework application, or is this something you want to integrate in other websites?

And how do we want to integrate it? Because if I want to integrate this, then I'll probably you need to use like an an iframe. But if that's not the case and this is a standard component framework, then probably what we are building here, it's a reusable component. And when it comes to functional requirements, well, I'll just kind of review this. Okay, so I have here a static label. We have kind of these numbers.

I think in original design, this number changes all the time. This is also getting a fresh all the time. Let me switch over to the original design. Now, moving on to the nonfunctional requirements, I would mention things like web performance and ask them, is web performance important? Probably in this case, it is. So in this case, do they have any SLO, like a service level objective? And in the front end, you quantify that with core web vitals in an real user monitoring RUM system.

So I'll be like, okay, are we aiming for a specific load time? Are we aiming for a specific interaction time? Then we have things like accessibility. And so here you want to ask who is who will be using this, and if they have any legislation around. So usually they care about accessibility, and they definitely care about security. And I'll just mention that was at the very beginning of the of the interview as, okay, how important they are. And I'll tell them we will have take this into account as we scale the design later on.

You don't need to get into the details, just mention that you're having all these things into account as you design a system. And the other thing you want to ask in this case, it's do we want real-time updates? And if we look at the real UI, we see here there's definitely a real-time component to it. So for example, this variation, it's real time and we see that both the graphs are moving and both the timer timer is moving and the contract is moving and also the data range it's dynamic.

And we get new points in and then we redraw this with an animation. So we're going to split this in two, one being the initial loading, where we see the static the static graph, and then the real-time part that happens after the user loaded the page is constant refresh and fetching of those new data points. And the outcome of this functional requirements and non functional requirements phase, so they're just kind of an exploration here, you don't need exact numbers because it's kind of harder to get the number of accessibility or security.

Well performance, you can get better numbers in a core web vital, but just if you mention them, they already know that you are going to quantify this. And so the outcome would be you exploring those non functional requirements and having a Yf. And with that we are able to move to stage two, which would be the state architecture. Because in a new UI, state it's the most important aspect when it comes to functionality.

And so, if I look now at our UI, we will take all the things that are not in scope, so they told us that we need to focus on mainly the graph functionality, so this are not going to be in scope, this are going to be in scope, this is not in scope, not in scope, not in scope, not in scope, also not in scope. And then this component right here, this is pretty static. And the only dynamic part here, and I'm going to highlight that with this color, it's this text time.

That probably has to change when I reload the page. And now we go down into the actual dynamic. data. Uh so with the final price it's high coded, but this data here will change. This final price will change, this price to beat will change. It will come from the uh basically comes from the back end, you know, initial load. And the same goes for all these data points. And so now we're going to go into modeling that, but for now, I just finished the assessment here.

I see there is a slight line over here, so I need to fetch that target price. And then there is I see the lower price here, our current price. So that's kind of redundant. I just need one state, but I definitely need to target price. There's a time range here that's is the date and the time. And then I see there is this interactive buttons where you can change the I think the hour can adjust that. So that's kind of also goes into our state analysis.

So right now we're basically analyzing the UI and pulling what will be your state, pulling out what will be your state variables, exactly. And so you want to derive from here actual entities. And so if we were to look at our data, we see there is a current date interval, as I see here, there's definitely I'll just add this as type. And so here we will have start, it would be I'll just make that update.

And then we have at the end, which would be the date and this basically covers, this would basically cover the bar over here and this thing right here. So then I will move on to the next. So the next one would be the price to beat. So I would call this price data, and maybe we fetch this in a single request. So that would be price to beat, that's over there. We also have the price and like final and those things could be.

I'll just go with the number, you might get you might be tempted to use big int if it's a financial if it's financial data and you want a lot of decimals, then those numbers can store a lot more than a plain integer. But for now, I'll stick with the default JavaScript number primitive. Um and so we have final price, price to beat and target price. And I feel like with that we cover pretty much everything except for the graph data.

So now I'll go ahead and model this graph data. Basically, we can call this like a data series. And so, obviously we need an ID on that. And I make this a string because usually it's better to use UUIDs then numeral IDs. And so, if we look at the data series, it'll probably is an array of I'll call this data points. And so it would be an array of another type to be data point. And I guess this definitely would have some sort of maybe a label or or a name you want to display.

And so, I don't see much more around it. Probably we could join these two. I will get the price data because the price data is related to this specific data series. And the date interval, it's also we fetch the data series for the specific date interval. So, you might be tempted to unify uh to unify all those because in the end this these points they go from the start to the end. So, you're going to need that.

So, I'm going to move this start and end date and unify this in a single type. It makes more sense because they are very strongly related. Basically, those felt depend on each other. And then when it comes to the price to beat, price final and price target, I would assume that the target price probably it's independent to the data series. The final price is not, final price actually we do need to fetch, because it's probably the last data point here.

So, I'll take that out because that would be done this thing. That's derived state. And then the price to beat, that seems like a independent independent variable. So, probably the biggest discussion I would have as interviewer, okay, you know, those things in your data, in your backend, are they completely different? Are they stored differently? Do I need to make two requests or not? And then I'm not going to just unify them in a single time.

Does it make sense? Would it be fit to use AI in order to go through this step? You did it manually, right? You did it one by one. How would you use AI to go through this if you were allowed and would you in the first place? Yeah, sure, so you can use AI to refine your state architecture or brainstorm. What I did just before we shot this is to throw this to Claude and it came up with a very complex data structure. And I said, okay, let's simplify it. And then the final result was this data structure. And I told it to use this kind of format, to be diagram.io, you can tell it, hey, get this UI, give me the state in this format, that's very useful. And it basically gave me the price sticks, which is my data point, and then the chart data, which has a steady start and the target price. So it definitely unified the target price with chart data. But it's definitely missing some data points. So it can help you iterate, but you need to be very good at it because AI tends to not hallucinate, but it tends to expand things. It tends to add unncessary details, it doesn't get you know what's static or not in the image, but it can definitely help you refine your approach. So the last part would be this data point. So that's the one that I didn't really grasp out yet, so let's do that close the UI. So we have data point. And in that case you just want to kind of write down the primitives. So this definitely will have uh sort of an ID. I have an ID, like that a new ID too, it would have a timestamp. That can be a string over the network and then we have to parse that, and it will have a value, which for simplicity, a bit of number. But probably in this case, again, big integers would be uh more suited, and then we're going to have this relationship of, okay, type data point. Uh so this kind of to keep what we call referential integrity, those data points will come as data points here. So there should be a storage relationship between the two. That's database level, but in our front end, we just know that these data series will contain an array. And it comes with all these data. So, are we done with the state management architecture or do we need something else? So again, I would ask them if we can unify this just to have one single data request. Like we unify this, we make one request, we get both the price data and data series. That's probably possible. It depends on the back end API. If they tell me I have complete freedom, I would tell them for simplicity, I would keep these things together, the price to bit and the price to target. So I'm going to copy that and simplify this. Because simple, it's always better than complex.

I'm going to put that here. So, that's pretty much how our data structure looks right now. We basically have these two data types, data series and data point, and we can move on to the state transitions. Okay? So, basically, state transitions are there to synchronize state or response to any user input. So, keep in mind that usually need two reasons to change state in the frontend. Number one, there's some data coming from the backend.

Number two, there's some user event. So, it can the UI for user events like things that are clickable or forms, or also things that come from the backend. And I always start with the backend because it's the easiest. So, obviously, we land on this page and we need to fetch the data. So, we'll need to make a fetch request and get probably the data series, which contains all the data points. And, of course, because it's a date it's a it's a request, we will need the three states, which is data, right, that has the type data series, and then we also have loading and error states to see if there was an error in the back.

So, that would be our state as of now, that's the shape of our state. And then, as I see here, we also have this user kind of clicking on this different timestamps, and that's probably going to change our start and end date. And that's definitely state, because there's no way we can obtain that. That degree comes from the user choice. So, probably, our second state uh and actually the the main one, that first one would be uh kind of the interval, which would basically be uh start.

Like I'm going to add this as uh as an object that has a start uh timestamp. I'll call this start date, but it's actually a timestamp and an end date. And so, what happens when we have state mutations or state transitions is that whenever users click on this, we'll probably change the start date and end date. We're going to compute that and we'll have a new value for that state, and we also need to trigger the data fetch. So, the interval kind of refreshes and the graph refreshes.

So, our final state would be a start date and end date, which have an initial value, and then data series loading and error, which are based on the synchronization with the backend. And what would you use for state management. So it feels like here state is very much at component level. This date, it's also at the component level. So use component state. So basically use state for for the most part.

And there's no need for reducer, the state transition is pretty straightforward. What probably would be useful, if we don't want to re-invent the wheel, is to use an external library like TanStack, which kind of gives you custom hooks, reusable hooks for data fetching, so we don't need to write our own custom hook for fetching this this end point. Assuming we are using React, right, to build the UI.

Yeah, so if we use TanStack, it's available in pretty much all the component frameworks. I would probably use React because it's the most common and I think for this interview they were actually using React in their in their tech stack. So, we could go with that or any kind of component framework. So, wrapping this up, the let's say the second stage which was state architecture is done. Just to recap, first we go through the requirements getting phase, we looked at functional and non-functional requirements.

Then we moved towards the state architecture and the output of this would be the state entities, and the shape of the state and maybe the library you're going to be using, and what is the next step, part of the not this stage. So now that we got the state, I can go deeper into implementation details. So for example, they were to ask me, okay, what component framework would you use? I'll switch I'll stick to React in this case, just because it's the most common one.

I would ask them what they use, do they have any preference. And then the other thing is how do we ship this to our users? Is this a component we will just add to our SPA, so it's shipped with our single page application? Or do we want this to be part of our design system, for example? Is this meant to be reusable? So that would be my first question, are we going to reuse this in any other part of the page and does it has to be reusable?

And if it's reusable, what other things that change between those instances? So I would assume the asset itself changes. And if that's the case, then I would have to extend my and I can fetch you the specific data series. And so in this case, this is going to jot down a couple of things. Number one would be for the component framework. I'll say we use React. And then I'll probably ask if there's any design system they have.

Do they have any design tokens that I'm supposed to use? If not, I would define them. Design tokens are basically colors, fonts, and the lowest unit of design. In terms of CSS, I would probably stick to some sort of CSS modules to avoid any kind of global conflicts. And then ask them what's their CSS approach either using things like Tailwind or any kind of atomic CSS. And then number four, in terms of accessibility, I would probably stick to semantic HTML for the most part.

And try to make sure that the order on the screen is the order in the JSX markdown of the elements. And that would be more or less our minimum viable front. And now we can go deeper into the non-functional requirements. And finally, what about code quality, which given that we're going to assume we're going to be using AI coding for this project, we will need a sustainable way to ensure code quality, whether we use an LLM or not, to write the code.

Sure, so for the build tools, like the most used traditionally is usually webpack, but nowadays most people use things like Vite, where it's a lot faster. Or even esbuild. I would definitely check in and what they are already using, and I would recommend probably Vite because it's the easiest to get started with and it's pretty fast. It's actually super fast. We could also use RS pack if they have an existing webpack configuration and they just want speed, it's basically webpack written in rust.

And then of course, we would need to, depending on what we use for CSS, we would need to have our CSS build pipeline. Do we want to use SAS? Are we using only style components, for example, with CSS modules and so forth. And when it comes to you mentioned code quality, because we're using agenty coding. So, once we have the data structure AI is pretty good at getting the UI, giving this data structure and print out the first version of the code.

But I would stake to first of all static code quality, that would be TypeScript. Mhm. Yes or yes for type checking. I would use a linter tool, the most compatible one it's S Lint. But there's also things like Ox, I think it's Ox Lint. If I recall the name well, which is a lot faster, I just set up set this up for for a typescript project and it's blazing fast. So there's new versions, and then something like Prettier, which is really important because when you have agents writing the code, sometimes you want people to format the code in the same way and use the same constructs.

And so when you look at the pull requests, they are a lot smaller if everybody is using the same style. Because with agency coding, pull requests are huge, so you get the 6,000 lines of code you need to review and it's a lot easier if everybody is using exactly the same conventions. Mhm. And then for dynamic code quality, that would be executing the code, which is basically testing. So I would definitely do unit testing, like component testing.

And the cool thing about using a coding agent is that they are pretty fast at writing this, so definitely, first of all, make a test plan, analyze all the edge cases and then write a component test, and then also think of sort of an end-to-end test. Bojan, are we done with the minimum viable frontend and can we move on to the next step? Yes, again, you want to check in with your interviewer and get the buying.

So make sure they are that they're on board with all these decisions we made, and sometimes they might want to ask you specific questions. Like for the build tools, they'll ask you about why would you choose Vite versus Arespack? What's the timeline of the project, how fast do we need to go? But for the most part, if you get these many details, so we have the state transition state management. We have the wireframe and the minimum to get this up and going, then you should be fine to move on to the next step.

And so in the next step, you want to lead them to the non-functional requirements. web performance part, for example, is usually the most important. Basically web performance and scalability. And at this stage what's very important is that you're going to a high level of granularity. So the difference between a senior and a junior is that juniors will kind of just answer the question and let it fall flat.

They'll be like, well yeah, so for the web performance, then I would do code splitting. Or they give you some generic thing or they tell you I would set up a CDN or we're going to like Dallas analysis. Whereas seniors will have a more structured and more in-depth approach. So they'll be like, okay, going into web performance, what do we care about? We care about the three dimensions, which are basically loading speed, reactiveness to input, so using input, so how fast do we react using input?

and stability of the layout. That's number three. And based on those, we want to probe how important they are. So let's start for example with loading speed. I would ask them, is this going to be on a public page, it's SEO important? And do we need to are people going to get are we going to have a high amount of traffic here? And probably that is the use case here because these things are these kind of widgets, they appear and print very fast.

So then I will go into, okay, we need a lot of JavaScript to make this happen, how do we make this efficient? And so number one thing with the number one thing would be making sure that we do, of course, bundle splitting, so load only the JavaScript we need. This is usually we do it with a build tool. Number two would be if we look at the UI itself, probably we could do some SSR, especially if there's there's a lot of static page around it.

So we just dynamically render this part and the numbers, but everything else is pre-rendered. That will also give us a good CLS, like the cumulative layout shift. There'll be no layout shifts because we already pre-loaded this, we pre-rended this on the server. And yeah, it will probably pre kind of maybe even you could even pre-render part of this range. Kind of set the default of the range and then have this being pre-rendered on the server.

So the initial load is very fast, but you cannot interact with it. Two things I want to go to. Number one, it seems like scalability, it's a pretty straightforward thing. the front end, right? Because we have CDNs, we have static assets, we can ship our bundles and they are instantly available to the user. But the bottleneck can become the backend, right? So, would something like a BFF make sense in this case or not? And also keep in mind the real-time component of this graph, right? That we want real-time updates to the user. Yeah, very good question. So I'll answer your first question, when it comes to the BFF, it very much depends on the source of the data and what is the shape that we're getting into. So, if there's a lot of difference between the shape we want, which is this one, and the actual shape in which they are giving it to us, or we know that the service we're getting this from, it's maybe subject to very frequent changes where we don't own the service, then we can use a BFF to provide like a stable interface for the front end. So, basically, we'll have a front end application, we'll have a front end and we'll basically have a dependency on the BFF, but this will stay rather stable, so we can iterate on the UI without changing whenever the, let's say, the data service comes from here, they change their API, we change the BFF, we're done. We don't need to change the front end. So this interface stays stable, and this is very even more important if you're using coding agents, having this kind of stable interfaces that help you do root cause analysis at scale because if something breaks and you have the stable interfaces then you can use AI to locate bugs much faster than if you change the whole thing and all the PRs are introducing changes in all the systems, it's very chaotic and very unstable. Yeah, for the folks watching us, if you don't know what a BFF is, it's basically what said, it's an intermediate layer that you add between your API and your front end that can absorb those changes, right? And it can help accommodate the front end better regardless of what API you have in the backend. Exactly. And so that would be a REST API or a stand alone graph QL that then makes the downstream requests, gets the data and gives it back to to the front end. We call that a reverse proxy. And so going back to your second question, which would be how would you make the real time updates? They

most important thing, the most important question here is, is the communication here is real-time? So we could either go with there's basically three approaches. We could either do pulling, which means we from the front end, we call the back end. Right? We go from the front end to the back end and check if there's any new data. This is the most robust one. And the problem is talking about scalability when you have a lot of clients and they pull your back end, they're basically doing a denial of service attack. They will DOS your back end. There's too much pressure because literally everybody that has a session open keeps hitting your end points all the time. And let's imagine you have this kind of graphs like you might have on a single screen 10 of those. So you're faking every every two seconds, if your update window is two seconds, you're making 10 requests from a single client. So it's scale is very poorly. It doesn't scale at all. So definitely pulling would not be a good choice. The second one would be web sockets, and it's getting important here that this implementation is pretty complex and it's bidirectional. Whenever you have like a user chat and users go back and forth, that's when you need bidirectional communication. It means that it's not only the server sending updates to the client, but the client also serving sending updates to the server. But in this case, we just see the front end needs to re-render, but that's pretty much it. It doesn't send data to the server that then has to be reflected in other clients. So in that case, the best is to use what most modern LLM applications are using, which is server sent events, right? Server sent events. This is a native API where you listen to URL and you basically get these chunks of events. And in our case, the shape of the event would be the data point. So basically, we will listen to a specific URL and get like in that case, let's imagine this was time series. I think we have Bitcoin, that would be the ID of our asset. And we basically get these messages sent, and so what we could do at application level is to have a state update. You can get a state transition.

then basically the state update will push this into our data serious. And so what will happen is we add the second new point here, and then there's a whole transition to move this up, to paint this when we look at real time. Now I'm going to switch back to the application because there's something more important happening, which is whenever I was going to the live market, we see that the graph it's also moving and the values are here of the increments that happen, and we see the current price switching.

Now, this is a tricky one. So let's bring this in. Because it feels like there's so many things happening, but I feel like there's only one happening. So let's see. So with that new data point, we can paint the new point. Then we need to move the range. But that's pretty easy because we have the time stamp of this new data point. So we're going to use the time stamp on that point to update our range.

We'll also update our current price, and then we start showing those updates as these data points come in, inside the differences. But again, I didn't need to store this again. I could just have a pointer here. This is where we started when you landed on the page and we added three points and then I calculate the difference and I render the differences as a stack here. And then the time it's when you landed on the page.

So I don't really need extra state. I could probably, unless I'm missing something crucial, I could probably paint this whole thing with a single, with the new data point. And that's very important that you keep your state as minimal as possible. Okay, one thing we didn't mention, it's caching. Wait, let me see, though. Okay, one thing we haven't mentioned, it's caching. What would you cache at which levels?

Sure. So the most important metric to see what we need to cache is what we call the read write ratio of a resource. So if something is being read a lot more times than it's being written to, then it's worth caching. And you want to apply this to pretty much everything in your system. And so first we start with our static assets. Now we mentioned assets. So this are JS, CSS and basically for caching at that level, you can just introduce a is CDN like a content develop content a content delivery network, which will basically spread this close to edge to the edge locations and then have efficient cache policies. We mentioned a design system, the CSS in the design system, it's usually more stable than the rest of the application. So it means basically that there's less rights, then there's a lot more reads than rights, which means it's usually a good idea to separate the CSS files from the design system. And that's when you need to go deep into your build CSS build tool and separate your CSS from your bundle. Because if you look at traditional CSS modules, like style components, what they do is they add a style tag in your HTML file. And the problem with that is that it's coupled to your document. So you can't really cache that. And that's when you go deep into your knowledge of, okay, how it's CSS actually managed by tools like feet and so on. But you're definitely, if you separate this, then you can be able to cache your assets efficiently. And then let's look at the dynamic data. So we had the basically the graph, the graph points. That's something that if we look at the read and write, the cool thing is it's very easy to know that because data from the past, it's basically read-only. So everything that every data point that it's past now can be actually cached with a very efficient cash policy because it will not change. Like the price of a stock only changes in the future. Nobody will go back and write back. The price of the stock yesterday. So in that case, I'm going to ignore all the caching that has to be done in the backend. But I'll definitely implement uh sort of http caching, so if someone it's pulling the data from yesterday, then that's being cached so everybody's using the same version of it. And probably, I have http caching that will cache it on a client, and probably I would also look into request client side state caching. So you have, for example, in tan stack, you could actually implement your own caching policy for a specific request. And I would make sure

that all past data is cached. Basically, the reason why it's attractive to use a library like Tanstack is because they give you state management for your data requests. That means if you are going to requests a data interval or a data point that you already have, Tanstack is basically able to store that on the client so you don't actually go to the server. And the refreshes are very fast. And this is very useful when you have someone checking what the price of the stock was yesterday or 3 days ago and so on. The moment they do it once, you can store that on the client side in your state and then you avoid any kind of requests. So, this kind of refreshes are very fast. The only thing that cannot be cached is future data that comes to the server sent events, right? But everything that goes beyond this only has to be fetched once because it basically does not change. So, when I refresh and change the interval, I could still keep, let's say, I change my time range to here, this kind of points, this kind of data points I could still keep, yeah? And then somehow reuse. So that's the kind of micro optimization you can do. And then of course use all the framework optimizations like use catch, use memo, and all that to avoid any kind of component rerender. Now, I would say let's move on to the two AI related questions, and one of them will be about AI development. Basically, this is an open-ended question, I'm wondering what kind of models would you use, what kind of AI tools do you see fit to build this kind of application? If you were to implement this system design, and the second one would be whether if we would have to integrate with with an AI app, how would you go about that integration? Okay? So for development, I would probably, I think the most the models I'm familiar with. The models I use the most are the models from Anthropic. So, if you're looking for a coding agent, probably everybody talks about about Opus 4.7. To be honest, there's been a slight regression in several tasks from Opus 4.6, but you can also use Codex with

GPT 3.5, they are quite comparable. Of course, they all have different strengths, but keep in mind that none of them has, despite all those companies claiming it, my personal experiences is that they lack any visual intelligence. So that's why before you go in and regardless of whatever you use, I would have some sort of stable artifacts in your in your code that you use as anchor points to make sure that the models they just do the interpolation between these artifacts.

So, one of them would be a design system. So, yeah, they call it with your building blocks. The second one would be the state diagram. And so you make sure that those things are are stable and then models do a pretty good job when you tell them to just implement the component. And probably, if you're talking to the back end, you definitely want to also write sequence diagrams. And so you use this as checkpoints between your code, so you program, so your models program to interfaces.

And if you're asking me about a like harness and about coding, agent or harness, I would recommend the native one usually. So, I would either use cloud code if you're using Anthropic models or open code with different models and this is usually cheaper, and you get pretty much the same the same performance and probably open router to switch between models. And then cursor is really good also because I do feel like this tui, this terminal user interface, it's very limited if you want to do any advanced code reviews, so for development and refactoring, the cursor agent mode and composer are much, much better.

But their pricing is not it's a bit worse because anthropic and all the model companies, they price their APIs more expensive than their harness. So, it depends on what they use, but that's the things I would go back and forth. I would also use a code with your agent. What about if cost was an issue if you were to build this solo and your company doesn't pay for it? What model what harness would you go for?

There's definitely some Chinese models that are decent, like Kimi 2.6 with Kimicode. Uh I interface a lot more stable than cloud code. And the performance is pretty much the same, sometimes even better. But again, being this a financial institution, they probably have a lot of restrictions. I mean on their data, because the last thing we want is to to give our data to one of those model companies. So, I would even consider local AI. In this case, I would ask them if there's any initiative for local AI. That means a self-hosting models or you're running local models with Yama, and you can basically pull even models like Quinn or cheaper models and you can run them. I can even run Quinn 15 billion, probably with decent performance, 15 billion on my machine. But again, cloud call has around, I think, was it 800 billion parameters? So the performance you get from a bigger model, they're just much, much faster then if you use a local one, but you can decently build a local one. Because again, financial institutions, it's a bit more taking. Okay, finally, there's like code review agents, code review agents and I would integrate also your some sort of a Chrome MCP. You got to be careful with those, so basically the agent can test itself its own work. And then I would use code review agents to summarize summarize pull requests. And have it can, especially for security issues, security, and boring things like accessibility. It's really good at fixing those. And it can feed this, usually a good coding agent, if you use code rabbit or any of those, or even cloud uh, I think it's bug hunt or something like that. It's going to feed the prompt. Like it's going to find the bug and then feed it straight into your coding agent, where it can usually do the fix and then push back into the pull request. Again, you have to do a lot of supervision because sometimes they just correct each other and they go into an infinite loop, where the code review agent keeps changing the code of the coding agent and then the coding agent keeps changing that. But that's what I would use nowadays, that would be state of the art. Now, I guess we can wrap off the section. One thing I wanted to ask, it's if you were to review this architecture that you came up with, what which parts would you revisit looking back

back or pay more attention to. So looking back to this, I would probably deep diver into reusability and how much of this component has to be used. Do we want to ship this as part of our design system as a reusable component? Probably going into tooling, like storybook. And then if it's a single page application, I would ask a lot more questions about what would be the rendering strategy. Do we want to do server side render or static site generation?

Probably not or incremental partial rendering or partial pre-rendering. So going to go in deeper into the exact render strategy. That would be number one and then looking at the architecture. I do I would ask questions about what kind of architecture they have right now in the front end, do they are they looking into micro front ends? Is it something that makes sense for them? What's their CSS architecture?

Are they going for something like atomic CSS, which is what Tailwin implements? Or are they going for style components? Those kind of questions would be core. And probably we didn't talk about the one thing I didn't mention, I think it's mobile responsiveness, so how would you make this responsive? Probably mentioning relative sizing units, rather than new high coding pixels. using a lot of flex box and media gray.

Um, what's the biggest mistake candidates make in such a front and system design interview? from your experience. So the biggest pitfall, it's running out of things to say. Uh ideally, as a great engineer, they throw this at you and you can address and you could talk about this for 5 hours. You could present different approaches, you can brainstorm and you need to be leading that discussion. So you need to have a bit of a mental map of where you want to go, what it what would be a final acceptable result for the design interview.

And you want to kind of walk your interviewer through those steps and they will probably stop you at every step and ask your decision, ask you about your decision making. And the difference between a junior and a senior is that juniors kind of they're very tool oriented, so they'll go oh we should do style components or we should do this. And seniors are like, okay, this is the best practice, this is kind of the driving decision factor here.

Okay, if we do web forms then, we got to take into count the bundle size. And then based on that, they start making decisions. But rather than making decisions, seniors present options. And it's the interviewer that can very quickly see what the right decision is. Because they're really good at being like, okay, option A, we could go with this option B, we could go with this option C, we could go with this.

Given the problem context, I would go with option B. That, it's someone that's a senior. And then they are not passive, so they will do that and then move on to the next topic and the next topic. So, the biggest difference is that juniors, they kind of need to be told, hey, we need this to be performant. Whereas a senior will be like, okay, what is the user, what kind of the users that will be using this?

And then they help decide if performance it's important and then they get from there and be like, okay, if it's important, then this is the things that we should have to decide. And walk the person through all these decisions. So they're very proactive technically and they can go very deep. So, if you were to say it in one sentence, the difference between a junior and a senior, it's the senior can anticipate certain roadblocks and limitations and present options uh to the interviewer and consult the interviewer.

Not just going to building and because it's not building, right? It's consulting, even like we're talking about AI writing half of the code, then it's really not about building at certain point. Finally, Bogdan, if you had one piece of advice, only one, for front-end engineers who are preparing for system design interviews, like this one, right? Right now, they have an interview two weeks, three weeks from now, what would it be?

Number one, don't it's more important to bring things home, to have a complete design. Then to get confused by all the different options out there. So, there's a lot of system design material out there. The problem is a lot of it is back-end oriented. And the other problem is a lot of people are focusing on like, how would you design Uber, or how would you design Instagram? But most of times for your average software company building a SAS, they will ask you about more for kind of business SAS feature like this one.

Where there's a lot of data. Whatever you you learn to the front end and to the business enterprise software okay? So keep it relevant to the front end and try to bring it back to what you actually use every day. Don't solve imaginary systems. Aston Bogdan, thank you so much for the people watching us. There's also a free tinker assessment for you to find your tinker gaps to senior and a free training for you to find out how to make the jump to that senior level. Who can actually pass these interviews with ease?

Thank you so much, Bogdan, and we will see you folks in the next one.