What are the most common frontend interview questions?

Closures, the event loop, this binding, prototypes, and value versus reference on the JavaScript side; props versus state, effects and dependency arrays, keys and memoisation on the React side; the box model, specificity and Flexbox versus Grid for CSS. Machine coding repeats a handful of components — tabs, modal, debounced search, autocomplete.

How many rounds are there in a frontend interview?

Typically three to five at product companies: a JavaScript screen, a React round, a machine-coding round, often a system design discussion from mid-level upward, and a hiring-manager conversation. Startups often compress this into one or two longer sessions covering the same ground.

How do I prepare for a frontend interview in a month?

One week each on JavaScript fundamentals, React, machine coding, and system design plus HTML/CSS. Prepare out loud rather than by reading, build the common components without looking anything up, and keep a running list of every question you are actually asked so you can answer it properly the same evening.

Do frontend interviews ask DSA questions?

Some, but lighter than backend loops. Expect arrays, strings and hash maps — the kind of manipulation that appears inside a real feature, such as grouping, deduping or a frequency count. Graph and dynamic programming questions are uncommon outside the largest companies.

What is a machine coding round?

A live session where you build a working component in 30 to 45 minutes while the interviewer watches. Common prompts are tabs, a modal, a debounced search box, autocomplete and infinite scroll. State placement, cleanup and keyboard support are what get scored, not how much you finish.

What is asked in a frontend system design round?

You architect a user-facing feature — a feed, an autocomplete, a chat app — and justify the trade-offs. The constraints are network, device and browser rather than throughput and storage, so pagination, virtualisation, caching, rendering strategy and real-time transport dominate the discussion.

How much React do I need to know?

Enough to reason about why a component re-rendered. That means hooks and their rules, dependency arrays, keys, lifting state, context and its re-render behaviour, and the basics of memoisation. Server Components and the App Router are increasingly expected if the job description mentions Next.js.

Are HTML and CSS still asked in frontend interviews?

Yes, and framework-first candidates often lose marks there. Specificity, the box model, positioning and stacking contexts, Flexbox versus Grid, and em versus rem come up regularly, as do basic accessibility questions about semantic elements and keyboard reachability.

What should I say when asked about my weaknesses?

Name something real, then what you did about it. A specific answer — "I used to skip writing tests under deadline pressure, so I now write the test for the bug before I fix it" — is credible. Answers framed as strengths in disguise are transparent and cost you goodwill.

How do I answer 'tell me about a project you built'?

Say what problem it solved, the two or three decisions you had to make, what you would change now, and what broke. The last two matter most — a candidate who can critique their own work convincingly demonstrates more judgement than one who only lists features.

What salary should I expect as a frontend developer in India?

It varies enormously by company type, city and experience. Product companies pay substantially more than service companies at the same level, and the system design round often determines your band within a company more than the coding rounds do. Research a range for your specific level and city before the conversation.

How do I stand out from other candidates?

Explain your reasoning out loud, volunteer the trade-off in your own answer before being asked, and mention the things nobody else does — accessibility, error states, cleanup, what you would measure. Those are consistently the notes interviewers write down when they recommend a hire.

Frontend Interview Questions and Answers

Short answer

A frontend loop is usually four rounds: a JavaScript fundamentals screen, a React round, a machine-coding round where you build a component live, and — from mid-level up — a system design discussion. The questions repeat far more than people expect, so preparing by round beats preparing by topic.

Round	Typical length	What is being filtered
JavaScript fundamentals	45 min	Do you understand the language, or just the framework?
React / framework	45 min	Can you reason about renders and state, not just write hooks?
Machine coding	45–60 min	Can you build something correct while someone watches?
System design	45 min	Can you make and defend architecture trade-offs?
HTML / CSS / a11y	30 min, often merged	Do you know the platform under the framework?
Behavioural	30–45 min	Will people want to work with you?

The rounds, and what each one is really filtering for.

What does a frontend interview loop look like?

Most Indian product companies run three to five rounds over one or two days. The first is almost always a screen: JavaScript fundamentals, sometimes with a small coding exercise. If you pass, you get a framework round — React for the overwhelming majority of roles — and a machine-coding round where you build a working component live. From about two years of experience upward, a system design discussion is added, and it is usually the round that decides your band rather than whether you get an offer at all.

Service companies and startups compress this. A startup may do one long session covering everything; a service company may lean harder on definitions and less on building. Ask the recruiter what the rounds are — they will tell you, and it is a completely normal question. Knowing whether machine coding is in the loop changes how you spend your preparation time more than any other single piece of information.

