Here’s a thing I’ve noticed: the hardest part of a frontend interview isn’t knowing the answer. It’s explaining the answer while someone is watching you think. Most frontend engineers know what a closure is. Far fewer can explain it clearly under pressure while also writing a working example on a whiteboard or shared editor.
This post is about the subset of frontend interview questions that consistently show up in React, JavaScript, and CSS interviews, and more importantly, what a genuinely good answer sounds like versus a technically-correct-but-hollow one.
JavaScript questions that look simple but aren’t
A few questions get asked constantly because they have real depth if you push on them.
1. explain closures
The definition everyone knows: a closure is a function that has access to variables in its outer (enclosing) scope, even after the outer function has returned.
What makes the answer good: a concrete example. Here’s one interviewers like:
function makeCounter() {
let count = 0;
return function() {
count++;
return count;
};
}
const counter = makeCounter();
counter(); // 1
counter(); // 2The inner function “closes over” count. The outer function has returned, but count is still alive in memory because the inner function holds a reference to it. Interviewers often follow up with: “What would happen if you called makeCounter() twice?” (Two separate closures, two separate count variables.)
2. the event loop, explained clearly
The interviewer gives you this code and asks for the output order:
console.log('A');
setTimeout(() => console.log('B'), 0);
Promise.resolve().then(() => console.log('C'));
console.log('D');Output: A, D, C, B.
Why: ‘A’ and ‘D’ run synchronously. Promises go into the microtask queue. setTimeout goes into the macrotask (callback) queue. Microtasks run before macrotasks, so ‘C’ runs before ‘B’ even though both were scheduled after the synchronous code.
This trips people up the first time they see it. Once you understand the microtask/macrotask split, it makes sense. I find it helps to think of microtasks as “urgent callbacks” that cut the line.
3. what does this refer to?
Arrow functions vs. regular functions is the crux. In a regular function, this is determined at call time by how the function was invoked. In an arrow function, this is determined at define time by the surrounding scope. This matters a lot in React event handlers and class components.
CSS questions: specificity and layout
CSS interviews are often shorter but more practical. Interviewers care that you don’t break things accidentally and that you can reason about layouts without trial and error.
specificity
Specificity is calculated as a three-part value: (inline styles, IDs, classes/attributes/pseudo-classes, elements/pseudo-elements). A single ID (0,1,0,0) wins over any number of classes. An inline style (1,0,0,0) beats everything except !important.
The practical interviewer question: “You have a button styled with a class. Another developer added an ID to override the color. Now you need to override that ID without touching the HTML. What do you do?” The answer: add an attribute selector or two classes to bump your specificity past one ID, or use a more specific selector chain. The lesson: avoid ID selectors in component CSS so you don’t paint yourself into this corner.
flexbox vs. grid: a real decision
Flexbox: one axis at a time. Use it for navigation bars, button groups, card internals, anything that’s fundamentally a row or a column.
Grid: two axes simultaneously. Use it for page-level layouts, media grids, anything where rows and columns need to align against each other.
The question interviewers ask that’s harder: “Can you build a grid with flexbox?” Yes, but you have to calculate widths manually and handle gap with negative margins (old approach) or gap (modern, now well-supported). The point is grid was invented because flexbox for two-dimensional layouts was getting complicated.
responsive design techniques
Media queries are the baseline. The real conversation is about: mobile-first vs. desktop-first breakpoints, using clamp() for fluid typography, and when to use container queries instead of viewport queries. Container queries are well-supported as of late 2023 and come up more often in 2024 interviews.
React questions: hooks are the main topic
If you have three hours to prepare for a React interview, spend two of them on hooks. The Stack Overflow Developer Survey 2024 shows React still leads among web frameworks by usage share, so hooks knowledge is essentially table stakes.
useState and the re-render model
Every setState call schedules a re-render. The new state value doesn’t appear immediately in the current render. This catches people:
const [count, setCount] = useState(0);
setCount(count + 1);
setCount(count + 1);
// count is still 0 here; both setCount calls scheduled a render with count=1To fix: use the functional updater form: setCount(prev => prev + 1). Each call gets the latest queued state, not the snapshot from the current render.
useEffect dependency arrays
The dependency array controls when the effect re-runs. Empty array: run once after mount. No array: run after every render. Array with values: run when those values change. The stale closure problem: an effect that closes over a value and doesn’t include it in the dependency array will read a stale copy of that value. ESLint’s exhaustive-deps rule catches this, which is why it’s in almost every React project’s config.
custom hooks
A custom hook is just a function starting with “use” that calls other hooks. They’re the right abstraction for logic you’d otherwise duplicate across components. A useDebounce hook, a useFetch hook, a useLocalStorage hook: these are all common interview whiteboard tasks.
The question interviewers ask: “Write a useDebounce hook.” Here’s a straightforward implementation:
function useDebounce(value, delay) {
const [debouncedValue, setDebouncedValue] = useState(value);
useEffect(() => {
const timer = setTimeout(() => {
setDebouncedValue(value);
}, delay);
return () => clearTimeout(timer);
}, [value, delay]);
return debouncedValue;
}Interviewers often ask: “What happens if the component unmounts before the delay fires?” The cleanup function (the return inside useEffect) cancels the timer. That’s why the cleanup is there.
Frontend system design: what it looks like in practice
Larger companies add a system design round to frontend interviews. This isn’t the same as backend system design. It’s about component architecture, state shape, network strategy, and accessibility.
Common prompts: “Design an autocomplete input,” “Design an infinite-scroll feed,” “Design a date picker component.”
The evaluation criteria are roughly: (1) does the candidate break the problem into components before writing code, (2) do they think about the data flow before the UI, (3) do they mention edge cases like empty states, loading states, error states, and keyboard accessibility without being prompted.
I think most candidates underestimate how much interviewers care about accessibility in system design. The BLS notes that web developers increasingly work with accessibility requirements as part of their standard role. Mentioning ARIA roles and keyboard navigation in your design is a differentiator.
Preparing with actual verbal practice
Reading about closures is not the same as explaining them to someone in three sentences. The best preparation for a technical interview is speaking your answers out loud, getting interrupted with follow-ups, and discovering where your explanations fall apart.
Craqly’s AI interview feature lets you practice exactly this: answer a frontend question out loud, hear a follow-up, and get feedback on whether your explanation was technically complete or fuzzy. It’s a faster feedback loop than studying alone with a document.
If you had to pick the three highest-use things to nail for a React/JS/CSS interview: closures and the event loop, the hooks model (especially stale closures), and CSS specificity with a layout example. Get those three sharp and the rest fills in around them.