Frontend Interview Questions 2024 (Part 2)

we've done over 150 front-end interviews and here are the top seven most asked front end questions you should know if you want to pass an interview as a senior front-end engineer in this video we will also show you what's the number one mistake most frontend developers make in tle interviews the most important thing to focus on if you want to stand out in a frontend interview and if you stay until the end we will reveal a sneaky trick to take your front interviews to the next level let's go question number one what is the difference

between between cookies local storage and session storage in the browser okay so basically cookies have a limit in terms of storage it's around 4 kilobytes um they are server and client side so server and client that means whenever you make an HTTP request you'll send the cookies through that's why they are great for authentification um especially if they are https um protected and uh yeah they're great for storing things like the token or anything you want to share between kind of share State between server and client and that you want to synchronize seamlessly because they

get sent over by the browser um local storage uh the limit is much higher I do not recall how much but it's much much higher um it's persisted indefinitely so persisted forever uh versus cookies that have an expiration date and it's great for storing application State um if you want to persist in any of your State uh whenever let's say you have some user state that they close the window but you want them to still have it um like let's say the setting of the team if you have a dark team or a like team

and then session is a bit more peculiar because this one does get deleted when they close the tab or the browser window so it's not used that much but you could use session storage for things like whenever you want to store the form inputs you don't want to this um check out pages and the users they start typing it out and if they refresh you do not want them to to lose that so you can store this in session storage it gets automatically deleted uh when the users close the tab so you don't need to

care about cleanup cool now we're going to move on with question number two if you are setting up a new front end application what are some optimizations you would put in place in order to make it more performant and also maybe you can briefly explain each of them um sure so is it a can I use a module bundler is it a mod frontend application could you give me more detail yeah let's suppose a react application client side rendered um you know let's use weback as a standard uh as a modu bundler and feel free

to to pick it up from here um so we probably need to bundle this in a bundler and probably the first thing you want to do is to polyfill the code so number one I will definitely polyfill um that's just because you do probably want some Modern features of JavaScript and not all the browsers support this and we don't want to worry about it so I'll probably bundle our code and number one polyfill it which will increase the size of our bundle but it's just necessary um can you explain in in two seconds how polyfills

actually work basically you look for different language features in your code like promises or the spread operator and then you check your target browsers like if we're shipping to Internet Explorer 11 and then you figure out okay does this browser support this JavaScript feature and if it doesn't then you replace that with some function written with JavaScript browser supports so it's basically kind of replacing um or adding new code to your code base to support or replace features that maybe your Target also doesn't support um so we poly fill our code that's number one number

two um we bundle it together um so we're going to have this big bundle and the number two thing you want to do is to apply compression so we don't want to ship a Javascript file we want to ship a jip file and then with content negotiation indicate the browser hey this is a jip file and then they'll take it decompress it and so here we decrease probably 70% the payload over the network so we increase loading time um and there's a couple more optimizations that we can do through addition in JavaScript this is kind

of uglify uh the code in minification so these two uh they are both kind of code optimization and they take Cod we written and uh kind of remove new line characters and they replace variables like we usually have this long variable names they replace them with very small onel variables it's basically transforming it in code you cannot read but it's likely smaller than the initial file and it's okay because the machine doesn't really care the browser doesn't really care how we write our variables they can just executed um but because we do all this we

also will need to emit some Source Maps these are basically um extra files that will map the source code to the code we actually distribute and so whenever we have a bug in production You' be able to know in your source code where which is the line of code where that exception happened if you don't have Source Maps you cannot debug in production does it make sense so far yes 100% we you know we have to uglify this in order to Minify it but then it's just machine readable so we need a source map for

the developer to be able to debug this in production yes exactly and all of this all these optimizations you could do with weback or if you're using something like a modern more modern bundler like uh Vite they will come out of the box so they all happen under the hood um and then number three I would definitely look into code splitting just to make sure we only ship the JavaScript necessary for the initial load and we can lazy load or defer the uh the JavaScript that's not strictly needed for the initial load so that would

be my third optimization when it comes to um to JavaScript now this is at module bundler level um so all this is done inside the module bundler once we have the bundle already built I would also add um yeah more optimizations down the RO like maybe a CDN optimizing images and fonts and whatnot awesome makes sense now uh what about tree shaking oh that's a really good question so so that would happen by default in weac and most modern module bundlers um we just got to make sure we're using the right modules so we need