The JavaScript questions that come up every time

The fundamentals screen draws from a small pool. Closures, `this`, the event loop, prototypes, hoisting and the temporal dead zone, equality and coercion, and the difference between value and reference cover the large majority of what gets asked. They are not asked to check you memorised definitions — they are asked because each one has a consequence that shows up in real bugs.

Three output questions that appear constantlyjavascript

1for (var i = 0; i < 3; i++) setTimeout(() => console.log(i), 0);
2// → 3 3 3     one shared binding; `let` gives 0 1 2
3
4console.log(0.1 + 0.2 === 0.3);
5// → false     IEEE 754 floating point
6console.log((0.1 + 0.2).toFixed(2) === "0.30");
7// → true      compare with a tolerance or a fixed precision
8
9const a = { n: 1 };
10const b = a;
11b.n = 2;
12console.log(a.n);
13// → 2         objects are assigned by reference, not copied

The pattern to notice is that each of these has a follow-up waiting. The loop question leads to closures and to `let` versus `var`; the floating point one leads to how you would compare currency; the reference one leads to shallow versus deep copies and, in a React round, to why your component did not re-render. Preparing the follow-up is worth more than preparing another twenty first questions.

The React questions that come up every time

The React round is mostly about renders and state. Expect the difference between props and state, when effects run and why they run twice in development, the dependency array, why a list needs stable keys, what `useMemo` and `React.memo` each do, and how you would share state between distant components. The strongest answers connect back to JavaScript — a stale closure is a closure question wearing a React costume.

The bug asked about most oftenjsx

1function Timer() {
2  const [count, setCount] = useState(0);
3
4  useEffect(() => {
5    const id = setInterval(() => setCount(count + 1), 1000);
6    return () => clearInterval(id);
7  }, []);                        // captured count = 0 forever
8  // → 1, 1, 1, 1…
9
10  return <p>{count}</p>;
11}
12
13// Fix: the updater form never reads the captured value
14setInterval(() => setCount(c => c + 1), 1000);
15// → 1, 2, 3, 4…

If you can explain that bug in terms of closures — each render creates a new function that captured that render's state, and the empty dependency array means the effect only ever ran with the first one — you have answered a React question and a JavaScript question at the same time. Interviewers notice candidates who join those dots, because it means the knowledge will transfer when the framework changes.

What HTML, CSS and accessibility questions are asked?

Often merged into another round, and often where framework-first candidates struggle. The recurring topics are the box model, specificity, positioning, Flexbox versus Grid, `em` versus `rem`, how stacking contexts work, and semantic HTML. Accessibility questions are increasingly common and rarely deep — knowing that a `div` with an onClick is not keyboard reachable, and that a label needs to be associated with its input, covers most of it.

Centring, specificity and the unit questioncss

1/* Centring — the two answers to have ready */
2.a { display: grid; place-items: center; }
3.b { display: flex; justify-content: center; align-items: center; }
4
5/* Specificity: id 100, class 10, element 1 — !important overrides all */
6#nav .item a  { color: red; }    /* → 1,1,1 = 111 */
7.item a.link  { color: blue; }   /* → 0,2,1 = 21  — loses */
8
9/* em compounds with the parent, rem is always the root */
10html { font-size: 16px; }
11.card    { font-size: 1.5em; }   /* → 24px */
12.card p  { font-size: 1.5em; }   /* → 36px, compounded */
13.card h3 { font-size: 1.5rem; }  /* → 24px, always */

The answer that stands out here is knowing when to reach for each layout system. Flexbox is content-out — items size themselves and share what is left over — while Grid is layout-in, where you define the tracks first and items fit into them. That framing answers "which would you use for a navbar?" and "which for a page shell?" in one sentence, and it is more useful than reciting that one is 1D and the other 2D.

This is 1 of 200+ questions in the Complete Frontend Kit

Get every question with detailed answers, follow-ups and real code — plus coding challenges and a last-minute revision sheet. One-time payment, instant access.

⚡ Get the Complete Frontend Kit → ₹499

What happens in the machine coding round?

You build a working component in 30 to 45 minutes while the interviewer watches. The prompts repeat: a counter as a warm-up, then tabs, a modal, a debounced search box, autocomplete, infinite scroll or a star rating. What is scored is where you put state, whether you clean up timers and listeners, whether the keyboard works, and how you behave when something breaks.

The cleanup that most often costs marksjsx

