React.js Live Coding Mock Interview 2025 (Build A Recursive List - Advanced State Management)

Hi folks, today together with Bogdan, we are going to solve a mock interview. This is a real senior front-end interview question that one of our mentees got. And the funny thing, the interesting aspect of this question is that it combines hands-on react front-end knowledge with algorithmic and data structures knowledge. Which happens to be more and more common in live coding interviews, particularly in the US and European market.

den, are you ready? Yes, let's go. Amazing, then let's go. Yeah, so this is what our mentee was presented with, um, I'm going to start reading the problem statement. And if you're doing this in a real interview, you want to read this too and ask questions as they arise. So let's go with it. Um, we need to develop a component that will showcase high-level topic suggestions. Okay, in a list format, using the JSON schema from topic JS.

So, let's go ahead and look at this JSON schema, okay? Over here, perfect. I see it's a object, it's an array that has objects. And it can basically have another subtopic property, and then we see this kind of repeated again. Same properties, then again subtopics, all the way to the bottom. I see a three level nested object, but I think it can go even deeper. Hm, okay, so this is our data structure.

The questions you can ask here are, is this, you know, do we need to test for properties that are missing? Should we assume that topics is an empty array, um, are there any edge cases, but most likely they will tell you. Yeah, just move forward with this generic structure. There's no API call to get that, which makes things simpler. Represent each topic as a clickable bubble. Okay. So, this would be our topic, and for each one of those.

topic should visibly show if it's active or inactive. I guess they are referring to the enable status. If it's true or false, make sure you ask questions to really clarify what they mean. When a topic it's selected, and I guess that would mean a click, it should expand to display its subtopics. We can use colors to difference between active and inactive, and ensuring the design is clean and unattractive. Okay, nice. That's an optional requirement, display the number of subtopics in each topic card or bubble. Okay, so I guess for physics, we would have one, two subtopics. For classical mechanics, we'd have two subtopics. Okay, so now that we have the requirements strict, the first thing you want to do is to get done the component, the basic component structure, ignoring state and user interactions in the beginning. As a second step, I would go with the component structure, and for that it's great if you have some sort of drawing software. I'm using TL drawing in this case. So Bogdan, once we understand the requirements and we make sure we clearly understand them, we are going to aim for a graphical representation of the problem, right? And especially because this is front end that will also allow us to understand already the component structure. Now, um, what advice would you give people that might struggle with the time pressure, right? Because you have to do all this in 40 minutes. You have to understand the requirements, make a graphical representation of the problem, and then jump into the code. And we know a lot of junior developers and mid level developers and even senior developers sometimes have the habit of jumping straight into the code. What would you tell them? Jumping straight into the code, it's it makes him like a great idea. But um, it will most likely make you you'll you'll end up going back and forward. You'll write things you might delete, and it's also very hard, much harder to communicate what you're trying to achieve. You might have syntax errors. Um and so if you have a drawing, it will really have your back in the case of something going wrong in the interviewer, because they know what you're going to do. They will help you out, and so you'll look like a great engineer that just, you know, a a mistake in the syntax.

However, if you don't visualize and if you don't show what you're going to do, they'll just assume you don't know what you're doing. Um I know this takes a lot of time, do this for every all the steps I'm doing right now you should apply in your day-to-day work. This should be your kind of reflex muscle memory and you should always use this drawing software daily. And so when the interview comes, it's just part of your process. It's nothing new. So even though it feels like there's a bit more time investment, initial time investment in this, it's going to save you back when you're going to get stuck in the middle of solving the problem. And it will help you lead the interview to a successful um And poor bag then show us how would you visualize this problem? Yeah, so I probably talk out loud the requirements and try to make them just a wire frame it. So, pretty much, uh let's use a square, I'll say, okay, we we had this list of different topics, right? So we had one topic and let's say that was biology, right? That was number one and they mentioned a list of them. So we had biology, let's say we have maths for what I saw in the JSON file. maths and chemistry. If your interviewer doesn't collaborate, it will be harder to get this done, but most of them will be okay. So you want to do this fast. I'm going slowly because um for the purpose of the video. Normally I'll do this in the first five minutes. Um chemistry and what can let's say science. Whatever. So that's what they mentioned. We have this nested list, but then they also mentioned we might need each topic might have subtopics. So let's see how it would look like if maths would have a subtopic which would be algebra algebra and then maybe right so let's go down and then maybe we have here whatever calculus. I'm making things up right now calculus and they mentioned also that even calculus might have a subtopic like what can be differential equations. Let's see, right? So that's what we're building. We're building this kind of recursive structure. Um for now, I would leave this as it is and go and implement this basic structure and see if I can get it done. And after that

