whatfix101 Frontend Engineer Interview: Questions & Prep (2026)

Whatfix is a Bangalore-based digital adoption platform (DAP) company that helps businesses build in-app guides, walkthroughs, and contextual help overlays on top of enterprise software. As of July 2026, Whatfix has 36 open Frontend Engineer roles, making it one of the largest single-company opportunities in knok's India jobradar for this role. Their frontend team works primarily with React and TypeScript to build a product that literally wraps other web apps, so deep DOM knowledge and performance discipline matter more here than at a typical SaaS shop.

The interview process typically runs across 3-4 rounds: an initial recruiter screen, one or two technical rounds covering JavaScript fundamentals and React, a system design or product-thinking round, and a hiring-manager conversation. Candidates report the process takes 2-4 weeks end to end. Salary bands, commonly cited across Glassdoor and industry surveys, range from 12-22 LPA for mid-level engineers to 24-40 LPA for senior engineers in Bangalore.

Whatfix interviewers focus on core JavaScript, React internals, performance, and the unique challenge of building overlays on third-party pages. Here are the questions candidates most commonly report:

1. Explain how the JavaScript event loop works and what happens when you mix setTimeout, Promises, and async/await in a single code block.
2. How does React's reconciliation algorithm decide what to re-render? When would you use useMemo, useCallback, or React.memo?
3. Whatfix injects widgets into customer web pages. How would you design a JavaScript SDK that does not pollute the host page's global namespace or CSS?
4. Walk me through how you would build a tooltip that positions itself correctly even when the target element is near the viewport edge.
5. What is the difference between shadow DOM and an iframe for isolating third-party UI? What are the trade-offs?
6. How do you handle CSS specificity conflicts when your styles need to win against an unknown host page's stylesheet?
7. You notice a React component re-renders continuously during a drag interaction. How do you diagnose and fix this?
8. Describe how you would implement undo/redo functionality in a step-builder tool where each step has nested configuration options.
9. How would you write automated tests for a component that conditionally shows a tooltip based on a user's scroll position?
10. Tell me about a time you improved the performance of a frontend feature. What metrics did you measure before and after?
11. How do you keep a large React codebase maintainable as features and team size grow?
12. Whatfix supports enterprise environments with strict CSP policies. How would you adapt a dynamic script injection approach to work under a tight Content-Security-Policy?

Q: You notice a React component re-renders continuously during a drag interaction. How do you diagnose and fix this?

*Situation:* At my previous company we had a drag-and-drop canvas where users repositioned elements. After shipping it, the product felt sluggish on mid-range laptops.

*Task:* I needed to find why the canvas was dropping frames and fix it without rewriting the whole feature.

*Action:* I opened React DevTools Profiler and recorded a drag session. I found that every mousemove event was updating state in a parent component, causing all child elements to re-render. I moved the drag position into a useRef so there were no re-renders during the drag, and only committed the final position to state on mouseup. I also wrapped stable child components with React.memo and extracted the event handler with useCallback so its reference stayed stable between renders.

*Result:* Re-renders during drag dropped to zero. The interaction felt instant, and our Lighthouse performance score improved noticeably. The fix took one afternoon and touched very few lines of code.

---

Q: How would you design a JavaScript SDK that does not pollute the host page's global namespace or CSS?

*Situation:* I worked on a third-party widget that needed to render UI on top of customer websites, similar to what Whatfix does.

*Task:* The challenge was that we had no control over the host page, so we could not predict what global variables or styles already existed.

*Action:* I wrapped all our code in an IIFE so nothing leaked to the window object. For styles, I used shadow DOM to create an encapsulated root, which meant host-page CSS could not bleed in and our CSS could not bleed out. I prefixed every custom event name with our product namespace and exposed a single, minimal public API on one branded window property.

*Result:* We had zero CSS conflicts reported after the redesign. Integration time for new customers dropped because they no longer had to audit their own styles for conflicts.

---

Q: Tell me about a time you improved the performance of a frontend feature.

*Situation:* Our analytics dashboard rendered a table with a very large number of rows loaded all at once. Users complained it froze on load.

*Task:* I was asked to make the table feel responsive without a full backend pagination redesign, as that would take several weeks.

*Action:* I introduced virtual scrolling using a library the team had already approved. Only the rows visible in the viewport, plus a small buffer, were rendered in the DOM at any time. I also added lazy loading for cell content that required a secondary API call, deferring those fetches until the row scrolled into view.