1useEffect(() => {
2  const controller = new AbortController();
3  const id = setTimeout(() => {
4    fetch(`/api/search?q=${q}`, { signal: controller.signal })
5      .then(r => r.json())
6      .then(setResults)
7      .catch(e => { if (e.name !== "AbortError") throw e; });
8  }, 300);
9
10  return () => { clearTimeout(id); controller.abort(); };
11  // → debounce AND cancellation: one request per pause, and a slow
12  //   earlier response can never overwrite a newer one
13}, [q]);

A half-finished component with clean state placement and working cleanup scores better than a complete one built from three tangled booleans and a scroll listener nobody removes. Narrate while you build — say why state lives where you put it — because reasoning the interviewer cannot hear earns nothing, and a silent candidate who finishes often loses to a talkative one who does not.

Keys, and why the index is the wrong answerjsx

1{items.map((item, i) => <Row key={i} item={item} />)}
2// → remove the first row and React reuses the wrong DOM nodes:
3//   a text input keeps the previous row's value
4
5{items.map((item) => <Row key={item.id} item={item} />)}
6// → React matches by identity, so state follows the right row
7
8// The other half of the same question:
9const remaining = todos.filter(t => !t.done).length;
10// → derive during render. Storing it in state creates a second
11//   source of truth that has to be kept in sync forever.

What does the system design round ask?

From mid-level upward you will be asked to architect something user-facing: a news feed, an autocomplete, a chat app, a dashboard with live data, or a component library. Unlike backend system design, the constraints are the network, the device and the browser. "Scale" usually means more data on one screen rather than more users, which is why virtualisation, caching, bundle size and rendering strategy dominate the conversation.

Use a fixed structure so it costs you nothing under pressure: requirements, constraints, high-level architecture, rendering strategy, data and caching, a deep dive wherever the interviewer points, then the non-functional work — accessibility, internationalisation, error and offline states, a performance budget, observability. Most candidates never reach that last group, so raising it yourself in the final five minutes is the cheapest way to stand out in the whole loop.

The `this` question, which appears in almost every screenjavascript

1const user = {
2  name: "Arun",
3  greet() { return `hi ${this.name}`; },
4};
5
6const fn = user.greet;
7console.log(fn());
8// → hi undefined     `this` is lost when the method is detached
9
10console.log(fn.call(user));
11// → hi Arun          call/apply/bind restore the receiver
12
13const bound = user.greet.bind(user);
14console.log(bound());
15// → hi Arun          bind returns a permanently bound copy

How should you prepare, realistically?

Preparation fails when it is passive. Reading answers produces recognition, and interviews test recall under pressure — two very different things. The fix is to say answers out loud and to build components without looking anything up, which surfaces the gap between "I know this" and "I can explain this to a stranger who is judging me".

Week 1 — JavaScript fundamentals: closures, this, the event loop, prototypes, coercion. Say each answer aloud.
Week 2 — React: renders, effects, keys, memoisation, state placement. Explain the stale-closure bug from memory.
Week 3 — Machine coding: build tabs, a modal, debounced search, autocomplete and infinite scroll, timed, twice each.
Week 4 — System design and HTML/CSS: run the framework aloud on five prompts; revise specificity, Flexbox and Grid.
Throughout — prepare two projects you can discuss in depth, including what you would do differently now.

Two habits are worth more than extra hours. First, keep a list of every question you were asked in a real interview and answer it properly the same evening — the pool is small and repeats fast, so this compounds quickly. Second, record yourself answering three questions and watch it back; almost everyone discovers they answer too quickly, skip the reasoning, and stop before the interesting part.

One more thing worth saying about the machine-coding and system-design rounds together: they are the two where preparation transfers least from reading. You can learn what a stale closure is by reading about it once, but you cannot learn to structure an unfamiliar problem under time pressure without doing it. Budget most of your practice hours there, because those are also the rounds that most often decide the level you are offered.

What questions should you ask the interviewer?

This is scored, and most candidates waste it. Generic questions about culture read as filler. Specific questions about the work signal genuine interest and give you information you actually need — what the codebase looks like, how work is decided, what happens when something breaks. It is also your only chance to find out whether you want the job.

→What does the frontend stack look like today, and what would you change if you could?
→How does a piece of work go from idea to production here?
→Who decides what gets built — and how much say do engineers have?
→What does the testing and code review process look like in practice?
→What is the on-call or incident story for the frontend?
→What would a successful first three months look like in this role?

How many rounds should I expect?