es6 modules if we do three shaking in our code amazing B now uh we're going to move on with the third question which also has to do with performance but it's more focused on when we have big assets okay let's pick images the question is you are building a frontend application with very big images maybe it's an eCommerce store let's imagine that very high definition pictures right how would you optimize this for Max performance uh sure yeah images are always tough especially because designers don't necessarily want to compromise and they just want these big images

normally a header and the footer and that takes a lot of work to actually make um yeah load well so I'm imagining we have maybe one of those big images or product images maybe so how can we optimize that size Matters you really want to ship the minimum size that you can so you don't want to ship a 3,000 pixels image and render it as 800 pixels element um so here you want to ship the minimum now the minimum means of course you want some sort of uh Clarity um like you don't want to you

don't want to show Pixel stuff it's just going to very low quality um once you have the size like Dimensions I'm going to call this Dimension Dimension you want to look into compression and you can still also do image optimization I'm not going to get too deep into into here but the tools I worked with can remove metadata from the image or you can modify what they call the color space to include less colors the image looks a bit less vibrant but it contains less data so it's smaller um and then of course I would

always use the webp format uh whenever we ship to the web it's the most recommended for uh web performance PNG it's okay but webp is the best you want to put all the images in a CDN so you have the right um caching policies on them um and then you can also look into lazy loading lazy loading images if they don't need to be visible on the initial load you can either lazy loading or load on scroll this is getting very popular these days to load images as the user Scrolls uh you got to be

careful there because uh those things might affect SEO but in general they're okay and because you do lazy load but we do not want to have any cumulative lay of shift you would need to specify width and height um and of course you can use use the source set attribute Source set to ship different images depending on uh the viewport on like the device so basically you can ship a different image on mobile and then load different image on desktop it's pretty much the same image but you can create smaller thumbnails of that image automatically

and usually CDN offer that out of the box like modern CDN would create the thumbnails for you and then give you a snippet that already includes source sets so your image is as small as possible in the different devices awesome understood well it there's a lot of different ways you have to to deal with images let's let's understand a bit why what these two questions that b and just answered have in common and what they have in common is that they both deal with Performance challenges in the frontend you see the reason why most frontend

developers struggle with technical interviews it's because most technical interviews don't actually test you on your front end skills like building components and writing code but on secondary skills like performance optimization testing those are exactly the skills that most Junior and mid level developers ignore because they don't they don't come up in their uh daily work uh which is why no matter how you know high they focus on writing the perfect code they don't do very well in technal interviews and here is one quick way to get your front end interviewing skills to the next level

spend as much time testing and optimizing your frontend application as you spend building it okay do get familiar with the bugging tools do get familiar with the performance tab okay which gets me to another main point of this video One topic you start you know one topic that you have to start accounting for when if you want to really get good at doing front end interviews it's frontend we won't have time to dive into this in this moment but if you want B night to make another video talking about it just let us know in

the comments now we're going to move on with question number four bton how would you manage code quality in a large scale front-end application what what tools and practices would you use um for code quality I would probably start with a lar and so you want to basically catch small issues make sure everybody guys the same codes you're going to have prtr Mays link setup if you're using typescript have the TS link setup it just takes off a lot of the work and communication because everybody guides code in the same style after that you do

want to have a layer of unit test and ideally some e2e test for sure and then finally I would have something like a dependency scan ideally you also have in your linter something to scan for AI 11e which stands for accessibility so we taking care of code quality and style we have accessibility covered we have testing we have a dependency scan to tell us how our dependencies node modules especially can be very vulnerable to to different attacks and finally Maybe you want to also add something like Lighthouse or Sentry to your pipeline and they will

tell you how your core web vitals change basically how your web performance changes over time so if by any chance we make any mistake with a big image like we mentioned before or we add fonts we immediately see the effect of that on our web performance and we can fix it early on so cool buan now we're going to move on with question number five what is an xss attack and how can you make sure that your frontend application it's not vulnerable to such an attack an xxs attack so I guess that stands for coite

scripting um so let me dra out really quick so basically as I recall in xss the attacker it's somehow persisting some sort of JavaScript code into our database and then our users are because they fetch things from our database they uh they can run that a good example example would be Facebook I think it happened to them back in 2006 or something someone was writing comments on famous posts as JavaScript and whenever you load that post um You' render that comment you'd actually run that JavaScript on your machine so um what does this mean it

means basically I could actually have send over the network in that JavaScript have a a Fetch with a post and send your password and credentials over the network to myself for example um so yeah that's that's basic basically the attack itself if you want to prevent this in the front end number one thing you want to sanitize input so sanitize input that means the attacker ideally cannot persist JavaScript code into our database as comments or text input so we able to somehow detect that and remove that and we don't want to add JavaScript to our

