How NOT to Fail A React Interview: 7 Junior Mistakes To Avoid

I've done dozens of react JS interviews at Junior mid and senior level in the process I went from getting stuck with simple react problems to getting six figure offers from several companies all this while the job market it's completely crazy today I will share with you the seven most common reaous interview mistakes developers make that stops them from passing the interview and getting an offer if you don't know who I am I'm Bon principal engineer and co-founder at the senior Dev where in the last 4 years we helped over 250 JavaScript Developers level up to senior and Beyond now the number one mistake

it's modifying State directly or mutating state directly as you see in this example I have a list State and I am modifying that array directly in the on click Handler this goes against the re principle of immutability State should never be changed directly we should always compute a new version of a state and use the state update functions this ones we actually publish that update when we do that react will update the state recompute the fiber for this component finally compute the virual Dom and then follow the reconciliation algorithm to figure out the changes and commit them to the Dom always compute

the new version of the state as we do here we see a computer new array and then use the state Setter to update that value the second very common mistake it's declaring a component inside another component the problem here is that whenever my component gets rendered list element gets red declared that means the whole element gets recreated and that makes react believe that every time we reender my component the list element it's a new one which will cause a reender of this whole list if this would be a big list of thousands of items we would have a very expensive and unnecessary reender because again react

believes this function it's different for every render it gets reassigned all the time to avoid this you want to always declare components outside ideally even in a different file this will make it extremely easy to apply optimizations like use memo and it allows react to really leverage all the internal optimizations that it applies to the virual D number three it's abusing the use effect hook this happens when you have several State objects and you might want them to change in a chain effect so when the user clicks on changing the color I want to set a color to Blue but I also want to increase my

counter a natural way to do that is to attach an effect to color and set what whenever you change the color also called set the count the problem with this is that effects will run a the end of the rendering process so basically react will recompute our changes do the vual D reconciliation commit the changes to the Dom and then run the effects and then it will start over and doing an extra reender this can be a huge performance killer effects should not be used for State updates like this but rather calls outside the system outside our application instead you could actually run both state Setters on click

now a lot of people might think this will also trigger to reenders because we up this stage twice but in reality react will use the fiber tree to batch those updates and only trigger one reender and commit once to the D the fact we don't have an effect here means there is no reender after the first render it's just going to be one single render with a new state so avoid use effect as much as you can and only use effects when you need to make a call outside the component either that's in the back end or setting something in local state or cookies you shouldn't use effects to chain State updates instead trigger the State

updates directly in the event handlers and by the way if you are interviewing right now make sure you also take the free assessment we put together this assessment contains dozens of real interview questions we've been collecting over the years and it will give you a good idea of where are your skills right now so you're better prepared for your next interview check the link in the comments to find out more number four it's not using hooks at the top of a component this one it's very straightforward but whatever you see the code always put hooks at the very top never have something here hooks are the first thing that should happen

in a component this is one of the two rules of hooks which if you're interviewing right now make sure you review and so basically every component should look like this where at the very top we have all our different hooks either that's context hooks State hooks or use reducer Hooks and then our event handlers follow number five it's not having stable keys for your list items basically using indexes from arrays as a key item this is a very obvious one it's very well mentioned the mentation but people still do it especially in life coding interviews the problem with this is that in order for react to have a

fast reconciliation algorithm react assumes that two elements are not the same if they have a different key what can happen is that whenever we change the list by removing an element so imagine I have you know couple of items and I go ahead and remove this one I remove this one all the other IDs will change because all these elements might be shifted in that scenario react will consider that all the elements here have changed and the keys are what we call unstable and it will not be able to reuse any of it so it will reender the full list instead you want to use stable IDs ideally from the back end for your

list items in this case my backend data has IDs and I'm using that directly as a key in this way react knows which elements are still there and which ones have changed so it will never reender a component that didn't change which makes it a lot more performance again it's one of the most obvious ones but be careful because since so many people still mistaking this one especially under pressure in life coding interviews the next one it's what I call ambiguous components this happens whenever people tend to over engineer their code and start creating components that might render different elements depending on a

type prop in this case depending on the Ty prop I might render a button or a link or a drop down the problem here is that all the possible props that these different elements might have separately are now together in a single inter phrase which will be huge this makes the component a lot harder to test because there's just so many more test cases it also makes it much harder to understand what's going on to onboard people on it and just adds a lot of complexity the solution is to have individual components in individual files that are as small as possible can be tested and used independently and can grow

independently this follows the single responsibility principle and the interface segregation principle from the solid principles and if you were able to mention this you'll really stand out as top engineer finally this is what I call Consolidated context which means we take different data that might change independently and that different components might not necessarily subscribe to and put it together in a single context provider what will happen here is that number one we're going to have a huge interface here a lot of props and so of course everything is more error prone number two whenever any

of those context State changes we will update everybody that subscribed to this what I mean is if the notifications change everybody that's actually using team and user will also rerender instead you want to create different context and context providers so we put teaming in one of them we're going to have a for example in another one the user provider and the notifications in another one this gives components the the component the freedom to subscribe to either one or two which means we will not have unnecessary reenders because as a component now I really only subscribe to the context I'm actually using whereas

in the previous situation it was a All or Nothing scenario this will considerably decrease the number of unnecessary reenders in your componentry and make the application much faster knowing these mistakes will make you perform a lot better in interviews but if you really want to be ready for your next react interview make sure you also check out this video and this other one where we dive deep into common interview questions in react to make sure you also nail your next interview I'll see you there