The performance questions I ask in a frontend interview

Performance comes up in most frontend interviews I run, usually about twenty minutes in, when we have built something small and it works. That is when I ask "so what happens when this gets slow?" The answer tells me whether you have ever had to make a real page faster, or whether you have only read the checklist.

I am Harry Ashton. I built CodePrepped so engineers stop guessing what hiring managers look for. This post sits next to the accessibility questions I ask and the trade-offs I want you to say out loud. Performance is mostly trade-offs, so it is a good place to show how you think.

Photo: Kevin Ku / Pexels.

Why I ask about performance at all

I am not hiring a performance specialist for most roles. I am hiring someone who will notice when a page feels sluggish, find out why before guessing, and fix the thing that matters instead of the thing that is fun to optimise. Those habits show up in how you answer the first question, long before we get anywhere near bundle analysers.

"This page feels slow. What do you do first?"

This is my opener, and the strongest answers start with a question back to me: slow how? Slow to show anything, slow to respond to a click, or jumping around while it loads? Those are three different problems with three different fixes.

Then I want to hear that you would measure before you change anything. Open the browser's performance tools, record a load and an interaction, and look at what is actually taking the time. If you have used field data from real users as well as a lab run on your own fast laptop, say so. The gap between the two is often where the real problem is hiding.

The answer that worries me is a list of fixes before any diagnosis: "I would add lazy loading, memoise everything, and switch to a smaller library." Some of that might help. None of it is chosen for a reason yet.

"Talk me through Core Web Vitals"

I do not need definitions recited. I want to know you can connect each metric to something a user feels and something you would change.

• Largest Contentful Paint is about when the main content shows up. I want to hear about the hero image or heading, how it is discovered, whether it is lazy loaded by mistake, and whether the server is slow to respond in the first place.
• Interaction to Next Paint is about how quickly the page responds when someone clicks or types. It replaced First Input Delay, and if you know that, I know you have kept up. Good answers mention long tasks on the main thread, heavy event handlers, and breaking work up so the browser can paint.
• Cumulative Layout Shift is about things jumping around. Images and embeds without reserved space, late-loading fonts, and banners injected above content are the usual suspects.

If you can tell me about one time you moved one of these on a real page, and what you changed, that is worth more than knowing all three thresholds by heart.

"When would you reach for memoisation?"

In React interviews this question comes up a lot, and the best answers start with "less often than people think". Wrapping everything in useMemo and useCallback adds code and its own cost, and it rarely fixes the slow thing.

I want to hear that you would profile first, find the component that re-renders too often or does too much work when it does, and then pick the cheapest fix. Sometimes that is memoisation. Often it is moving state closer to where it is used, splitting a big component, or not doing expensive work during render at all. If you mention that newer React tooling can handle some of this automatically, and where you would still check by hand, good.

"This list has ten thousand rows. What changes?"

I like this one because there is no single right answer. I am listening for questions: does the user need all ten thousand at once, can we paginate, does the server need to send them all, is it a table people scan or a feed people scroll?

Virtualising the list is a fine answer if you can explain the cost. Search inside the page stops finding rows that are not rendered, keyboard and screen reader users need care, and scroll position gets harder to restore. A candidate who raises those without being asked has clearly shipped one.

"How do you keep the bundle from growing?"

Most teams do not set out to ship a huge bundle. It grows one dependency at a time. I want to hear how you would notice: a size check in CI, looking at what a new package actually pulls in before adding it, and splitting code by route so people only download what the page they are on needs.

I also like hearing about the boring wins. Serving images at the size they are displayed, in a modern format. Loading third-party scripts late or not at all. Not shipping a date library for one formatted date. These are rarely clever, and they often matter more than anything clever.

"What would you not optimise?"

This is the question that separates people who have done the work from people who have read about it. Every optimisation costs something: more code, more to test, harder to change later. I want you to tell me about something you deliberately left alone because it was fast enough for the people using it, or because the fix would have made the code worse for the next person.

"An admin page used by five people internally does not need the same care as the checkout" is the kind of judgement I am hiring for.

Answers that make me write a careful note

• Quoting a score from one lab run as if it were the whole story.
• "We optimised it" with no before, no after, and no idea what changed.
• Reaching for a framework rewrite to fix a slow image.
• Treating performance as a final sprint instead of something you notice as you build.

None of these are automatic fails. They are prompts for a follow-up, and a candidate who says "looking back, I should have measured that first" can still have a strong interview.

How to prepare without memorising a checklist

Take a page you built, ideally one with real images and a few dependencies. Record a load in your browser's performance tools and find the slowest thing. Fix one problem, record again, and write down what changed. Then do the same for an interaction, like opening a menu or filtering a list. You now have a real story with a before and an after, which is exactly what I am listening for.

Then practise telling it out loud. CodePrepped's mock interviews and AI Trainer give you somewhere to rehearse follow-ups like "how did you know that was the bottleneck?" before you are asked it by someone like me. If you are applying now, the shortlist scorecard is a quick way to see what to work on before your next screen.

Do I need to know the exact Core Web Vitals thresholds?

No. Knowing roughly what good looks like and where to check is enough. I care more that you can find why a page is slow than that you can quote a number.

What if my last job never measured performance?

Say so, then show me something you measured on your own. A small side project with a before and after reads far better than pretending your old team had a dashboard.

Will I be asked to optimise code live?

Sometimes. If I do, I care about you talking through how you would find the slow part and what you would try first, more than finishing every fix in the time we have.

Is performance only a senior topic?

No. I ask juniors too, with simpler follow-ups. Knowing to check before you guess is useful at every level.