React.js Mock Interview Live Coding 2025 - Tier 1 Tech Company (Build Google Sheets)

Today we are going to build a mini Google sheets, this is a senior front end React live coding really interview. For this challenge, I want you to render four cells, respectively labeled A to D. Each cell should contain a text input that the user can type into, if you're familiar with Google sheets, that's how it works. Each cell should also display a number, if the text input contains a number, the cell should render that number.

A cell can also contain a string, right? So both numbers and strings, satisfying the Rex A to D plus. If the input contains letters, it should show the sum of the referred cells, just like when you sum different cells in Google sheets. For example, AD represents the sum of the cell A and D. By the way, you are not allowed to use any kind of AI assistance for this interview, and uh you are free to use any component frameworks, JavaScript framework you're familiar with, React, view, whatever you you feel good with.

Any clarifying questions you have, feel free to ask. Okay, so for the scope of this, do we need to take into account if the user adds like a super big number, bigger than the JavaScript integer, for example? For now, let's ignore those edge cases and focus on the core functionality and the core features that I mentioned in the problem statement. First thing I would like to do before we get going and and start coding is to layout a bit the components structure and state management if possible because it will make everything easier.

So I'm going to go through it and just start kind of going what the like a low fidelity version of the UI and try to iron out those details. So we have four cells labeled A to D. I'm just going to use a rectangle here. How a text label, perfect. That's our first cell. I'm just going to do this four times. And there it goes. So that will be enough our static version. Perfect. And says they should display a number and if the text input contains a number, the cell the cell should render that number.

So basically if this has the value 98, then it should show that, and then if the text input contains a number, the cell should render that number. Okay, and a cell can also contain a string satisfying injects A to D. Any of the input contains letters, it should show the sum of the different cells. So basically, let's see how this would work. If B would have the value of 11, and then C would have the value of AB, then what we should show is the sum of these two, which is 100.

So in terms of components, I think that's pretty much it. We could probably have a cell component, which I will outline, and that would be our cell. And we just create four of those. Now, there is a value state, right? So, for sure, this cell component will have the state of value. And from what I see here, we are sometimes not showing what the value is. So, I would also have some sort of display value.

At the very least, right, which is somehow computed from AMB. Now, does display value needs to be an actual state? Not really, because it's, you know, it's a sum of AMB. It's just a representation of the state of the other cells. So that's what we call derived state. So I think we only have a cell state, we'll only have the value. Now, the problem is, from what I see is that to compute C, we need AMB.

And so, for C to work, it needs siblings state, and that's why we probably will need to lift the state of those cells to the parent component. I'm going to call this the shit component. Because the easiest way to make those operations would be to do a bit of crap drilling and have have the shit containing the state of each cell and then the cells rendering different values that they can compute based on that.

So, I like the idea of lifting the state uh to the shit level. But what are the implications of this if, for example, we have 100 rows or 1,000 rows in a single sheet? Well, the main implications probably you'll have a lot of re renders at cell level because, you know, shit will re render every time you change any state. So if you change the value of the uh shit will trigger a re render, which will trigger also a re render of all the children of shit.

But you can avoid that just by wrapping it in react memo, so you we will wrap the cell component in react memo that will avoid uh unnecessary So you're really in this. But what should I do in this first stage of the interview and what do juniors do and what should they not do? The main problem most people do is that they will straight jump into the code and start coding some components without really communicating what they want to achieve.

And it's a lot easier to you draw this out really quickly. I mean this is this will be a live interview. You have to do this relatively quickly. But this will give the interviewer a very great idea of where are you aiming to go. And even if you then get later stuck in the code, they will actually help you out if they have the clarity that you know what you're doing, you analyze a bit of component structure and you make your intention clear and your thinking process.

When I analyze the component structures, like when I when I make this step from the requirements that are in stated to the to the drawing, what are the things I should focus on first? Well, the the first and foremost is just kind of building that wireframe. So, what you call component structure or wire framing a bit, the designer gave you and see which are the components that are either dynamic and that those are the ones you want to go or the ones that the user will interact with.