come back to it and add state and user interaction because they mentioned that all those things can be collapsible, expanded or not. And then there was this optional requirement. So, but I would communicate this to my interviewer to get buy in. So, number one, components structure. And this can be without any interactions. For the component structures, let's keep in mind we want HTML that is semantic.

And the reason we want to use semantic HTML is because everything has to be SEO ready. So, search engine optimization and accessible. As a senior developer, this is should be your own inner criteria for building things. So, it's something you need to be proactive about. They don't need to ask, they don't need to tell you, oh, this should be accessible. It's something you should bring up and say, okay, how much accessibility do we need?

I'm going to use HTML semantic just to make sure we are ready for a scenario where everything has to be super accessible. Or do we need to make it SEO ready and then discuss that with the interviewer? Just bringing that up will already make you stand out as a senior candidate. Yes. So, make whatever you're building, try to make it or explicitly mention it as HTML semantic and as SEO ready and accessible out of the box, right?

Yeah, so let's go to the code now. So, this is the starter code they presented us with. And of course, I would go ahead and write my code down as pseudo code. And so, what we need to render a list of um titles based on the topics.json or js file. And the other thing is we mentioned we want to use semantic HTML and we would need to at some point have some sort of recursive for the nested sub topic.

So, let's make this happen with React. The first thing I would need to do is I will import my topics from uh from topics.js. So, there we go, our topics. And now, let's just go over and always go for the simplest representation. I would use topics.map, so we pretty much go up to each topic. And we have a topic and then we go ahead. and render that. And so, we mentioned we want to make this semantic. So rather than using a div, I'm going to use a list. Let's use a lee. Uh I will still want to have this uh probably uh outer div to keep the layout stable. But let me add a outer um an order list element. And we will have our topics over here. Perfect. And now we'll actually give me a second, uh we will return a list element. Any inside that list element, we can actually render the top act. title. That would be our first implementation, the simplest one. Let's check how this looks like. Um, do I have this running on another port? Oh yes, it's already running. I'm going to stop it, just to make sure we start from scratch and run it again. Okay, so we have like a basic representation of these four topics. It's not much, but for now it looks okay. Let's go back and continue. Okay, so they mentioned we also have this recursive behavior. So if we have sub topics, we should render again another um another list, and again all the items, you know, sub topics. The problem is I do not really have a stop condition, I cannot really make nested for loops because this could go on for an undefined number of levels. And this is where we can actually make a recursive components to actually. And by that what I mean is that wherever we will find when we find a subtopic, we will just render it as a topic. And each topic that has sub topics, we will render them again as a topic all the way to the bottom of the nested object. So the first thing we need to do is to extract this in a specific render function of a topic. Does that make sense? Yeah, it seems to me like that render function will be the one that will be called recursively. Yes, it will basically call itself on each subtopic again and again until there's no more sub topic. So, a good understanding of recursion, it's crucial for

interviewing today in the market, and I wouldn't even mind interviewing if I do not know recursion. It will be a waste of time. Perfect, so we have our topic component. I will keep it simple. It will just return this very same uh JSX and it will shift topic as a in this case. So that will be our topic. And so what we want to do is to return a topic. And so this would receive topic as a prop. Okay? Let me zoom out a little bit. Check our code.

It's very simple, but ideally it gets the job done. Let's check it out. Perfect. So, it's pretty much the same structure. We didn't break anything. But now let's actually also render these sub topics now that we have the structure in place. So, basically here things will change a bit. And we want to say, hey, you know what, if there are subtopics, okay? So if a topic. subtopics. topics. linked it's greater than zero, then let's render another unordered list. Is that the same? Yes, the the unordered list and inside this unordered list, we iterate over our sub topics.

So we go with topic. subtopics. map, just like last time, we will get a sub topic and we will actually return a topic element. So this is the recursive nature where we see that each topic will call itself if there are any sub topics. Okay, let's check out what's our final result. Oh, there we go. Beautiful. So that's kind of our nested structure. This will be the first requirement. I do advise you to use if you can, um the React debugger.