Three to five at most product companies: a fundamentals screen, a framework round, machine coding, often system design, and usually a hiring-manager conversation. Startups compress this into one or two long sessions. Ask the recruiter — it is a normal question and the answer changes how you prepare.

Do I need to know data structures and algorithms?

Less than for a backend role, but not zero. Expect arrays, strings, hash maps and occasionally recursion — the kind of problem that appears inside a real feature. Graph algorithms and dynamic programming are rare in frontend loops outside the largest companies.

Is TypeScript required?

Increasingly, for React roles. Most job descriptions list it and most modern codebases use it, so its absence filters resumes before the interview. In the rounds themselves, core JavaScript still carries more weight — expect to type a component's props and explain a utility type or two.

What if I blank on a question?

Say what you do know and reason out loud from there. "I haven't used that directly, but based on the name I'd expect it to do X — is that right?" is a good answer. Silence and bluffing are the two bad options; interviewers are allowed to help, and how you use a hint is itself a signal.

How important are my side projects?

Very, for freshers and career changers — they are often the only evidence of what you can build. Two projects you can discuss deeply beat six you can only demo. Be ready to explain a decision you now think was wrong, because that question comes up constantly and a candid answer lands well.

Frequently asked questions

What are the most common frontend interview questions?: Closures, the event loop, this binding, prototypes, and value versus reference on the JavaScript side; props versus state, effects and dependency arrays, keys and memoisation on the React side; the box model, specificity and Flexbox versus Grid for CSS. Machine coding repeats a handful of components — tabs, modal, debounced search, autocomplete.
How many rounds are there in a frontend interview?: Typically three to five at product companies: a JavaScript screen, a React round, a machine-coding round, often a system design discussion from mid-level upward, and a hiring-manager conversation. Startups often compress this into one or two longer sessions covering the same ground.
How do I prepare for a frontend interview in a month?: One week each on JavaScript fundamentals, React, machine coding, and system design plus HTML/CSS. Prepare out loud rather than by reading, build the common components without looking anything up, and keep a running list of every question you are actually asked so you can answer it properly the same evening.
Do frontend interviews ask DSA questions?: Some, but lighter than backend loops. Expect arrays, strings and hash maps — the kind of manipulation that appears inside a real feature, such as grouping, deduping or a frequency count. Graph and dynamic programming questions are uncommon outside the largest companies.
What is a machine coding round?: A live session where you build a working component in 30 to 45 minutes while the interviewer watches. Common prompts are tabs, a modal, a debounced search box, autocomplete and infinite scroll. State placement, cleanup and keyboard support are what get scored, not how much you finish.
What is asked in a frontend system design round?: You architect a user-facing feature — a feed, an autocomplete, a chat app — and justify the trade-offs. The constraints are network, device and browser rather than throughput and storage, so pagination, virtualisation, caching, rendering strategy and real-time transport dominate the discussion.
How much React do I need to know?: Enough to reason about why a component re-rendered. That means hooks and their rules, dependency arrays, keys, lifting state, context and its re-render behaviour, and the basics of memoisation. Server Components and the App Router are increasingly expected if the job description mentions Next.js.
Are HTML and CSS still asked in frontend interviews?: Yes, and framework-first candidates often lose marks there. Specificity, the box model, positioning and stacking contexts, Flexbox versus Grid, and em versus rem come up regularly, as do basic accessibility questions about semantic elements and keyboard reachability.
What should I say when asked about my weaknesses?: Name something real, then what you did about it. A specific answer — "I used to skip writing tests under deadline pressure, so I now write the test for the bug before I fix it" — is credible. Answers framed as strengths in disguise are transparent and cost you goodwill.
How do I answer 'tell me about a project you built'?: Say what problem it solved, the two or three decisions you had to make, what you would change now, and what broke. The last two matter most — a candidate who can critique their own work convincingly demonstrates more judgement than one who only lists features.
What salary should I expect as a frontend developer in India?: It varies enormously by company type, city and experience. Product companies pay substantially more than service companies at the same level, and the system design round often determines your band within a company more than the coding rounds do. Research a range for your specific level and city before the conversation.
How do I stand out from other candidates?: Explain your reasoning out loud, volunteer the trade-off in your own answer before being asked, and mention the things nobody else does — accessibility, error states, cleanup, what you would measure. Those are consistently the notes interviewers write down when they recommend a hire.

This is 1 of 200+ questions in the Complete Frontend Kit

Get every question with detailed answers, follow-ups and real code — plus coding challenges and a last-minute revision sheet. One-time payment, instant access.

⚡ Get the Complete Frontend Kit → ₹499