So, here we have the cells and then we know they will interact with them. What do you mean by dynamic dynamic components? Uh, dynamic means you fetch that imagine you're fetching some data, it comes from the back and then it's dynamic, it changes. You don't want to wire frame every div you will use. That doesn't it doesn't add any value. But the most important thing is dynamic components that get rendered or they somehow change when they see their data fetched from the backend or there's some user interaction.

Is there anything I should be watching out for at this stage or can I just proceed to the coding point? You want to have a balance between not overthinking here, because you're being analyzed on final code. So if you spend half an hour doing this, and you have no code to show at the end of the 45 minutes you're done. But if you don't do this and you've jump straight to the code, it's so likely that you'll run into an error and that's the end of the interview because they will assume you cannot communicate, they won't understand where were you going and there's nothing to help you out.

So you want to do this relatively quickly and it's usually just looking at the rough design they give you and replicating that with a low level of detail, paying attention only to the components that are either dynamic or that Bogdan, please for the floor. How can I get good at this if I don't do it in my job? You need to make this part of your natural flow. This is what I would do whenever I would receive like a JIRA ticket or a UI from product.

This is the normal model operation, right? This is my normal workflow. Because this will save up a lot of iterations in the code, which are much more expensive. So just drawing things out and understanding what will be the state, it's usually 80% of any UI. And once you have this, the rest it's just kind of playing the piano, typing everything and taking care of the styles. The second thing you want to do is to understand what's the state.

And right now we are kind of halfway there, we realize that we need to lift this state. As a rule of thumb, state should live as close as possible to where it's being used. But in this case, we just cannot do that, because the state of A, it's needed to compute something in B, in C. And those components are siblings. And if two siblings component need the same state, we need to lift it up. So we're going to lift the value state to the sheet level.

And that would be the value of A, B, C and D. So as I said, state should live as close to where is being used. But if that's not possible, then the first option to leave that state up, it's prop drilling. And if you're doing a live coding interview, prop drilling with probably the only approach you need to use. Nobody will ask you to set up a Redux on the fly. You need to be able to talk about global state and shared state.

But prop drilling, it's more than enough for a life calling. Quick question, a few moments ago you mentioned the word derived state and that you don't really need it. Can you, can you clarify a bit? Yes. So, basically, the misleading idea, if we just have a first look at this component C, is that this value 100 should be state. We mentioned that value, it's a state of the cell. And so this 100, which is actually the value now, should be some sort of state.

But in reality, that would be a redundant state because the value, like 100, already exists, we can just deduct it from AB. And so 100, it's non essential state. but dependent on other variables. And if you go and add this into state, you're creating you're adding unnecessary state variables to the application, which is always a disaster because it's going to make everything harder to test, has more renders and it's just more complicated.

Awesome, understood. So back to our data structure discussion, there's only two main data structures you'll always use and it's either an array or a JavaScript object, aka a key pair value. Now, because we render this four cells, a lot of people might fall into the trap of thinking, I'm just going to map to something and render those four. But because we see here there's a reference and so C will have to access a value from B.

So C has an address, it has a key, which is A. And then it has another key that's B. And then it's using that key to access this value. Then it's almost instinctively telling us that this will be a lot easier to do if we use a key value pair. Because once we have, you know, an address, we can immediately get a value. Whereas if we render this with with an array, you'll have to mess around with indexes.

And if you avoid that pitfall, we're already 80% there with the solution. Perfect. So, so far we know we're going to have a shoot component that's going to have a state, that state would be a key pair value. And then we will render this cells based on that state, and they will have an on-change handler. So that is the third step here, which is once you have the state mapped out, you want to take a closer look at state mutations or changes.

There are only two sources where you get state mutations in a UI. Can either be because we're synchronizing data with the back end, we make a fetch request, the data came through, or because they are user interactions. There's no data fetching here. So there will always be user interactions and from what I see in the problem statements, the only thing that the user usually does is to change the value of the cells.

So they will click on B, type in it and then maybe click somewhere else and that's pretty much it. And so the state mutation we will need will be only on change event. And what we want to do on change, it's to number one, update the field value, using that key. And number two, we whenever whenever the user clicks out, at least that's what's happening in Google Sheets, when you click out, we display for computer display value and we show that.