Yeah, so if you get stuck at any point, you can always check the props in the state. We will add state in a second of everything. And that's what seniors do. They know the tooling really well. Um, what a mid level junior developer would do, would use they would use a lot of console log when they need to, you know, state their props if there's any error. Understood? Bogdan, maybe for the developers watching us that are not so familiar with recursion or the recursive way of thinking.

Can you maybe reexplain um the code part where you are uh implementing this recursive function? Um sure. So one of the um easiest way to actually understand it is to look at this componentry. You see this right here. Um you kind of see that it's kind of repeated, right? So we have a topic, then a list, then a UL, and inside there's another topic, then a list and a UL, and then another topic. So basically what happens is we say, hey, whenever we get a topic, which is this kind of object, right? We get the topic, then render itself, and if there's any sub topics, then use again the topic function to render that one. And so on, all the way here where there's no sub topic. And this is what you coded into the topic component, right? Yes. So as you see here, this is what we call in recursion our base case where there's no recursive behavior and if there are sub topics, then we go into a recursive. Oh, I mean, looks looks amazing. Perfect. And now I move on with the user interactions on state. So, going back to our requirements, they said that each topic, it's a clickable bubble, and whenever we click on it, there should it expand to displayed sub topics. This would be a bit harder to uh to reproduce, but always whenever we have a user interaction, think of what's the state and what is the state transition. So, we know that it's going to be like expanded or not, so that will be kind of a true or false. And then we know that that changes on click, so that's that's our state transition. Going back to our component, we know that each topic could be expanded, it could be expanded or not. So, I would add some very minimal state and say it's expanded and set it's expanded. And just use state, the most common React hook. Um, we're going to start with false. So, things would not be expanded. And if things are not expanded, we do not want to show the sub topics, correct? So, we only

should this if we are expanding. Let's go and check. There we go. So now even if everything is rendered, it's kind of it's closed and we don't see it. And finally, we would say, you know what, whenever you click on the title, let's expand that. So basically, we can have a function constant or toggle, um no, let's let's call this on click, so it's easier. Which takes a on click event, which we don't really need, and it will basically set it's expanded to its opposite side value. So if it was true, we set it to false, if it was false, we set it to true. And we pass that down to our title, but before that, let's wrap it in AP just to make sure that it only happens this on click when we click on the actual label, not on everything. Let's save and test it out. So, let's close this. Click on chemistry, okay, in organic chemistry hydrocarbons. As I mentioned, if these things don't work out, you can always use the component inspector, go over here and figure out the state. We see the state here, it's false, right? We know physics, it's somehow not expanded. And now it's true, and now it's false, and now it's true. And you can do this for any component. Perfect. Now, before you finish, you always want to prove that you are. Before you move on, make sure you check the requirements again, they mentioned that there should be a. Each topic should be visible visibly show its active or inactive status. I think they were referring to this property enabled, so we could actually make some sort of conditional rendering. Basically say, yeah, we can add some styles and say that this P should be of a different color if it's not enabled, so let's say that the style should be um let's set the background color, so the background color background color um should be uh if if the topic that enable then it should be transparent. Let's see if it does it is and if not, it should be.

I think analysis flew for a workout for this dog team. There we go. So basically, just some conditional rendering. And finally, I think there's an extra requirement for displaying the number of sub topics in each card or ball. Let me go back in and basically we have our key, so I could probably add an extra span here. I do not want to just add it as text, that's would a big idea. And then go over here and say this would be the title. No, the topic topic.subtopics.length. And let's see how this looks like. There we go. Now we only want to show that if there are subtopics, or we need some conditional rendering. Let me go back and say yeah, now this is where JSX gets ugly. But we say basically if the topic.subtopics.length is greater than zero, then do that. Let me zoom out a little bit. Okay, yeah, there you go. So this is now our nested component. Amazing job. Bogdan, for the people watching us both, I guess the code will be available for you to try yourselves. And that's what we advise you. Bogdan, are we, are we done with the requirements? What would you do at this point in time? We are done with the requirements, but a senior trade is being able to review your own code. So before moving on, I would let them know, or let my interviewer know that I want to read, and kind of do a code review of my own code. And one of the first things you'd see right now is that we do not have a key property on this topic, which means React is not really able to, if there's any re-rendering happening, the whole list will get re-rendered because React is not able to identify which topics didn't change. So, probably one of the quick fakes, it's to add a key, which is be, let's say, topic.title, assuming that the title is unique, right? And the same goes for the subtopic. Whenever you have a map, we want a unique key. That's number one. And then number two, I would go into discussing um accessibility, um most of this, it's accessible. But you could go deeper.

