The one skill behind frontend interviews: matching the signal to the technique

Most frontend interview prep is a list of questions. You grind the list, feel
prepared, then freeze in the room — because the real question was never "do you
know debounce," it was "can you notice that this problem wants debounce."

That noticing is the actual skill. Interviews test whether you can read a vague
problem and reach for the right tool fast. The list-grinding approach trains
recall; the interview tests recognition. They're not the same muscle.

Here's the pattern that helped me, with concrete examples across the areas
frontend interviews actually cover.

The move: signal → technique

For every problem, name the signal (the tell in the prompt) and the
technique it points to. Train the mapping, not the memorized answer.

JavaScript

• Signal: "only run after the user stops typing" → Technique: debounce (trailing timer, reset on each call).
• Signal: "same input, don't recompute" → Technique: memoize with a Map keyed on the arguments.
• Signal: "these async steps depend on each other, cancel if a newer one starts" → Technique: an abort token / stale-response guard.

React

• Signal: "child re-renders when unrelated parent state changes" → Technique: memo + stable callbacks (useCallback), or lift/colocate state.
• Signal: "derived value recomputed every render and it's expensive" → Technique: useMemo — but first ask if it's actually expensive.

TypeScript

• Signal: "the return type depends on the argument's type" → Technique: generics, or overloads when the shapes are discrete.
• Signal: "this value is one of a fixed set and I keep typo-ing it" → Technique: as const + a union, over a loose string.

Browser / performance

• Signal: "layout janks while scrolling" → Technique: move work off the main thread or batch reads/writes to avoid layout thrash.
• Signal: "I need to know when this element enters the viewport" → Technique: IntersectionObserver, not scroll listeners.

Why easy → hard matters

Once you've got the mapping, walk each technique from its simplest form to its
gnarly edge cases. Debounce is easy until the interviewer asks for a leading
edge, or cancellation, or a flush. The easy version proves you know the tool;
the hard version is where the signal-reading actually pays off.

Practicing the recognition, not the recall

Two things that made this stick for me:

1. Run the code where you read it. Reading a debounce implementation and writing one against a live console are different. Do the second.
2. Get quizzed, don't get told. Have someone (or an LLM) give you the signal and make you produce the technique cold, then critique it.

I ended up building a free site around exactly this — Frontend Interview
Prep — 265 questions across HTML/CSS, the
browser, JavaScript, TypeScript, React, system design, and DSA, each pairing the
signal with the technique and each with an in-browser editor so you can run your
answer. There's also a "copy as prompt" button on every question that hands you
a ready-made "quiz me on this" prompt for ChatGPT/Claude, which is the
recognition-drilling loop from point 2. It's the tool I wish I'd had.

But the technique stands on its own: next time you practice, before you write a
line, say out loud what signal the prompt is giving you and which tool it wants.
That habit is what shows up in the room.