And this is where kind of things get a bit more tricky because as you see, depending if a field is selected or not, we show one value or the other. So, imagine the case would see, if the user clicks, we need to show AB, but when they click out, we need to show the 100. And that's when where we realize that each one of those cells will have at least two values, right? It will have a value, and then they will have a display value.

But again, this is not state, this is derived. So, probably we can actually compute the display value, right? Display value can be a function of basically the state of the sheet and the value of the cell. Basically, you know, the value it's AB and then we look at the sheet state, we take the value of A and B and run the sum and we get the display value. Perfect. And now we are ready to switch over and start coding.

I think we I run out most of the details. But again, you will need to do this in five, maximum 10 minutes. So you need to go rather fast. I definitely took my time here. So, as I mentioned, now we will go ahead and start implementing our components. So, we mentioned uh there will be four cells. Now, in the very beginning, in your brute force approach, brute force, you can actually even do one in one shot.

That's usually a lot easier. So, instead of having an iteration over those four components, I'm just going to hard code those cells over here. I'll have all the state in one single component. Because you don't want to start splitting this in components and then have all kind of bugs with props and so on. It's a lot easier if you do one if you do everything in a single shot. So, let's start with our state, mentioned we're going to have our shit state, right and then we're going to have a set shit and over that that will be a use state.

Now, what will be the initial value of our state here? Well, for that we need to decide on our data structure, and we mentioned that will be a key pair value. they told us, it only has four values, so I'm just going to initiate all of them to zero. Make sure you ask the interviewer if it's okay to initiate it with zero. So and there's the which is also zero. So we then we use the initial value as the initial value of our spreadsheet. And finally, I'm going to add our different uh cells, let's say. And for that, I'll use a simple div. We know they do have a label at the top. So I'm even going to be able to use our semantically uh perfect label. Perfect, not a, and definitely like an input field, that's a self closing tag, where we do know that the value of this input field would be. So that would be A0. So far so good, and now I'm just going to copy those four times. Now a lot of people will be tempted to put this in different components, and that's okay, but it will generate more complexity and you might get stuck. It's a lot easier to do it just like this. If the interviewer ask, I'll tell them, hey, I will split this into component later. What is just easier to work with it right now? Now, as you see, I'm not using AI for any of those, it's the problem with AI is that they will it will give you all kind of suggestions, we had students trying to solve this, GPT telling them, well, this data structure should be array. And the worst part is that you're not building the muscle of actually thinking by yourself. And what you will realize by the end of it is that the solutions you come up with are a lot simpler, more elegant and more efficient than GPT spitting out some code. So I know it's very tempting to throw this to GPT and just watch you the right code, but that's not going to help you at all. So don't use AI, really tight this out. They will make you write code without AI in the interview. So that's our implementation, we render our component, but it's very static. So let's add our first state mutation, which is the simplest one, which is hey, you know, the user will modify A. Why, you know, they cannot really modify this value, right? Modify that. So let's add our on change handler, and so that will always be kind of a function that will receive an event and that event um will have a target value. And what we want to do here is to set the sheet to the previous value.

you I agree. Maintain all the others. But in this case, we will say that A it's equal to event. target. value. Let's see if this works. That worked out. Now, one thing you also want to use, it's the React debugger. So I'm going to go over to the rendered sandbox and I'm going to inspect. We should inspect this, let me make this bigger. Awesome. And so make sure you do know how to use the React debugger.

I have it already set up. I have my component. I have my add component and there's the state. That's the state I added. And I'm going to go in and modify A, and all of a sudden my state has been modified. This will make it look like a senior, this will save you when you've got any state issue, which with the nerves of an interview that can happen. But if you have this, you'll bounce right back and it will show it will look very good in the interview.

Perfect, so let's go back and extend this behavior to all of them. So, as you see, I ignore, don't repeat yourself. This is a live coding interview, there's literally no time to sit around and and reuse components. You will get all kind of errors when you start adding layers to to your functions. So, as you see the reason this is bug free, is because it's very simple to debug. Perfect. So, there's that, we have our event handlers.

Let's check them out really quickly. B works, C works, and D also works. Perfect. Now, that's our simple spreadsheet and now we come in with that final, with that one requirement. That says, if the value of a cell it's a letter, so if they type AB, we should we should actually display the value right, the sum of a plus b. Now, to do this, as I mentioned, we we need to make a difference between value and display value.

