Last week, I had a technical interview with a senior principal engineer at a consulting company, for a React possibly full-stack consulting position. The role involves working closely with client teams particularly in the healthcare space to help build and optimize internal applications.
The interview lasted just under 30 minutes, and I thought I’d share how it went — what I felt good about, what could’ve gone better, and how I plan to level up from here. If you’re in the middle of a job hunt or brushing up on your frontend fundamentals, hopefully this gives you some practical insights.
Setting the Scene
The conversation was casual and focused, kicking off with some intros. The developer mentioned his background — two decades in Java, with 7–8 years specializing in React and React Native.
When it was my turn, I gave a quick rundown: I’ve been a senior full-stack developer at KaizenApps for five years, working mainly with TypeScript, React, Node/Express, and a range of modern tooling. I expressed my appreciation for meaningful software work and asked what the consulting day-to-day looks like — a good way to show curiosity and alignment.
Diving Into the Technicals
Once we jumped into the React-specific portion, here’s how it went:
Why React?
I talked about:
- Component-based architecture for reusability and scalability
- The virtual DOM for efficient UI updates
- Declarative syntax for clarity in complex UIs
- Strong ecosystem and community support
- One-way data flow and the ability to go cross-platform with React Native
In retrospect, I could’ve gone deeper on the virtual DOM diffing algorithm or mentioned the tradeoffs versus frameworks like Vue or Svelte — but I hit most of the big points.
What Makes a Good Component?
I emphasized:
- Single-responsibility and reusability
- A clear API surface using props
- Composability and testability
- Minimal external dependencies (keeping components isolated)
This was one of my stronger answers, and it helped set the stage for the next question: how I’d break down a simple app like a counter with a dynamic title and buttons.
Component Architecture: The Counter Example
I proposed:
- A CounterContainer component to manage state
- A Title component to display the title
- A CounterDisplay to show the number
- Increment/DecrementButton components with handlers passed from the parent
I framed it with a quick anecdote from a past project, which helped show how I think modularly. If I had to tighten it up, I’d clarify the data flow more cleanly up front, then layer in how I’d optimize for reusability later.
State Management: Local vs Global
This part went smoothly. I explained:
- Local state (useState) for component-scoped data like counters
- Global state (Zustand) for shared data like user sessions
I also talked about the pros (centralized data, avoiding prop drilling) and the cons (tight coupling, debugging complexity, risk of overuse). This showed I understand the architectural tradeoffs and when to reach for state libraries.
Async/Await vs Promises
I explained:
- async marks a function that returns a promise
- await pauses execution until the promise resolves
- async/await is syntactic sugar over .then()/.catch() chaining
I mentioned how it improves readability and error handling, and I also owned up to not remembering the JS event loop well enough to explain it in depth (note to self: review that soon).
Debugging a Real Bug
The interviewer asked about a hard bug I solved recently. I shared:
- A stale closure inside an async function that prevented a React component from updating
- How I debugged it using logs, Google, and help from a teammate
- The fix: using a functional state update to ensure I had the latest state in scope
This was a strong moment because I walked through a real issue, my thought process, and how I collaborated to resolve it.
Performance Optimization
I talked about:
- Memoization (useMemo, useCallback, React.memo)
- Minimizing state and breaking large components apart
- Using React DevTools to find bottlenecks
- Virtualization with react-window for large lists
He followed up by asking how useCallback and useMemo help with performance, and I gave a clear answer on preventing unnecessary re-renders and maintaining stable references in child components.
Testing Strategy
I mentioned tools like:
- Jest and React Testing Library for unit/integration tests
- Cypress for E2E
- Enzyme (only for legacy projects)
I covered the types of tests I write: rendering UI correctly, user interactions (like button clicks), props, edge cases, and snapshot testing for regression coverage. In hindsight, I could’ve shared a memorable test case or a tricky UI edge case I had to write coverage for.
Favorite Project
I wrapped up by sharing the Mythical Marketing project, where I was brought in as a founding engineer. I walked through:
- Inheriting and cleaning up a deeply nested legacy codebase
- Building a modern TypeScript + Next.js + MongoDB app from scratch
- Choosing MUI, React Charts, TipTap, and SWR for performance and developer experience
- Solving backend architecture issues on Azure for marketing analytics
It showed not just technical chops, but ownership and an ability to take a messy codebase and ship something production-ready.
What I Did Well
- Clear, well-structured technical answers
- Related everything to real-world experience
- Showed both React fundamentals and architectural thinking
- Was collaborative and conversational (not rigid or overly rehearsed)
Where I Can Improve
- More depth in foundational topics like the event loop, virtual DOM internals, and reconciliation
- Tighter focus in answers — I went on a Swift tangent that wasn’t really relevant
- More polished examples during testing and optimization questions
What’s Next?
If things move forward, the next step is an interview with RBA’s VP of Software Development, followed by a final client interview. I’ll be preparing by:
- Brushing up on JS under-the-hood topics
- Building out a mini React project with clean testing and state management
- Practicing concise, example-driven answers
Thanks for reading! If you’re also prepping for frontend roles, I’d love to hear what kinds of questions you’ve run into — or feel free to share interview strategies that have worked for you.
👉 Drop me a message or connect on LinkedIn