Senior Frontend Developer Interview Questions

hi folks D here from the senior Dev and uh today together with bden we're going to go to a bunch of senior frontend interview questions these are real interview questions that we've got ourselves in senior front interviews but also our mentees number one we're going to start talking about tooling right and the first question is can you tell me about your experience using webpack what is it use for uh weback it's a module bundler so we basically use it to uh put several JavaScript files into a single one that used to be necessary because in

the browser um you basically in order to add JavaScript you need to place a script tag for every Javascript file you have and when you have a big application with hundreds of files that's just not practical so bundle um weback will uh will kind of bundle all that it will parse all of them and based on your imports and exports and put them all together into a single bundle and then we can apply different optimizations um I worked a lot with weback in the past basically setting up projects from scratch and doing all kinds of

configurations yeah nice Bon are you familiar talking about weback and module bunders are you familiar with the term tree shaking three shaking as in weback it's basically what weback will do when we ship our bundle to production and it will basically try to find that code those are modules that maybe we imported in our code but we're not really using or parts of modules and it will basically try to eliminate them so our bundle is as small as possible and we get the best web performance amazing have you used um tree shaking professionally in production

uh at any stage can you uh give me an example of that uh yes as far as I know in version five it comes by default so every time we use weback it will try to T Shake our code one thing you want to be aware of is that it only works with es6 static import so if you have any any module in your dependencies or you're using commonjs Imports with require then weac cannot really appre shake that so you got to be careful because yes weback ships with it by default but if we don't

use those kind of modules then it's not capable of really understanding if it should remove that code or it's not being used which modules where uh so us six static inputs are the ones that do uh allow weback to do three shaking and commonjs you know the old require notation those ones cannot be three shaked because they are Dynamic and they are evaluated at run time so they they are basically functions and weback cannot really use them to build this dependency tree and figure out okay what's going wrong in there can I drop any of

that code until it gets executed in the browser excellent seems like you know quite a bit about weback now um what is talking still talking about weback and and tooling and module bunders um you know what is a dependency graph and what is it used for in weback uh the dependency graph in in weback it's basically what weback builds from our entty point so it'll basically take our first file and then figure out and go down all those import statements we have at the top and from that it will keep going down until it reaches

basically the end and that's basically a three structure that it forms and that's how it stores basically all our modules and then it's using that to uh transverse it to go through it and find out if there's any modules we need to drop or which ones are in production so it's the kind of the main abstraction in web pack and it will always be used to put you know to go from Individual files to a single bundle cool now we're GNA move on with a question about CSS injs basically can you explain what CSS injs

is and can you give me an example you know what are um what are some use cases for CSS injs uh yeah sure so CSS injs appeared because we writing all this JavaScript and we have a lot we have a lot of interactivity and we basically want um to change CSS Styles when a certain state or certain variable changes and CSS injs allowed us to um to basically have Dynamic CSS where you click a button and some CSS CH changes immediately um you could do that with classes like you would assign a different class to

an element but it's just a lot easier if you could just swap colors or directly do things with JavaScript variables inside CSS that usn't that was not possible before because you had static CSS files uh and with CSS injs we write our CSS inside JavaScript files and then webpack will basically somehow extract that and build different classes and attach them to attach them to um to the um to the JavaScript uh to the HTML Dome at run time but we don't need to worry about that so it basically allows you to write your CSS in

JavaScript and leverage a lot of dynamic dynamic Styles so you have the dynamic language like JavaScript but you can do styling with it awesome so you already mentioned some of the advantages right of having JavaScript control um variables inside your styling but what are some disadvantages of using CSS injs uh well one of the main disadvantages is that because your styles are now in Javas in JavaScript files you cannot really extract them and do certain optimizations you can do to CSS um and one of the thing is you cannot really cach your CSS files so

if your CSS didn't change back in the days you could have the user uh storing that and browser side because you attach a cash policy with HTP headers to it like cash control and they would store that and in a subsequent visit they wouldn't have to download all your CSS but now all that CSS it's inside our uh Javascript file JavaScript bundle it's all together which makes our bundle bigger um it's a bit harder to price but it's also non-cashable uh you can actually counteract that by extracting uh with web pack your CSS at run

