I think a lot about the state of interviewing in software and web development. Here are a few ideas I have for good, meaningful interview questions for experienced frontend developers. Note that these don’t reflect the views of my current or former employers, just some thoughts I have had over time.

First, What’s Our Motivation?

Too often it seems interview questions are either

1. “gotchas” about idiosyncratic behavior/quirks or
2. whiteboard challenges to see how a candidate thinks through a problem.

I am pretty strongly opposed to both of these types of questions because I don’t think they actually tell us what we want to know.

In the former case (the “gotchas”), it seems silly to expect candidates to have encyclopedic knowledge of browser, javascript, or frameworks. In the latter case (whiteboarding), putting someone in a high pressure situation with a bunch of people judging them is a really poor proxy for they would perform in a real-life job situation.

We should instead strive to ask questions that give us the best possible picture of how our potential new teammate will perform.

Some Questions

I like the idea of asking questions that reveal a person’s understanding of web application fundamentals. From a frontend perspective, I think some really great question categories are:

• Client/server interaction
• Security
• Accessibility
• Performance
• Frameworks (generally)
• Modern development practices

Let’s work out some examples of good questions in each of these categories:

Client/Server Interaction

What is the difference between client code and server code?

Here we’re looking for some base level understanding that client code is sent to the user to be executed in their environment (e.g., a web browser) whereas server code is executed in our environment (e.g., AWS EC2 instance, a computer in our utility closet, etc). Client code often consists of HTML, CSS, and JavaScript whereas server code can be any number of server-side languages.

What does it mean for a backend to be stateless and what does this mean for the frontend?

We are looking for the prospective teammate to identify that an HTTP request to the backend has to stand on its own. For example, if our first HTTP request is a successful login, we can’t expect our backend to remember in the future that we have logged in successfully. Instead, we need to pass a cookie or token with each request that the backend can use to identify us.

What does the expression “never trust the client” mean?

Users have full control over the frontend code we send them, so it’s important that and inputs from the client are sanitized on the backend. This question hopefully helps ascertain that the prospective teammate understands that client code truly belongs to the user.

Security

What are some frontend security concerns and how might we mitigate them?

This is pretty open-ended, but we would expect the prospective teammate to at least discuss Cross-site scripting (XSS) and cross-site forgery request (CSRF) attacks.

XSS attacks are when a user submits malicious code to your application (probably stored in a backend database) and, when displayed on the frontend, executes in an unsuspecting user’s client. We can protect against XSS attacks my properly escaping any user-provided input in our application.

CSRF attacks are when malicious websites trick users into executing POST requests to your backend. This is possible because browsers automatically attach cookies to any request backend. Therefore, if a user is already logged in to your application using a cookie, another website can have the user submit data to it. We can protect against CSRF attacks by using a CSRF token, which is a token that would only be available to your frontend and is submitted with POST requests as a non-cookie (e.g., another header). The applicant may also be familiar with same-site cookies, which will eventually result in browsers only attaching these cookies from clients at the same site. Importantly, we can’t count of same-site cookies until we can reasonably expect our users to all have browser versions that support the feature.

What is CORS and how is it enforced?

Cross-origin resource sharing (CORS) is a mechanism for backends to specify what origins can have access to its resources. While CORS is specified by the backend, it is up to the client (e.g., web browser) to enforce the CORS instructions.

What is a HTTPOnly cookie and why are they important? Should you always use them?

An HTTPOnly cookie is a cookie that’s only accessible to the browser but is not accessible to javascript run in the browser. They are important because you can enable the client and server to pass cookies back and forth without exposing them to potentially-malicious frontend code (e.g., an XSS attack).

You do not always have to use HTTPOnly cookies. You may intentionally have cookies you want to be exposed to your frontend’s code. For example, you can elect to use a cookie-to-header CSRF token flow, which relies on your frontend’s javascript pulling a CSRF token from a cookie and resubmitting it to the backend as its own header.

Accessibility

What kind of frontend components and interactions are tricky from an accessibility standpoint and why?

This is subjective and it would be interesting to hear what folks have to say on this one. For me, it’s modals and datepickers. Modals require trapping focus within the modal and hiding background content from screen readers. Datepickers are tough if you consider how a keyboard user would navigate a calendar and how that information would be conveyed to them.

How would you decide between an anchor tag and a button for any specific action?

Anchor tags are for navigation, buttons are for actions. It is important not to surprise users or their assistive technology by using elements for unintended purposes.

What are some tools you have used to assess your application’s accessibilty?

We are looking for tools like Google Lighthouse audits and tools like ANDI that help you identify how elements are interpreted by assistive technology.

Performance

What are potential performance issues you might see in an application and how would you mitigate them?

Looking for a discussion of things like:

• long network requests, which can be mitigated by caching strategies
• large asset sizes, which can be mitigated by compression and code splitting
• blocking requests, which can be mitigated by deferring resource loading until after the HTML is rendered
• for frameworks, lots of component re-rendering, which can be mitigated by memoizing or changing re-render dependencies

How would you go about troubleshooting performance issues?

There are probably a lot of answers here, but my first instinct would be to check the network tab in browser devtools and see if I have any abnormally long requests or large assets being loaded. If I can mitigate any of that based on an aforementioned mitigation strategy, I would potentially apply that. If I’m using a framework like React, I might use React devtools and component profilers.

Frameworks (generally)

Why do we have frontend frameworks? What are the problems they try to solve?

There are a lot of good answers to this question. A lot of experienced developers who have spent enough time interacting with the DOM will certainly talk about how frameworks generally abstact away the DOM API and help keep data and UI in sync. Other good answers can include discussions of maintaining modular codebases, ensuring browser compatibility, reducing HTTP request size, and increasing responsiveness/reactivity for the user.

What are the cons of frontend frameworks like React, Angular, or Vue?

Frontend frameworks have become ubiquitous, but they’re not always the right answer. They can result in shipping large code bundles to the client, which can be difficult to download in low bandwidth areas. Furthermore, they can increase development complexity needlessly for simple problems. Finally, frameworks can be intimidation for junior developers and newcomers to the profession compared to some HTML, CSS, and JavaScript files.