Work on three layers: strong JavaScript fundamentals (closures, event loop, promises, prototypes), core HTML/CSS and accessibility basics, and at least one framework in depth — React being the most in-demand in India. Build two or three real projects you can explain line by line, and rehearse explaining your decisions out loud. Most candidates fail not because they don't know the answers, but because they can't structure them under pressure, so take a few timed mock interviews with an experienced frontend developer before the real one.

Senior interviews in India go beyond syntax. Expect frontend system design (component architecture, state management at scale, caching, performance budgets), deep JavaScript and React internals, testing strategy, and behavioural questions about mentoring, code reviews, and stakeholder handling. Prepare 4–5 detailed stories from your own work — a performance improvement you led, a migration, a production issue you resolved — and practise whiteboarding an architecture, since senior rounds judge how you think, not just what you recall.

For most working developers, 6–8 weeks of focused preparation is realistic: 2–3 weeks on JavaScript and framework fundamentals, 2 weeks on projects and system design, and the final stretch on mock interviews and company research. Freshers may need 3–4 months to build fundamentals alongside projects. Consistency beats intensity — 90 focused minutes daily with weak areas tracked after every mock will move your frontend developer interview preparation faster than weekend cramming.

Freshers are usually tested on HTML semantics, CSS layout (flexbox, grid, positioning, media queries), and JavaScript essentials such as var/let/const, hoisting, closures, promises, event delegation, and ES6 features. If React is on your resume, expect basic questions on components, props vs state, and useState/useEffect. Interviewers also probe your projects — why you chose a stack, what broke, how you fixed it — so prepare crisp project walkthroughs and a short self-introduction.

Search GitHub for repositories on frontend and React interview preparation — several well-maintained ones compile hundreds of questions with answers and links to further reading. They are excellent for building a question bank and spotting topics you haven't covered. The limitation is that lists can't tell you how an interviewer evaluates your delivery, so use them for revision and pair them with timed mock interviews where you answer aloud and receive honest feedback.

Experienced candidates are grilled on virtual DOM and reconciliation, controlled vs uncontrolled components, context vs prop drilling, performance optimisation with memoisation and lazy loading, error boundaries, and key prop behaviour. You'll often get design scenarios — build an autocomplete, infinite scroll, or data table — where state modelling and edge cases matter most. Prepare real examples from production, like a re-render issue you debugged, because experienced rounds test how you've applied React, not definitions.

Expect depth on useState and useEffect — dependency arrays, cleanup functions, and bugs from stale closures — plus useContext, useReducer, useRef, and useMemo/useCallback. Interviewers frequently ask you to build a custom hook (like useDebounce or useFetch), explain the rules of hooks, and compare useEffect with useLayoutEffect. Be ready to discuss when memoisation actually helps versus adds overhead, since good interviewers test trade-offs rather than the API surface.

Keep it to 60–90 seconds with a simple arc: your current role and tech stack, two or three highlights relevant to the job, and why this opportunity excites you. For a frontend role, mention the frameworks you work in, the scale or impact of what you've built, and one strength with proof. Rehearse it aloud until it sounds natural rather than memorised, because interviewers often use this answer to set the direction of the rest of the conversation.

Pick a genuine, non-fatal weakness — one that isn't core to the job — and pair it with the concrete action you're taking to improve. For example: "I used to over-engineer components; now I get early feedback in pull requests and keep the first solution simple." Avoid clichés like "I'm a perfectionist" and never say you can't think of one. Interviewers use this question to judge self-awareness and honesty, so a real weakness with visible progress lands far better than a rehearsed strength in disguise.

Keep it to one page (two for 8+ years of experience), lead every experience bullet with impact — "reduced load time by 40% through code splitting" beats "worked on React" — and quantify results wherever possible. Follow a clear structure: header, summary, skills, experience, projects, education. Mirror keywords from the job description so it clears ATS filters, skip photos and heavy graphics, and cut routine or outdated work. Before applying, get the resume reviewed by someone senior in the field, since small wording changes often decide shortlists.

With no full-time experience, lead with projects — two or three well-built ones with live links and GitHub repos, each described by problem, stack, and measurable outcome. Add a skills section grouped by category (languages, frameworks, tools), any internships or open-source contributions, and education near the top if your academics are strong. Strictly keep it to one page. Recruiters hiring freshers look for working code and fundamentals, so a resume built around real projects outperforms one listing only coursework.

Yes, as a starting point — a good template gets structure, alignment, and section order right. The mistake is treating it as fill-in-the-blanks: recruiters see the same templates constantly, and shortlisting depends on content showing measurable impact. Choose a clean, single-column, ATS-friendly layout (avoid tables, icons, and two-column designs that parsers misread) and then customise every line to your own work. A plain template with strong content will always beat a designer template with generic points.

Overleaf is a solid choice — LaTeX templates give clean, consistent typography and version control, which is why many developers and engineering students prefer it. Keep the design simple: single column, standard fonts, and export as a PDF with selectable text so ATS parsers can read it. If you're not already comfortable with LaTeX, the setup time may not be worth it — a well-structured resume in Docs or Word is equally acceptable to most recruiters, and what matters is the content inside it.

PDF, almost always — it preserves formatting across devices and applicant tracking systems, while Word files often break. Ensure the PDF has selectable text (export it properly, never a scanned copy), use a clear file name like Firstname_Lastname_Resume.pdf, and keep the size small. The only exception is a portal or recruiter who explicitly asks for a Word file because their parser needs it. For most applications in India, a clean one-page PDF is the safest choice.