time um and ship it separately uh but it's still still not as easy as it used to be when you had your CSS separated from from your JavaScript understood it's also harder to debug your CSS uh because again those classes that weback generates they're unique hashes and all of the sudden it's not as easy as it used to be to understand why a certain element looks a certain way there is some tooling right that um csjs usually brings on to make that debugging easier um one thing you we haven't chatted about it's the the performance

um how how how does it affect how does CSS njs affects performance so that's uh one of the main things is because you cannot cash your CSS you're loading it and it will decrease um the performance and um yeah it will also you might also have a lot of uh cumulative layout shift because your CSS gets now applied when uh when the JavaScript bundle gets pared so um in the critical rendering path we usually evaluate CSS first and we apply it and that ensures the fact that there's no flash when you load the page but

now because we evaluate the CSS at the end you might have cumulative layout shift when the user loads the page things might move around and you got to be careful uh and sometimes split your CSS and ship CSS injs for the dynamic parts and then still use PL old CSS for most of your grid elements so you have a stable page and the other thing is because we are creating new components for example iio style components in react every every time we style a heading or a native react element we end up creating another component

and in a big component three that will create a huge component layer uh which it's always a huge component Tre a very deep component Tre which is always a disadvantage because it makes debugging harder and of course a bigger component Tre it's also harder for react to reender all the time even if react is very um effective you want to keep it as small as possible awesome V then we're going to move on to the next question um and we will talk about JavaScript Frameworks specifically react um have you worked with react in production so

far uh yes I worked with react for the last uh pretty much since 2015 so that will be around pretty much since it came out yeah awesome then you're probably gonna fly through these questions uh first question is you know what is a pure component in react uh pure component in react well I think so pure component used to be uh when we had components and you wanted to avoid the reenders you use one of those because it would compare the incoming props with the existing props and if they were the same it would skip

the render um You probably don't need it today because we use Hooks and hooks are by default memorized so whenever you do a whenever you do a set State um react already checks if you are updating the state to the same value and if that's true it does not reender the component so it kind of comes by default but back with class components we had to use pure compon components cool um another another type of component uh question is what is an error boundary component you know what is it used for why do we have

error boundaries components in react uh yeah sure so basically error boundaries um help you limit the impact of an error so if you have a data fetching error in some component you can wrap it with an error boundary and that will uh at some level localize the error so doesn't go up the component three and you don't show the whole thing the whole application broken but you can actually show a placeholder for that one component that um something went wrong uh so it allows you to localize and have a much better predictable UI and also

have no layout shift when you have the servers they can totally destroy the UI if they're not managed awesome very well um now still talking about react in this case we will focus on react Hooks and the hook that we are talking about is you know are you familiar with the use effect hook tell me more about how is it used um you know what would be some advantages and disadvantages of using use effect uh yeah sure so we basically use effects to uh trigger a what you call a side effect in react that would

mean uh when a state variable changes maybe imagine we want to do something else like we want to make a call to our analytic system and to tell something changed or write into local storage for example example that would be an ideal case for effect um I know when they came out um myself included and all the community kind of abused effects and we using them for everything so we would use effects to change a different when one state variable change we use effects to change a different uh variable but the thing with defs is

that they U they run after the component reender and they trigger another reender so if you're not careful and you abuse them you end up having so many reenders in your component and of course reenders of parent uh will cause reender of a child component so that will really it can end up affecting your application if you're abusing them um performance- wise second question about use effect hookit why can't we use an as async function as a callback to use effect well probably because in a sync function returns by default the promise and the return

of the use effect hook should always be a cleanup function that allows us to if we for example in the effect attach something to the on scroll effect to remove that Handler because if we don't remove it and we end up re rendering we keep attaching handlers to that event and we might bloat the browser so react allows you to return that cleanup function but when you use a sync you're always returning a promise and react doesn't know what to do with that promise because it's not it's it expects a function so that's why uh

you get this lary iting most of the times that tells you hey you cannot you cannot use an an sync function here yeah awesome totally makes sense we are going to move on with a question about State okay and I want you to imagine that we have a simple front end application with the following State okay number one we will be fetching some data from the back end right then we perform some user authentication and um set some general user settings that will affect those those um user settings will affect the whole application and my

question is you know when we have to do with such requirements on the client side what would be the best solution to handle State Management in this application and why uh sure okay so we have backend we have data we get from the back end we have authentification state that you mentioned and some global settings right yes um okay so I'll probably Place those differently because of the requirements on them uh so usually uh from my experience data that comes from the back end can stay in component State unless it's needed by two or three