*Result:* Initial render time dropped dramatically on the same data set. Users stopped filing performance tickets for this page, and the product team was able to enable the feature for larger accounts that had previously been blocked.

STAR for behavioural and past-project questions
Structure every story as: Situation (brief context), Task (what you were responsible for), Action (specifically what you did, not what the team did), Result (measurable outcome). Keep Situation and Task short. Spend most of your time on Action and Result.

Think-aloud for live coding and system design
Whatfix interviewers typically value your reasoning process as much as the final answer. Before writing code, state your assumptions, name the edge cases you see, and explain which approach you are picking and why. If you get stuck, narrate what you are thinking rather than going silent.

Trade-off framing for architecture questions
For questions like 'shadow DOM vs iframe', do not just pick one. Briefly state what each option optimises for, then say which you would choose given the constraints in the question. Interviewers want to see that you understand context matters.

Numbers-first for performance questions
Any performance story lands better when you can say what you measured before and after, even if the numbers are approximate. If you do not have exact figures, say 'we estimated' or 'Lighthouse reported' rather than inventing precise numbers.

Whatfix's product lives inside other people's web apps, which means their frontend engineers need skills that go beyond standard React development. Based on what candidates typically report, here is what the interview team looks for.

Deep JavaScript, not just framework knowledge. Questions on closures, prototypes, the event loop, and DOM APIs come up frequently. Knowing React is table stakes. Knowing why React works the way it does separates strong candidates.

Isolation and encapsulation instincts. Because Whatfix runs inside third-party environments, interviewers pay close attention to whether you naturally think about namespace collisions, CSS leakage, and CSP restrictions. Candidates who have built browser extensions, embeddable widgets, or iframes have a head start.

Performance as a habit, not an afterthought. Expect at least one question or exercise where performance matters. Know your profiling tools and be ready to talk about specific numbers from your own past work.

Product curiosity. Several candidates report a round where the interviewer asks how you would improve the Whatfix product itself. Spend some time using the free trial before your interview so you can speak concretely.

Clear communication. Whatfix works with enterprise customers across time zones, and the engineering culture places value on written and verbal clarity. Practice explaining technical decisions in plain terms.

Week 1: JavaScript and browser fundamentals
Review the event loop, microtask queue, closures, prototype chain, and how the browser renders a page (layout, paint, composite). Write small code snippets from memory to test yourself. Study how shadow DOM works and when you would choose it over an iframe.

Week 2: React internals and performance
Read through the React reconciliation docs. Practice identifying unnecessary re-renders using DevTools Profiler. Build a small component that uses useCallback, useMemo, and React.memo correctly, and be ready to explain exactly why each one is there.

Week 3: System design and product prep
Practice designing a third-party widget SDK from scratch: how would you inject it, style it safely, and make it configurable? Use the Whatfix product for a focused session and note one or two features you would improve. Be ready to discuss your ideas clearly.

Week 4: Mock interviews and behavioural stories
Do at least two timed mock coding sessions. Prepare three STAR stories: one about performance improvement, one about a technically difficult problem, and one about working across teams or handling disagreement. Practice saying them out loud, not just writing them.

While you prepare, knok checks 150+ job sites nightly, applies to Frontend Engineer roles that match your resume, and messages HR directly on your behalf, so opportunities at companies like Whatfix keep moving even when you are heads-down studying.

Knowing React without knowing JavaScript. Candidates who can use hooks but cannot explain closures or the event loop typically struggle in Whatfix's technical rounds. The team builds low-level browser tooling, so fundamentals matter.

Giving vague performance answers. Saying 'I optimised it and it got faster' is not enough. Practice attaching real or estimated metrics to every performance story. If you do not have numbers, explain how you would have measured the improvement.

Ignoring the third-party context. Generic answers to questions about CSS or JavaScript that do not account for unknown host environments signal that you have not thought about what Whatfix's product actually does. Always bring isolation and safety into your answer.

Not asking clarifying questions in design rounds. Jumping straight into a solution without confirming constraints leaves the interviewer unsure whether you understand the problem. Two or three clarifying questions also buy you useful thinking time.

Underestimating behavioural rounds. Candidates report that culture-fit and communication rounds carry real weight at Whatfix. Prepare specific stories. Vague answers like 'I am a team player' do not land well.

Skipping the product demo. Not trying the Whatfix product before the interview is a missed opportunity. Interviewers notice when candidates can speak concretely about the product versus those who give generic answers.