with area attributes. For example, whenever we enable this, we could add an area attribute that tells screen readers that this option was expanded. It's called aria expanded. That would be something somewhat very senior, we would know. Or the fact that you could use react. memo to memorize this topic, so we don't need to render it if the privacy don't change. That would be performance. So there's all these nuances, but mostly around accessibility and web performance, and you want to go into it from a point of view of, okay, let me give you my own code, because that's something senior candidates can do by themselves. They they have their own standards and they give you their own code and they have their own excellent standards for their code. Amazing. What about testing? In terms of testing, probably we could unit test this component. We could separate it and yeah, just unit test that, you know, the expansion works on click with a with a click event triggered. Uh there's no data fetching, which makes things very easy, but probably we could, um with a unit test here, we already test most of the most meaningful part of this code base. Um as we see here, the logic is very limited. Um so unit testing would be more than enough for this use case. But if they do ask about testing, make sure you mention both unit test and end to end test and you are ready to give examples where unit test unit tests may make sense. And examples where end to end tests would make more sense. In this case, probably unit tests make more sense and it's very obvious because you see they told us develop a component. So whenever we talk about function or component scope, it's probably going to be unit test. I mean in the UI, this UI, it's a replication of the same component based on the recursive logic. Over the nested object. Uh pardon, a few words I wanted to help just for the audience looking at how you went through this problem, and I think if I think about the people that we coach, the developers that we mentor on daily basis at the senior dev and if I think about myself a few years ago, probably the biggest challenge I would have with such a problem would be the regressive point. And not because, you know, you see they told us develop a component.

I wouldn't have the skills probably to do it because it's a simple, it could be a simple function. If we think about it, you know, that it's obvious it's fake is simple. It's just that I would probably think about so many things at the same time. I would think about if I wouldn't have this methodical approach and this is the first point that I wanted to make. It's just imitate Bogdan and stick to the process and have a process, right?

And do not try to solve many problems at the same time, one problem at one time. Which brings me to the second point, point very important in computer science to divide and conquer. Whenever you have different requirements, just go step by step, do not think about everything at the same time. The third part, it's pay attention to the data. And that's what Bogdan did, because the data will, in this case, also tell you how the UI will look like.

Um and the fourth and final point, I would say it's know your tooling, right? You were using the browser debugger, the React debugger, uh to make sure not only that you come across as a senior, but that you make the whole debugging process less of a guessing game and more of a very methodical way of solving problems. Bogdan, anything you like to add to the four points that I mentioned? Um you know, you made a very good summary, I would also add the fact that what I did might look very simple, but you'll have to do this under pressure and so um you want to get there's one thing of knowing how to do it and the other thing is knowing how to do it fast under pressure with someone looking at your code.

But uh and that's why we need to develop that muscle memory. So make sure you can you you use the tooling software on a daily basis if you are a front end developer. Uh make sure you can touch type and make sure you're always you feel at home in the code editor as an engineer, you should have no problem pulling up a uh you know, a problem like this one and try to solve it. Um and the second thing is it's it's not so easy to find examples where you combine recursion, which is a traditional algorithm and data structure interview with a real-life scenario.

So it's a very valuable problem, we will add the link to the YouTube uh video. Make sure you do the problem. We know a lot of developers that are like, oh, that's simple, and they don't go ahead and do it, take it, do it hands on. Try to solve it yourself. you can translate in under 25 minutes from scratch. Once you do that, then you can be, you know, ready to to go in and do it in a real interview.

Yeah, one anecdote, it's we had a developer watching one of our videos here on YouTube, and they saw Bogdan solving the problem and they were like, oh, this is easy. I can do it. They did not try to solve it themselves, then they got it in an interview and they failed the interview. And the moral of the story, it's watching, it's not the same as doing and it's very important that you not only watch, but that that you read yourself.

With that being said, Bogdan, thank you so much, amazing performance, you've passed the interview and we only have around eight pages left. So see you in the next one. And see you, folks, in the next one for the people watching us that are interviewing, make sure you check the resources in the comment, specifically the free technical assessment that will help you find out your interview readiness score and your technical gaps.

Thank you once again Bogdan and we will see you folks in the next one.