components where you could usually just um lift it up and you'll have a bit of prop drilling but it should be manageable with that kind of data um when you have authentification State you usually want that to be globally available to any component because some components might need it to see the user goals and permissions that's why I'll probably use something like react context because it's very useful to broadcast uh the state through the whole component Tre and for the settings um it looks like there might be some non-trivial State transitions in the settings usually

if you have maybe complex transitions like a user can be premium or not and that will change many different settings across the apple is that's what I worked with in the past uh in that case you might look at the state machine or you might need a reducer pattern you can of course use something like Redux for that or a smaller like a twoand library but you do need a reducer pattern when you have these complex State transitions um you can use use reducer with context that also works uh so that's how I would um

that's how I distribute State these three different ways cool um now still sticking with State um one question about essential and derived State specifically could you explain the difference between essential and derived State uh the difference between essential and the state uh so basically essential state would be state that um changes by itself changes independently and you cannot use it any further and the I state state you could calculate based on the essential state so just to give an example if you had a component that displays like a breakdown of a shopping cart all the

different items that you add there they're probably essential state but the total and the vat amount they are the state because you can compute that based on all the other items so that would be an example and usually you want to keep as little State as possible so you want to have only the essential state in your state hooks in react amazing cool um now final question about State and react uh you know what would be the disadvantages of placing State inside react context i' would say number one is that if you lift state so

far up anytime that state changes every component that will be connected to that uh context will also change so if you have state that really changes independently and it's consumed by different components you could also split it into different react context to different providers because the components that will subscribe to those will be different you'll have overall less reenders uh so that's one of the biggest problem when you lift state in general but especially when you lift it to context it will end up causing reenders and as a gener rule I try to keep state

or we should all try to keep State as close to where it's being used yeah amazing bton um yeah we have a bunch of questions two more two more categories um I will be asking you about uh we're gonna start with testing right and uh specifically you know how would you go about testing a react application yeah what you know if any let's think about a midsized application not too big not too small uh there are no test let's see development team was pretty crazy they've written no test they just you know usually happens we've

seen that in companies but they stitch together a bunch of components there's data fetching there's authentication there's all all the kind of functionalities that you find on a client side application built with react how would you go you know you are hired to um bring that up to to implement some best practices in that one specifically testing how would you go about testing this kind of application uh okay so we have a react application that haven't been tested um I would probably inspect the codebase and try to decide either we want to do unit start

with unit test or uh integration test or entn test which is the typical testing pyramid um I probably in my experience in the front end one of the best tests to have are entend tests because you test the features which is very clear and then it allows you to refactor your code behind it without changing the test um and if we have any components that we reusing like imagine we might have input fields that are being reused or buttons or any kind of component that has ideally some logic and is being reused like a drop

down in that case I would write some unit test on them I'm not a fan of unit testing everything just because in react you didn't get a lot of value for testing pure components like just if an image renders uh we could do that some people do that in order to hit the code coverage uh but I would say having some good ENT test having unit tests on reusable components and strategically choose some integration test uh should be the way to go and how do you know you how do you strike the perfect balance between

ENT test unit test and integration test in the front end uh that's a very very good question um I would say you need to understand if we write a lot of entend tests but we have imagine no unit test and integration test what will happen is that when your entry test fail fails it it's good you know that there is a bug but it will be extremely hard to go through the code and find exactly where it is so the more unit an integration test you have the easier it is when you find a bug

to localize the when you make root call analysis to localize the the bug boundary and really eliminate all the other sides of the application if you only write 10 to0 test uh you will have coverage for your features but when something breaks it will still take you hours to debug so I would say uh I would be smart about it and understand your application and then have a have a certain balance I cannot give you exact numbers but I would write a lot of unit test and a lot of ENT test to finish the feat

to cover the features and strategically some integration test on on the critical features like if you have login or if you have payments you got to see also like what's more critical in your product uh you did mention the word code coverage when you were talking about unit testing um you know can you tell me more about code coverage like just shortly what it is and um what would be the appropriate amount of code coverage in your opinion in a fronted application uh so yeah code coverage it's the amount of code that EX executes when

we run the test basically so people say it's the amount of code we cover in we cover it with test but it's actually the amount of code that actually executes when you onun the test um in the front end I would say it's a bit more tricky than in the back end where it's a bit easier but I would try to keep it all the way up to 60% whenever possible if you go under 60 then it will be quite unpredictable and the test are unusable because you can't really trust um there's a lot of

