Video guide
20:41 · 1 May 2024
30 Frontend Interview Questions for Mid and Senior Developers
Chapters 7 sections
Interview questions in this video:
- 02
2. You are setting up a new frontend application. What performance optimizations do you put in place?
At the bundler level: polyfill modern JavaScript for your target browsers, then apply minification and uglification to shrink the code — and emit source maps, or you cannot debug production. Ship the bundle with gzip compression; that alone cuts the network payload by roughly 70%.
Add code splitting so the initial load only ships the JavaScript it needs — with a router, each route becomes its own chunk — and use ES6 modules so the bundler can tree shake dead code. Past the bundle: a CDN, caching, and image and font optimization. Modern bundlers like Vite do most of this out of the box.
Webpackcode splittingtree shakinggzip - 03
3. How would you optimize an application with very large images, like an e-commerce store?
Never ship a 3,000-pixel image into an 800-pixel element — resize to the minimum dimensions that still look sharp. Compress, strip metadata, reduce the color space if you can, and prefer WebP over PNG. Serve everything from a CDN, lazy load images below the fold, and set explicit width and height so late images do not cause layout shift. Use srcset to ship smaller variants per device — modern CDNs generate the thumbnails and the snippet for you.
WebPsrcsetlazy loadingCDN - 04
4. What is critical CSS and how do you extract it?
Critical CSS is the CSS needed to position and style the elements above the fold — what the user sees without scrolling. CSS is a global namespace, so browsers parse and apply all of it before moving on with the HTML; it is render-blocking and all-or-nothing, and a big stylesheet slows the whole first paint. Extract the critical part with a bundler plugin — for example a Webpack plugin that renders the page in Puppeteer at a given width and uses the browser's CSS coverage tool — then inline it and defer the rest.
critical CSSrender-blockingPuppeteer - 05
5. What do the defer and async attributes do on a script tag, and why use them?
Both download the script in the background instead of blocking HTML parsing. defer executes the script just before DOMContentLoaded, once the HTML is parsed; async executes as soon as the download finishes, whenever that happens. ES6 module scripts are deferred by default in most browsers. The point of both: keep non-critical JavaScript off the critical rendering path so the initial load is faster.
deferasynccritical rendering path - 06
6. What is the difference between a normal ES6 import and a dynamic import?
A static ES6 import is resolved at build time, so the bundler gets static analysis: tree shaking, TypeScript type inference — things require and CommonJS cannot give you, because require only runs at runtime. A dynamic import behaves like a function, so you can call it inside an if statement or a click handler. That is what enables lazy loading: only fetch lodash — or a whole component — when the user actually triggers the action that needs it.
ES6 modulesdynamic importtree shaking - 07
7. What is the CLS metric and how do you fix a bad score?
Cumulative Layout Shift is a Core Web Vital measuring how much the layout jumps while the page loads — an image arrives late, pushes everything down, and the user clicks the wrong thing. First find the shifting element with a debugging tool; Chrome's performance insights pinpoint the exact div. Then fix the cause: explicit width and height attributes on images, optimized font loading with a declared fallback height, or critical CSS when styles arrive late.
CLSCore Web Vitalslayout shift - 08
8. How does a CDN work, and why would you use one?
A CDN is a network of servers that replicates your static assets — HTML, JavaScript, CSS — across edge locations around the world. A latency-based DNS lookup routes each user to the closest edge, so nobody waits on a round trip to your origin server. It is easy to set up and a must-have for almost any frontend; CloudFront and Cloudflare both do the job.
CDNCloudFrontedge locations - 09
9. How would you deploy a frontend application?
Client-side only means a static deployment: upload the build to blob storage like S3 and put CloudFront — or any CDN — in front, so users hit the nearest edge location. That setup scales through traffic spikes without you doing anything.
SSR changes the picture: you need compute. Containers on Fargate, EC2 instances behind a load balancer, or a platform like Vercel that distributes the compute for you. Static assets still go through the CDN either way. Be careful with Lambda for e-commerce SSR — cold start times hurt.
S3CloudFrontSSRdeployment - 10
10. What tools and metrics would you use to monitor a frontend application?
Three layers. Error tracking with Sentry: stack traces, device and OS context, and alerting so whoever is on call can reproduce the exception. Core Web Vitals from real users — first contentful paint, Speed Index, CLS — to know the loading speed people actually experience, plus server metrics (CPU, memory, response times) if you render server-side. Finally product analytics like Google Analytics — not the best tool, but the industry standard and easy to implement.
SentryCore Web Vitalsmonitoring - 11
11. How do you manage code quality in a large-scale frontend application?
Start with a linter plus Prettier so everyone writes in the same style and small issues die in the editor — add TypeScript linting and an a11y rule set for accessibility. Layer on unit tests, some E2E tests, and a dependency scan, because node_modules is a real attack surface. Then wire Lighthouse or Sentry into the pipeline so a fat image or new font shows up as a Core Web Vitals regression before it ships.
ESLintPrettierE2E testingLighthouse - 12
12. What is an XSS attack and how do you prevent it?
In cross-site scripting, an attacker persists JavaScript into your database — as a comment, say — and every user who loads that content executes it; the script can silently POST their credentials to the attacker. Defense one: sanitize input so script never reaches the database. Defense two: never render raw HTML or JS received over the network — in React, that means avoiding dangerouslySetInnerHTML at all cost.
XSSinput sanitizationsecurity - 13
13. What are JSON Web Tokens and how are they used for authentication?
A JWT is the credential a client attaches to requests — usually in the Authorization header — to prove who it is. The flow: the client redirects the user to an identity server, the user authenticates with credentials or multi-factor auth, the client gets a token back, and the backend verifies that token against the identity server before returning protected resources. The frontend JavaScript itself should ideally never touch the token.
JWTauthenticationidentity server - 14
14. Where should you store a JWT in the browser?
In an HTTP-only cookie. sessionStorage clears when the browser closes, forcing constant re-authentication. localStorage is readable by JavaScript, so any injected script — an XSS payload, a malicious Chrome extension — can steal the token and act on behalf of the user. HTTP-only cookies are invisible to frontend code but ride along automatically on every request, so the backend can still identify the user.
JWTHTTP-only cookieXSS - 15
15. What are ARIA attributes and when are they useful?
Default to semantic HTML — header, footer, nav — because accessibility tools understand those tags natively. ARIA attributes exist for the edge cases where design constraints or a custom widget force you onto a div or span: they assign an accessibility role to a non-semantic element. Use them when you cannot use semantic tags, not instead of them.
ARIAsemantic HTMLaccessibility - 16
16. What is the shadow DOM and when would you use it?
The shadow DOM is an isolated subtree of the DOM: styles inside cannot leak out, global styles cannot leak in, and it does not inherit native browser styles — so a dropdown looks identical in Chrome and Safari. That isolation is worth it when you ship a component library or open-source widget that must not conflict with the host application.
For a normal product app it is over-engineering: more complexity, worse performance, no polyfill for older browsers. For CSS conflicts — including across micro frontends — CSS Modules or CSS-in-JS solve the problem far more cheaply by hashing class names per file path.
shadow DOMCSS Modulesencapsulation - 17
17. Walk me through one tick of the event loop. What runs first: synchronous code, promises, or setTimeout?
Run the call stack dry first — all synchronous code. Then drain the microtask queue: resolved promise callbacks execute here, before anything else. Then the browser repaints so the user sees the updates, and only on the next tick does it pick a macrotask like a setTimeout callback. That is why a setTimeout with delay 0 still logs after 'script end' and after every promise callback.
event loopmicrotask queuesetTimeout - 18
18. What is one advantage and one disadvantage of closures in JavaScript?
Advantage: simpler function signatures — a closure reads variables from its enclosing scope, so you do not have to pass everything in as parameters. Disadvantage: memory. Enclosed variables cannot be garbage collected while the function lives, and JavaScript is traditionally a poor language for memory handling anyway.
closuresscopegarbage collection - 19
19. A user presses the submit button too often, triggering too many backend calls. How do you fix it?
Throttle the handler so it fires at most once per interval — the right call for a submit button. For a text input firing on every keystroke, debounce instead: wait until the user stops typing before hitting the backend.
throttledebounce - 20
20. What is the difference between essential state and derived state?
Essential state changes independently — it comes from user interaction or data fetching, and nothing else can reproduce it. Derived state is anything you can compute from other state. On a checkout page: the items in the cart are essential; the item count, net price and price with tax are all derived. Compute derived values — do not store them.
state managementderived state - 21
21. What are the two rules of hooks in React?
One: call hooks at the top of the component, never inside conditions or loops. Two: only call a hook from a React function component or from another hook.
Reacthooks - 22
22. What can class components do that functional components cannot?
The keyword is lifecycle methods. Class components can hook into shouldComponentUpdate to control whether a component re-renders, and they are the only way to implement error boundaries — both need lifecycle access that function components do not expose.
Reactclass componentserror boundaries - 23
23. Why can't you pass an async function directly to useEffect?
useEffect treats the function's return value as the cleanup that runs on unmount — where you remove the scroll listener you attached, or every re-render stacks another listener. An async function returns a promise, and the useEffect API does not understand a promise as a cleanup function.
ReactuseEffectcleanup - 24
24. What is concurrent React, and what is a fiber?
Concurrent React — stable since React 18 — gives React an internal priority queue: it can pause a low-priority render, like painting freshly fetched data, to handle a high-priority update like the user typing or scrolling, so the interface stays responsive. A fiber is the unit of work that makes this possible: a node holding a component's code, props and current state. React walks the fiber tree on each render and can pause mid-tree, handle the urgent work, and resume exactly where it left off.
concurrent ReactfiberReact 18 - 25
25. How do you optimize the re-rendering process in React?
First avoid the render entirely: memoize the component so a re-render is skipped when the incoming props are unchanged. When a render must happen, useMemo and useCallback keep expensive values and functions from being recomputed unless their dependencies change. Slow renders show up in your metrics as bad INP — interaction to next paint, the Core Web Vital most affected by expensive re-rendering.
ReactuseMemouseCallbackINP - 27
27. What are the disadvantages of global state and of React context?
Abused global state triggers re-renders across every subscribed component. It also couples your code: components carry a hidden dependency, so they are harder to move and harder to test — every test now has to mock the store. React context has the same failure mode: suddenly everything is connected to it and needs providers mocked, so use it as much as necessary and as little as possible.
global stateReact contextcoupling - 28
28. In server-side rendering, what is hydration?
The server sends fully rendered HTML, so the user sees the page — but nothing is interactive until the framework attaches the virtual DOM and event handlers to that markup. That attach step is hydration; in React it starts with hydrateRoot. Until it finishes, clicks do nothing — that is the click-rage window. Avoid mismatch warnings by rendering identical HTML on both sides: no timestamps or generated values in server markup — produce those client-side, in a useEffect.
SSRhydrationvirtual DOM - 29
29. Name three advantages and three disadvantages of server-side rendering.
Advantages: much better SEO, because search bots get pre-rendered HTML; better web performance — the FCP improves since users see content immediately. Disadvantages: setup complexity, coupling between frontend and backend, and framework lock-in — SSR today mostly means committing to something like Next.js, which ships breaking changes fast. Deployment also gets heavier: you need compute, not just static hosting.
SSRSEONext.js - 30
30. What are micro frontends and when do they make sense?
Micro frontends split one frontend monolith into independently deployed applications — header, product page, checkout — composed by a shell that owns authentication and shared state. They solve an organizational problem, not a technical one: past roughly 30 frontend engineers, teams block each other in one deploy pipeline, and splitting lets them ship in parallel.
The price is real: visual consistency across apps, state shared through the shell, and heavy tooling complexity — you are distributing a system. Most companies adopt them too early. Do not, until the deployment pipeline is actually the bottleneck.
micro frontendsarchitecturedeployment
Transcript
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 front-end developers make in technical interviews. The most important thing to focus on if you want to stand out in a front-end interview, and if you stay until the end, we will reveal a sneaky trick to take your front-end interviews to the next level.
Let's go. Question number one, what is the difference 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 KB. 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're great for authentication, 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 a 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, uh, it's great for storing application state, um, if you want to persist 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 light 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 know, one of these, um, check code 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 user is 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 modern front end application? Could you give me more detail? Yeah, let's suppose a uh React application, client side, rendered, um, you know, let's use Webpack as a standard uh as a module 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, you know. 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 supports 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 browser doesn't support. Um so we polyfill 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 Gzip file and then with content negotiation indicate to the browser, hey, this is a Gzip 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 traditionally in JavaScript, this is kind of uglifying uh the code and minification. So these two uh they are both kind of code optimization and they take code we written and uh kind of remove new line characters and they replace variables like we usually have these long variable names, they replace them with very small one letter variables.
It's basically transforming it in code you cannot read, but it's slightly 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 execute it. 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'd 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 minfy 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 webpack or if you're using something like a modern uh more modern bundler like uh Vite. They will come out of the box. So they will 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 frequently needed for the initial load.
So that would be my third optimization when it comes to um to JavaScript. Now, this is at module bundle 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 road 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 Webpack 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 tree shaking in our code. Amazing, bum. 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 e-commerce store, let's imagine that, very high definition pictures.
Like, how would you optimize this for maximum 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, like 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? Well, 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 read 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 in 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 is 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 load in 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 layer of shift, you would need to specify with and height. Um and of course, you can use the source set attribute, source set. To ship different images depending on uh the view port, 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 CDNs offer that out of the box, like modern CDNs 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. Wow, that 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 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 is because most technical interviews don't actually test you on your core frontend skill.
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 technical 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 front end application as you spend building it. Okay? Do get familiar with debugging 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 counting for when if you want to really get good at doing front end interviews, it's front end. We won't have time to dive into this in this moment.
But if you want bug the 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. Bug, 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 linter and so you want to basically catch small issues, make sure everybodyy has the same codes, you're going to have prettier, maybe a linter set up.
If you're using TypeScript, have the TS linter set up, it just takes off a lot of the work and communication because everybodyy writes 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 dependencies scan. Ideally, you also have in your linter something to to scan for AI 11E, which stands for accessibility.
So we're taking care of code quality and style, we have accessibility covered, we have testing, we have a dependency scan to tell us how our dependency add something like light house or entry to your pipeline and they will tell you how your core web vitals change, basically how your web performance changes over time. So if 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. But now, we're going to move on with question number five. What is an XSS attack, and how can you make sure that your front and application, it's not vulnerable to such an attack? An XSS attack, so I guess that stands for cross-site scripting. Um, so let me draw it 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 they can run that. A good example would be Facebook, I think it happened to them back in 2006 or something. Someone was writing comments on famous post 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. Mhm. Um So yeah, that's that's 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 inputs, so we're 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 js 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 backend 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? I'm sure. I love CDNs right away. One of the best tools in the front end. And basically what it does, it's 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, it's 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 front end application. What's the most uh now that
what we are here, what's the most common provider you use when you want to set up a DNS for your for your React apps, for example. Um I would probably use AWS CloudFront uh if you are on AWS. I use this one a lot in the past. But you can also use CloudFlare. They are very established, very well CloudFlare, totally recommended. So I use both of them. I used Azure CDN too, um they they can all do the job.
Uh, but this 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 front end 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 would 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 red. 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'll be harder to contribute on the single front end monolith. So, as you get past maybe 30 front end engineers, we have a huge amount of people in the front end.
It makes sense to split those individual parts into independent applications. So this one has their domain, this one has their domain. And this is another application and there's a shell, which is the main one here, the green, that puts them all together. It's responsible for authentication, 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 price, you pay add 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 do you do if if people come to you as a senior software engineer and they, hey, we have a big mononolitical front end application, we are thinking about breaking this into micro front ends, what will 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 a sudden you have things that are very high to do like um sharing state. Uh 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 front end money 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 uh have done this too early and they realize, okay, this is actually a lot of complexity, we have all this complex tooling, now we're 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 would definitely consider it. But if you are building um, yeah, smaller websites or smaller applications, I wouldn't uh even bother about it.
Awesome. Well, yeah, micro front ends are quite complex to handle and imagine and and manage, but um I would say also a must topic for any front end engineer that wants to get to senior. three things I want you to do First, if you have any Tinkle interview questions that you want Bogdan and I to answer in one of those videos, just let me down in the comments. Second, if you are interviewing right now and you want to find out what your Tinkle level is, you know, what are some Tinkle gaps you should fix before you go to your next interview, then check out the free Tinkle 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 Bogdan and 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, Bogdan, and we will see you in the next one.