Deloitte Frontend Engineer Interview: Questions & Prep (2026)

Deloitte is one of the Big Four consulting firms with a large technology delivery presence in India. As of July 2026, knok jobradar tracks 405 Frontend Engineer openings across the country, and Deloitte lists 444 open roles, making it one of the most active hirers in the tech consulting market right now.

The interview process at Deloitte typically runs two to four rounds. Candidates report an initial online coding assessment, one or two technical interviews covering JavaScript and React, and a final discussion with HR or a hiring manager. The process is structured and can take a few weeks from application to offer. Ask your recruiter about the format for your specific practice before your first round.

Salary bands for Frontend Engineers across India (knok jobradar, July 2026):

Deloitte typically offers within these bands. Exact figures vary by practice, client billing rate, and city. Publicly reported offers on Glassdoor and levels.fyi suggest Bangalore-based roles often land toward the upper half of each range.

These questions come up repeatedly in Deloitte Frontend Engineer interviews, drawn from candidate reports. Technical rounds focus on JavaScript fundamentals and React, while the managerial or HR round tests communication and delivery track record.

1. Explain the virtual DOM. How does React use it to decide what to update on screen?
2. What is the difference between null and undefined in JavaScript? When do you see each in practice?
3. How does event delegation work, and why is it useful when building large UIs?
4. How would you structure a large React codebase so it stays maintainable as the team and feature count grow?
5. What are React hooks? Walk through when you would choose useCallback over useMemo.
6. How do you handle API errors and loading states gracefully so the user always sees a clear UI state?
7. Explain CSS specificity. What do you do when two rules conflict unexpectedly?
8. Describe a time you improved the performance of a page or component. What did you measure, and what did you change?
9. How do you ensure a component meets web accessibility (a11y) standards?
10. Tell us about a time you disagreed with a teammate on a technical approach. How did you resolve it?
11. How do you evaluate a new frontend library before recommending it to your team?
12. Deloitte projects run on strict client timelines. Tell us about a time you delivered under pressure.

Q: Describe a time you improved the performance of a page or component.

*Situation:* Our product listing page was loading slowly on mobile networks, and users were dropping off before content appeared.

*Task:* I was asked to investigate and reduce the time to interactive without changing the visual design.

*Action:* I used browser DevTools to profile the page and found two problems: a large unoptimised image bundle and a blocking third-party script. I converted images to WebP, added lazy loading for below-the-fold images, and moved the third-party script to load asynchronously. I also split a heavy component into a lazy-loaded chunk using React's dynamic import.

*Result:* The page felt noticeably faster on mid-range devices. The team adopted these steps as a standard checklist for future feature work, which reduced similar problems going forward.

---

Q: Tell us about a time you disagreed with a teammate on a technical approach.

*Situation:* During a dashboard rebuild, a senior colleague wanted to introduce a full state-management library for a feature that only handled a few API calls.

*Task:* I believed the added complexity was unnecessary, but I did not want to derail the project or create friction with someone more senior.

*Action:* I put together a short written comparison of both approaches, covering bundle size impact, onboarding cost for new developers, and how each would look in code review. I shared it in a team channel rather than pushing back in a meeting, which gave everyone time to think it through. We discussed it calmly and agreed to try the lighter approach first, with an option to revisit if needed.

*Result:* The simpler solution held up through the full project. The team updated its internal guidelines to prefer minimal dependencies for similar cases.

---

Q: Tell us about a time you delivered under pressure.

*Situation:* A client demo was moved forward by several days, and a key part of the frontend was not yet integrated with the backend.

*Task:* I needed to make the UI functional enough to demonstrate the core workflow within the new timeline.

*Action:* I built a mock service layer that returned realistic data so the demo could run end-to-end. I was upfront with my manager about what was real and what was mocked, and I documented the remaining integration work clearly. I also kept the mock code isolated so it could be swapped out cleanly afterward.

*Result:* The demo went well, the client approved the next project phase, and the real integration was completed shortly after. My manager appreciated the transparency and the clean separation of mock from production code.

The STAR framework (Situation, Task, Action, Result) is what Deloitte interviewers expect for behavioural questions. Keep each story to two to three minutes when spoken aloud. Spend most of that time on the Action, describing specific steps you personally took rather than what 'we' did as a group.

For technical concept questions, use an Explain, Example, Trade-off approach: define the concept clearly, give a real example from your work, then say when you would or would not use it. This shows depth without reciting a textbook definition.

For architecture or system design questions, think out loud from the start. Deloitte interviewers value the reasoning process as much as the final answer. Open with requirements, sketch a component structure, then discuss trade-offs (for example: server-side rendering vs client-side rendering for a data-heavy enterprise dashboard).

For estimation or delivery questions, show that you break large problems into smaller pieces and communicate early when a timeline looks at risk. Deloitte's consulting culture values proactive communication over silent heroics.

Deloitte Frontend Engineer interviewers are looking for more than raw coding speed.

Strong JavaScript fundamentals. React knowledge matters, but they want to see you understand what is happening under the hood, not just which hook to call.

Client-first communication. Because Deloitte work is often client-facing, they look for engineers who can explain technical decisions in plain language and surface blockers early, before they become problems.

Ownership and a delivery track record. Candidates who can point to specific features they shipped, bugs they diagnosed, and lessons they applied score higher than those with broad but shallow experience.

Adaptability. Deloitte teams rotate across projects and stacks. Interviewers often probe how you ramp up on an unfamiliar codebase or evaluate a tool you have never used before.

Collaboration, not ego. The disagreement question (number 10 in the list above) is a genuine filter. They want engineers who build alignment, not engineers who either cave instantly or dig in stubbornly.

Solidify JavaScript and React fundamentals first. Review closures, the event loop, prototypal inheritance, and promise chains. Practise explaining these out loud, not just writing them. For React, make sure you can explain the rendering cycle, hook dependency arrays, and common performance pitfalls.

Build something small and be able to walk through it. Pick one focused project (a data table, a validated form, a dashboard widget) and build it with attention to accessibility, error handling, and performance. Interviewers respond well when you can narrate your own code confidently.

Prepare four to six STAR stories. Cover: a technical challenge you solved, a delivery under pressure, a disagreement you navigated well, and a time you improved a process or codebase. Practise each one spoken aloud in under three minutes.

Research the specific Deloitte practice you are interviewing for. USI, consulting, and product-focused teams have different working contexts. Read recent news about their digital transformation work and prepare a couple of genuine questions about the team and the type of projects you would join.

If you are actively applying while prepping, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so you can spend your time on interview preparation rather than manual job hunting.

Jumping to code before thinking. Interviewers want to see your reasoning process. Take a moment to ask clarifying questions and think out loud before writing anything.

Treating React as the answer to everything. Candidates who default to 'I would use React' without being able to justify it or consider alternatives raise a flag. Know when a lighter solution is the right call.

Vague STAR stories. Saying 'we improved performance' without explaining your specific contribution, what you measured, and what changed is a missed opportunity. Use 'I' not 'we' when describing your own actions.

Under-preparing for the soft-skills round. Many candidates over-prepare for coding and walk into the managerial or HR discussion with no ready examples. At Deloitte, that final round is a real filter, not a formality.

Not asking questions. Ending the interview with nothing to ask signals low interest. Prepare at least two genuine questions about team structure, the kinds of problems you would work on, or the growth path available.

Overstating familiarity with tools. If a library or framework appears on your resume, expect a follow-up question. Only list technologies you can discuss in depth.