And to simplify that, I will just solve display value here at the direct of the component. Because the first problem here is compute the display value. And the second problem is, you know, when they click, go into edit mode, when they click out, show the display value. That one I will solve later. And you need to communicate that to the interview. To always solve the easiest problem next. And so, in 45 minutes, you will solve easy, easy, easy problems, they stack up to you almost passing the interview.

So, let's first compute play value. And I'm going to do that with a very easy function, I'm just going to have a function that is display display value. actually, I love naming functions with a verb, because, and exactly the verb, the action they do. So we're going to have our compute display value. I do not need any inputs for now, because it's all in here. But I definitely need to know which cell is this. So, that would be the cell key, right? And so in the beginning, the display value right now is just the sheet of that cell key. And so let's let's use this. And then we just need to add here that if it's a letter, do a some, right? That's the only logic we'll need to add. But now let's keep place this really quickly and say, you know what, just display my value in a P next to the input component. So I'm going to close that tag and that would be inline function is not very performant, but it's okay. We're looking for the brute force. Perfect. So there's the one. Now, we can do some CSS to show this in line and do some flex. But for now, I'll just, you know what, I'm just move on with the functionality. Always code functionality first. Don't uh get tied up into the details of CSS. And then the interview it's over and you didn't even finish with the first part. Even if it looks ugly, the interviewer they solve this problem before, they know it, they know what we where you're going. It looks like the value it's always one because I copied not only the function signature, but also the input, that would be RB, that would be RC, and that would be our ID. And now we need to solve only this problem. Which is, if you have letters, show the sum. So let's solve that second problem now. And say, okay, if there's a letter. So I think they gave us this in the problem statement. I'm going to build thex right now if you get stuck here. Nobody usesx every day. So if you get stuck here, you just ask for help and look, I'll be honest with you. So I think this was perfect and I think they gave it to us over here. And it was AD, so I'm just going to go ahead and copy that because I'm just a regular dev and I don't writex every day. I was definitely a forward slash. So let's see if x. test if whatever the cell value is contains. thex value, then do something else like done show. So if the shit at the cell key matches

the objects, then I'm just going to console that log, it's a match and then the cell key. So I'm I'm going for a very easy kind of debugging, let's see. So if I type here AB, okay, so it's it's definitely B matches the user typed some letters. And now we only have to do the steps, right? We have to split into two and then compute the sum and return the sum. I will assume for the scope of this that they only only add two letters, not three. They don't do ABC, they only do AB or AC.

And so I will say that we have here the first cell and the second and there would be the the cell key.split. So it's a string, we will split by character. And finally, we just return the first cell key plus the shit at the second cell key. Okay, let's see what we got. So, if I would say this is a three, and if this is a two, then it validates AB. We get a little undefine over there. Let's check about what we're doing. Now, just go into use console log.

I'm not a fan of console logs, but for the purpose of the interview, you just have to go with. We are splitting cell key, but we should split the value. Right, because the value is actually what's AB. So the value is the shit of that cell key. As you see, if things are simple and you keep everything in the same component, it's just also easier to debug by hand. And so, 4 + 5 gives us 45, probably because we didn't transform those things to numbers.

So, the way it should work, it's a number of this, it's basically uh concatenating strings rather than summing, making a number sum. And all of a sudden, AB it's 9. So, that would be our brute force approach to the problem. Malcolm, you've faced some obstacles, right? What would you tell developers whenever, whenever they face a bug where they get stuck in a live coding interview? How can they go about it? How can they manage their own nerves first and then uh go back, identify the problem, fix it, and get back in flow?

