Top Senior Front End Engineer Interview Questions and Answers (React Focused)

The tech world is starting to have a new appreciation for solid senior front-end engineers. There are more jobs available for people who specialize on the front end with higher salaries than before. So what is expected of a senior front-end engineer? This is a subjective question but in my opinion, a senior front-end engineer should know how everything works under the hood, why you would make certain architectural decisions over others, and be able to get in the weeds of the code and contribute heavily without much help.

So you might be asking what kinds of questions get asked in a senior engineer interview. This is again subjective and depends on who is interviewing you and what company you are applying to. But here are some of the questions I like to ask or have been asked and things I look for in an answer. Keep in mind these are not coding challenges I will have another post on what you may come across for those.

What is your philosophy on reusable components vs simplicity and premature optimization? 

Note: this question’s answer is more subjective than most of the other questions. These are the things I and all my teams in the past have looked for.

We always want to make components small and reusable but we don’t want to get carried away. Simplicity and readability are key. Don’t overcomplicate if you don’t have to. Generally make it reusable when you need to but keep reusability in mind when creating it.

There are components you know even in the beginning stages of your application will be reused. For instance, navigation, maybe a dropdown, or a table component, or pagination. If the component is super specialized then it likely won’t be reused but try to make it as reusable as possible. Think about ways it can be reused if possible but if it adding too much extra complexity just build it for what needs to be done at the time. Sometimes making something reusable makes it too complex, bug prone, and hard to support. If that is the case look into ways to make it simpler or make a new component to support some edge cases.

How would you explain a useEffect to a junior engineer?

Here we get to know the understanding of if they know what a useEffect is, how it works, and if they can explain a difficult concept to a junior.

A useEffect hook is a function that executes based off the dependency array that it is given. So if you have something you want to happen when something in your state changes you would put it in a useEffect. If anything in that array changes the function will run. If you only want it to run once you pass it an empty array, and if you want to do something when the component is unmounts you add a return statement to the useEffect and it will run when the component unmounts.

What are major pitfalls or common issues people face with hooks?

Unwanted rerenders. People make hooks with too many dependencies with a lot of complex logic and it makes the component rerender too many times and sometimes creates infinite loops. You need to be intentional about what is in your hooks and the dependency array for them. You want as few dependencies as possible. Some linters will complain if you don’t have each thing you use in your hook in your dependency array which I think is fair but you also have to be willing to ignore the linter sometimes and know exactly what you want to trigger that function and only have that in the dependency array. Arguably though this shouldn’t be necessary if your hooks are written correctly as they shouldn’t have to depend on many things and the component should need to rerender when the things in the hook change otherwise why are they in the hook? (you could just put them in a constant instead) but there are SOME cases where this is unavoidable (this is a common hotly debated topic).

If you are getting too many API calls being made from your hooks what can you do to prevent this?

Use a caching system or package to help. You can set something in state that checks if the call is different from the last call if it is then make the call otherwise don’t and then if you want new data each time the page is hit clean that up in the return of your useEffect otherwise leave it in global state so you don’t have to make the call again if you have the data. You can also use a package like React Query (there are also other packages you can use) to help you take care of the caching for you.

Explain the javascript event loop (also may get explain how promises or async await work in js these are basically all the same question/answer)

JS has a call stack that everything synchronously goes into. When you hit a function that there is a Web/Browser/Node APIs for (document, http request, or timeout), JS will pass that to the Web/Browser/Node APIs to handle. When they are done being evaluated they get pushed back to the callback queue. The callback queue is a queue of all the callback functions that are ready to be executed. If the call stack is empty js will look at the callback queue to execute those callback functions.

If there is a promise (async await is just a promise under the hood) they will be pushed into a microtasks queue. This queue works a lot like the callback queue but is given priority over the callback queue. This means if you had an async call and a setTimeout the async callback will get executed before the setTimeout.

Why should we not directly update state (using DOM manipulation)?

When you manipulate the DOM directly react loses its connection to that update. If we use React to set state it schedules an update to the components state object when that changes the component will rerender. React becomes unaware of the update and will no longer update properly based on the state of that component. Or if you are adding an element that React was never aware of you won’t be able to rerender that element based off the state of your application.

What are a couple of easy to avoid front-end security pitfalls?

I could write a whole article about this so if you want more information let me know I’m happy to do a more in depth article on this.

Cross-site scripting - react actually has some of this built-in it will escape XSS (so does Ruby on Rails). Using CSPs (content security policies), sanitizing your incoming data and data you are sending to the backend.

Injection - this is again sanitizing your incoming data and the data you are sending to the backend to make sure there are no queries that can be sent. This can also go along with the front end not being able to send a query to the backend. The backend shouldn’t expect a query the front end should send the necessary data the backend needs to create the query.

Broken Auth - this can be the ability to bypass auth by using the URL to hit certain pages rather than going through the expected route, having misconfigured CORS, allowing the user to easily update a value from the front end to access something they don’t have access to. There are many things that can go wrong here but a couple ways to fix it are, rate limiting your APIs (this is mainly to protect against automated attacks or brute forcing), making sure you have all protected routes (maybe a middleware that makes someone be authentic for every page or making sure all routes have auth around them that should), make sure you have proper auth (don’t allow your JWTs to live too long, don’t allow a user to just have access because they have a certain Id ensure there are other checks for auth as well). There is a lot more that goes into this.

There are many more if you want to know more check out the OWASP top 10.

What is Virtual DOM and how does it work?

The virtual DOM is a JavaScript version of the actual DOM that is saved in memory and syncs with the actual DOM to make things react on the page. Through libraries you are able to make JavaScript manipulate the actual DOM based off the state you want and define in JavaScript. The libraries do this by using an algorithm that looks at the difference between the state you want and the state of the actual DOM in a tree structure (will start from the root and move in). It will update anything that is different and the children below it if necessary.

You could go in to how it looks at class names and styling but it depends on what they want. Here is React’s article on how their reconciliation process works. Vue’s works similarly but here is the article on how theirs works.

What is the difference between Shadow DOM and Virtual DOM?

The shadow DOM is a small representation of the DOM (sub tree of the DOM) while the virtual DOM is a representation of the whole DOM. The shadow DOM is a scoped tree and only effects the element that it is connected to and not the children. This makes styling scoped as well which is what a lot of people use the shadow DOM for. It also makes rerenders more performant as it doesn’t rerender or worry about the whole DOM (parents and children of the element you actually care about) just the element that it is scoped to.

The main difference being that the shadow DOM is scoped for a particular element while the virtual DOM is for the whole DOM.

Let me know if there are any other questions you like to ask in your interviews or a question you’ve been asked that you thought was a great question. There are so many possible questions you could be asked but I hope this helps you get started on your interviewing journey!