code that's not tested so the test might fail but you don't really know why do I failing so 60 to 70% would be good I think going over 80 to 90 it's a bit of an Overkill and you didn't get a lot of value from those marginal test um in your last uh Team or company you know what was the code coverage you were aiming for and you know did you had any anecdotes anything that you can tell us how did it went for you um yeah sure so at least in some of my roles

I worked in the finance industry where they they made it was a general rule for the company to have around 9 5% of code coverage uh we ended up writing a lot of test that made literally no sense um you you have a lot of files that sometimes are just explicit they decare types you had to exclude all those and it was pretty much of a hard measure everybody was saying they do tdd but in the end everybody go test before pushing their PR um so I'll be really careful with these measures because in the

end people say they would do it and so on but uh but yeah I had that experience I also been in teams that didn't wrote any test at all to be very honest there was uh CS that was a disaster and I would say the perfect balance is in the front end 60 to 70 in the back end I would go a bit more up 90 to 80 80 to 90 95 uh it's still doable because the back end again it's it's a bit more functional and it's sometimes much easier to un need to test

or to modularize things and it is in the front end cool now um let's talk finally final uh final category we will talk about web performance right um and question here is can you explain FCP okay what are the causes of a bad FCP score okay so FCP FCP would be the first contentful paint uh which is basically the time it takes since the user hits the uh the enter button in the browser to display something and to display anything to them um and usually it's really bad if you ship a lot of JavaScript that

is client side Ender so it takes a lot of time to part all this react bundle and interpret it for the browser to show something or you don't use a CDN so maybe the assets are not compressed or they're not cached and so it it literally just takes a lot of time to to do that or you have a lot of CSS uh CSS CSS in the header uh has to be all interpreted before we move on to JavaScript and finally start incrementally rendering the HTML um so if you have a lot of that it

will also take a long time so these are three CES that I've seen in the past that's the first thing I would look at let's suppose you take charge of a front application you run your um analysis whatever tool you use Lighthouse For example and you realize that the FCP it has a very low FCP score how would you go about fixing it uh so okay so we saw that the FCP is low on lious I definitely r a couple of analyses just to make sure the score is legit and once we have that uh

I probably as I mentioned look first into the CDN it's usually easiest thing to do and gets a lot of benefits if there is not one set um and then probably I would uh use something to inspect the bundle and see if we can remove any part of the JavaScript that's not being used and if that doesn't still work I will look into code splitting and really only load the JavaScript that you need for a specific page I'll probably talk to the product managers and see which are the pages that are more critical for us

to to load fast usually it's not all the pages and I would focus on those ones and load split to make sure that uh we really load as little JavaScript as possible and maybe defer some some of the JavaScript or a sync loaded uh you can do that with weback uh with react. lazy also you can split your component Tre uh so basically code splitting would be one of the biggest um things I will do after we add the CDN and we make sure we have caching and compression in place so number one CDN caching

compression number two remove um whatever Li lies that you can remove that are adding way too much JavaScript to the bundle uh number three code splitting and and shipping different chunks of JavaScript as you need them right to make that lower have you considered and when do you consider something like server side rendering let's suppose this is a react client side um client side rendered application and you've went with all the optimizations and still because of the size of the application the application is too big and the FCP it's way too slow um would you

consider server side rendering what would you know would that improve the situation or not um server side rendering when done well it will definitely improve uh by basically removing by basically yeah showing instantly we ship the render HTML to the client so they will get something immediately they'll see something uh it does add however complexity to your code base so I know in some use cases where people rushed into Ser side then they had to roll it back I would definitely look at our product and if the product is very sensitive to loading speed or

sensitive to SEO then you'll get a lot of benefits from server side gring but if it's not if it's like a sass application where it's like accounting software then there's usually no value in serite rendering so you would stick to CSI still because it's not yes yeah probably in e-commerce in something like e-commerce or the media where you have a newspaper they want to load very fast and they're very sensitive to SEO they're probably most of them using serviceing asome ban this was it for today we uh covered a lot of topics from CSS injs

to react react hooks to weback to tooling to testing and now on to Performance I hope you um folks enjoy this we um we're going to publish some more series on this thank you B for this one and we will see you in the next one see you in the next one