Very good question. So, number one, we're going to start here. You need a bit of a picture. Sure of how things will work out. And this will help because even if you get stuck, if you have a good interviewer and I would say 60% of them will help you, they will help you out if you get stuck here because they know what you're what you're aiming to do. So you want to spend the first three minutes doing this. And then going into the code, as you see, I kept everything in a single component, literally, and I kept everything as simple as possible. I really this looks very simple and because of the reflex of production experience, most developers would go in here and start creating, you know, all these nested components. Then they would somehow iterate over this state, probably, you know, imagine I have this. I want to create four cells, rather than high coding it, they'll go and do a map, then you have to mess around with object keys and all that takes time and, you know, maybe 20 minutes of the 45 minutes are over. So I keep things very simple. I imagine there's no generalization, there's no abstraction, it's all here and I'm just high coding the values. And that allows me if there's a bug to immediately also trace it, because there's not so many abstraction layers in my code, I can easily isolate a specific bug. You know, and this is where uh if you have an obsession with clean code, it can actually play against you. Right, because that's something you do in a in a big code base where you want to um to keep things worded, but here is more about the simple thing that can work and allow you to to proceed. You are helping our students solve these things and get better at solving these kind of problems. What are the top mistakes junior mid level, even senior devs do in these situations and how would you what advice would you give them? Number one would just be start to to code. So coding first and we got to start thinking about UIs and state on paper, abstract and then go and project that in implementation and code. Number two would be using too much AI. So they get something like this, not try to solve it and just throw that to GPT or use cursor. The quality of AI solutions looks very good in the beginning, but we had people, you know, trying to solve this for for days and going in circles with GPT. And I'm talking about strong engineers that are, you know, very strong mid level, not not juniors. So whenever you're building a elegant solution, you start with a with a blank canvas. It's a bit like an

writer. When they get a book, they never will start with somebody else text. That's a disaster. And then number three, few people actually pay attention to this, but you want to be good at using the debugger. And if you're going to react interview tomorrow, make sure you spend 45 minutes playing with this debugger right here. That's a lifesaver. So I have it right here and I know exactly what my state is.

Oh we see it's crystal clear what is the state of my UI and it's going to show that you are a you are a senior. So if you combine this, thinking on paper with having the right debugging tools and keeping the code as simple as possible, you have very good chances to pass. Now, of course, once you finish the interview, you will have to talk about edge cases, which I did not covered. Uh you will have to talk if you are going for a senior position about accessibility and you will have to talk about performance.

But that comes at the end, then make the mistake of getting into any of those before you build the right for solution. Because they will end the call and the only thing they have, even if they want to move you forward to the next stage, is the final code you wrote. And so if we start getting distracted by by those edge cases or accessibility and performance, oh we add too many components and then the code is not working.

It looks like we did zero, right? It's a zero to one. Whereas if you start writing this simple code and solving edge case by edge case, those small steps accumulate into something that can actually be like, oh wow, they if they have more time, they'll probably finish this. Let's invite them over to the system design interview. And now, finally, when you finish this first implementation, you want to talk to your interviewer and make sure you mention edge cases that just take this implementation to face value.

So I would tell them, okay, so at the moment, we, for example, this only works if you have two references. Right? If we add A B C D, then it doesn't work anymore. The other thing is what if C references itself? You shouldn't be able to type A B C. There there should be an error if we find the kind of a self-reference. And what if you have a circular reference? So what I mean is, imagine you are saying C is equal to AB, and then you are saying B is equal to C.

All of a sudden, there's a circular reference and we should have some sort of an error handling. The other thing I didn't have handled. What if now I say d is equal to C plus a? This doesn't really work in nested levels. So, this function should probably be recursive. You keep going if you know, if the value of right of this first part, it's another expression, you evaluate that too. And so you keep going.

And that's pretty much it on the on the Excel kind of things. The only thing I didn't touch here is the on-click behavior. So, probably you want that whenever I click on B, we show this value. When I click out, you go back into showing the display value, and you do that with refs. It's unlikely you are able to cover all this in an interview. And this is why you should always prioritize getting the simplest solution to work and then be able to talk with the interviewer together to all these edge cases and how you'll go about it.

So, as a quick recap, whenever you get one of those interviews, start with a short wireframe, a really quick wireframe of your component structure. Identify state and use this rule of thumb, it should be placed as close to where it's being used. Well be careful when two siblings components need the same state, then you need to lift it up. And after that, watch out for state mutations and state changes, which usually come from only two sources in UIs.

It's either a user interaction or some data fetching. If you have this mental model, you'll be able to come up with something very close to this, and then going in implementation, keep things simple, go for the brute force, and walk through the edge cases at the end.