Frontend Developer interview questions (India, 2026): what to ask and what to listen for

12 interview questions for a Frontend Developer role, grouped by what each round should establish, each with what a strong answer contains, plus a five-point scorecard so every interviewer rates the same things.

Last updated 3 September 2026. Competitor pricing and plan limits are re-verified against each vendor’s own pages.

Interviewing a Frontend Developer well means asking about work the candidate has actually done, listening for specifics, and scoring every candidate on the same five criteria. The questions below are grouped by what they establish; each one comes with what a good answer contains, which is the part most question lists leave out.

A Frontend Developer builds the parts of the product users touch — the web application's screens, forms, state and performance — in React or a similar framework, working with a designer and a backend developer to ship features that work on a cheap Android phone as well as a laptop.

Use the screening questions on the job description page to filter before anyone reaches an interview, and the scorecard at the end so a panel can compare candidates rather than impressions.

What they have built

Show me something you built that is live. Walk me through one screen: how it is structured, what state it holds, and what was hard about it.: A strong answer: Ownership and reasoning about structure and state. Open the dev tools together if possible; the best candidates are comfortable being looked at closely.
Describe a performance problem you fixed on the frontend. How did you find it and what did you change?: A strong answer: Measured with a tool, identified the cause — bundle, re-renders, images, waterfall — and made a specific change with a measured result.
How does your current product behave on a slow connection or a mid-range Android phone? What did you do about it?: A strong answer: Has actually tested on real devices or throttled conditions, and made concrete changes. Indian users are on those devices.
Tell me about a disagreement with a designer and how it was resolved.: A strong answer: Constructive feedback on feasibility or usability, respect for design intent, and a resolution that improved the product.

Technical depth

Here is a component with a subtle bug [stale closure, missing dependency, uncontrolled input]. Find it and explain it.: A strong answer: Understands the framework's rendering and state model, not only its syntax. Explains why the bug happens.
Build a form for [a small feature] on paper: fields, validation, loading and error states, and what happens if the request fails halfway.: A strong answer: Considers every state, not just the happy path; handles failure and retry; thinks about the user waiting.
How would you make this screen accessible? What would you check with a screen reader?: A strong answer: Semantic elements, labels, focus management, keyboard operation, contrast — and having actually used a screen reader at least once.
When would you choose server-side rendering over a client-rendered app, and what does it cost?: A strong answer: Understands the trade-offs — first load, SEO, complexity, hosting — rather than a default preference.

Working in a small team

The backend API does not return what the screen needs. What do you do?: A strong answer: Proposes a better API shape to the backend developer with reasons, and adapts in the meantime — collaboration rather than complaint or a workaround that hides the problem.
How do you keep the component library consistent when three people are adding to it?: A strong answer: Conventions, review, documentation, and a willingness to consolidate duplicates.
What do you test on the frontend, and what do you rely on manual checks for?: A strong answer: Judgement — critical flows and logic tested, pixel details checked visually — rather than dogma either way.
What do you want to get deeper in — performance, design systems, mobile, full stack — and does this role offer that?: A strong answer: A direction the role can serve; reduces churn.

Scorecard for Frontend Developer interviews

Score each candidate on these five criteria, one to four, straight after the interview and before talking to the other interviewers. Written scores taken independently are what make a panel decision defensible; a discussion first produces one opinion with several signatures.

Ownership: a live thing they built and can reason about screen by screen.
Framework depth: understands rendering and state, finds subtle bugs.
Performance and device reality: measured and fixed for slow connections and phones.
Accessibility and completeness: every form state, keyboard and screen reader.
Collaboration: designer and backend interactions handled constructively.

Screen before you interview

Most Frontend Developer interviews that go badly were avoidable at the application stage. The job description template for this role carries five screening questions that settle the deal-breakers — notice period, location, the one or two hard requirements — before anyone books a slot.

How many years of professional experience do you have building production web applications in [React / framework]? — knockout
Are you able to work [from our City office X days a week / remote with overlap hours]? — knockout
Can you share a link to something you built that is live — a product, a site, a project — when we ask? — for context
What is your current notice period, in days? — for context

Questions, answered straight

What is the best interview for a Frontend Developer?

Have them show something live and walk through one screen — structure, state, what was hard — with the dev tools open. Then hand them a component with a subtle state bug. Together they cover ownership, framework depth and reasoning in under an hour.

Should I give a frontend take-home?

Only if it is under two hours and mirrors real work — a small form with all its states, for instance. Long take-homes lose good candidates, who have other offers. A live session on real code is usually better.

How do I assess accessibility knowledge?

Ask how they would make a specific screen accessible and what they would check with a screen reader. Candidates who have actually used one give concrete answers about focus, labels and announcements; others recite a checklist.