database um but even if they manage to do that somehow we could actually make sure we never um never render HTML or sljs from the user um from the user or that we receive over the network it's a bad practice and so one of the things if you ever use react you probably know of the dangerously I think it's called dangerously set HTML and you want to avoid this at all cost because this means you're giving code that you're not aware what it does um to the browser to render on your on your user browser

so I would avoid this as much as you can um basically two things sanitize the input and avoid just directly rendering JS or HTML that you receive from the back end into the front end now question number six can you explain explain uh quickly quickly how a CDN works you know what are some disadvantages advantages of having a having a CDN um sure I love CDN by the way one of the best tools in the front end and basically what it does is just creating it's a Content delivery Network so there's a network of servers

that will replicate our website and whenever somebody's accessing it from um from a geographical location rather than getting the assets from our server like the HTML JavaScript and CSS they would get them from an edge location of the CDN so imagine this is our website and I create a CDN distribution let's put it in yellow and I spread it over the globe if I have a user over here let's say it's over here that's my user so the user gets the asset from US versus the user getting it from the closer location to them the

way this is done is with a DNS table that routes the user based on latency so they would get the asset from the location that's closer to them basically and uh yeah they're amazing they're really easy to set up and I would say it's a must have for pretty much any client application any frontend application uh now that we are here what's the most common provider you use when you want to set up adns for your for your react apps for example um I would probably use AWS cloudfront uh if you're on AWS I use

this one a lot in the past but you can also use cloudfare they are very established very well Cloud Fair totally recommended so I use both of them I used Azure CDN too um they they can all do the job uh but those two I found very easy to set up cool cool awesome now uh we're going to move on with the final question in this video very important question especially in frontend architecture you know go into the level of detail you want but the question is what are micro front ends and when would you

use this kind of front end architecture so typically we'd have a front end like this one right here imagine we have different components I have a header let me change the color and then maybe I have like the body of the page that shows maybe a product and imagine here we have some sort of checkout information um let's put that again so this is our web page and this is works pretty fine when we are we have a smaller team but as we add more and more people to the team it will be harder to

contribute on the single frontend monolit so as you get past maybe 30 frontend Engineers we have a huge amount of people in the frontend it makes sense to split those individual PES into independent applications so this one has the UND domain this one has the UND domain and this is another application and there it's a shell which is the main one here the green that puts them all together it's responsible for authentification shared State and now because you have this you can actually deploy for example this one independently and have a team working only on

this one then you have this one and you can deploy it independently so it allows you to really separate development teams and you can make basically development faster but you do pay a lot of of pay you pay a price of complexity in the front end because they add a lot of complexity to your uh to your setup and you need very complex tooling to make something like this happen when when does it make sense you know what's what's kind of the the criteria when you you if if people come to you as a senior

software engineer and they tell you hey we have a big mon monolitic front application we are thinking about breaking this into micro front ends what would be the criteria for you to consider such a such a um move um so micro front ends are mostly good when you want to split your organization so you need to split people into teams and they want to work separately because we're Distributing our system you always pay the price when we distribute systems so all of the sudden you'll have things that are very hard to do like um sharing

State U and so I wouldn't pay that price until you have a very good reason to and the only good reason to is that you have so many people working on the front end and you start having issues with the deployment pipeline for example it takes very long to deploy the app several teams they they block each other so imagine one team deployed now they need to roll back this is the only frontend monol we have the other teams are waiting and they cannot push features so it's more of okay we need to make the

organization faster and we need this technology to enable us to work separately and to work in parallel uh but you do need a certain scale so I would say most companies probably U have done this too early and they realize okay this is actually a lot of complexity we have all this complex tooling now we spending so much time in meetings assessing all this so you need if you're in retail and you have a big team of developers I definitely consider it but if you are building um yeah smaller websites or smaller applications I wouldn't

uh even bother about it awesome B yeah microphone are quite complex to handle and imine and manage but um I would say also a must topic for any frontend engineer that wants to get to senior three things I want you to do first if you have any technical interview questions that you want Bon and I to answer in one of those videos just drop it down in the comments second if you are interviewing right now and you want to find out what your Le tle level is you know what are some tle gaps you should

fix before you go to your next interview then check out the free tle assessment we've put together for you and third it is proven that developers who have a mentor are almost five times more likely to get promoted and earn more if you want B I to personally Mentor you so you can become more confident and competent and get to that senior JavaScript developer position then you can book a chat with me and see if we could be a fit thank you bden and we will see you in the next one