Walk me through your typical frontend development workflow.

My workflow starts with understanding the requirements and any design specs before writing a single line of code. I break the UI into components early, thinking about which pieces hold state and which are purely presentational. I use TypeScript throughout, so type definitions come before implementation. For version control I work in short-lived feature branches, keep commits small and focused, and open pull requests for review before merging. I run the component in isolation using Storybook where the team uses it, write unit tests with Jest and React Testing Library as I build, and do a manual cross-browser check before marking something as ready. Code review is something I take seriously on both sides: I aim to leave comments that explain the why, not just flag problems.

How do you approach debugging a complex UI issue that only appears in certain browsers?

I start by reproducing the issue reliably, noting exactly which browsers and versions are affected. Once I can reproduce it consistently, I use the browser's DevTools to inspect the DOM, check for CSS differences, and look at the console for errors. I isolate the failing component and strip it back to a minimal reproduction to rule out interactions with other code. For CSS bugs I check for properties with known compatibility gaps using MDN or Can I Use. For JavaScript issues I look for browser-specific APIs or event behaviour differences. I also check whether any polyfills are missing in the build config. Once I have identified the root cause, I fix it in a way that does not regress other browsers, then add a cross-browser test case to prevent recurrence.

How do you handle code reviews, both giving and receiving feedback?

When reviewing someone else's code I focus on correctness, maintainability, and performance rather than style preferences, which should be handled by a linter. I try to ask questions rather than make demands: "Have you considered X approach because of Y?" lands better than a blunt rejection. I always acknowledge what is working well before raising concerns. When receiving feedback I treat it as information rather than criticism. If I disagree with a comment I explain my reasoning once clearly and then defer to the reviewer or escalate to the team if it is genuinely unclear. I avoid arguing in the thread for the sake of it. The goal is to ship better code, not to be right. I also act on patterns I see repeatedly in my own reviews and adjust my approach before the next PR.

Tell me about a time you had to debug a performance problem in a frontend application.

We had a React dashboard that was taking over four seconds to become interactive on mid-range devices. I started by profiling it in Chrome DevTools, which showed a large bundle size and a component tree that was re-rendering far more than necessary. The bundle analysis revealed we were importing an entire charting library for two chart types. I replaced it with a lighter alternative and used dynamic imports to split the charts into a separate chunk. For the re-renders I used React.memo and moved expensive calculations into useMemo with correct dependency arrays. After those changes the initial load dropped to under 1.5 seconds and the Largest Contentful Paint improved by 60%. I documented the findings in the team wiki so the patterns were reused on other parts of the product.

Describe how you work with designers to implement a UI feature.

I try to get involved before the designs are finalised rather than receiving a completed spec to implement. Early involvement lets me flag technical constraints: for example, if an animation looks beautiful in Figma but would require a layout property that forces a full repaint on every frame, it is easier to adjust the design than to fight the browser later. During implementation I check in early with a rough build rather than waiting until I think it is perfect, because designers often spot things in the browser that they did not notice in the static mockup. I also ask about interaction states upfront: hover, focus, loading, error, and empty states are easy to miss in designs. When the finished work diverges from the spec for a legitimate technical reason, I explain why in writing so the designer understands the decision and can account for it in future work.

How do you stay current with the frontend ecosystem without getting distracted by every new framework?

I separate signal from noise by focusing on browser standards and specifications first. New APIs like View Transitions or the Popover API represent real platform capability rather than framework opinion, so I prioritise understanding those. For frameworks, I follow release notes and RFCs for the tools I already use rather than chasing every new announcement. I keep a short reading list of trusted sources: MDN updates, the TC39 proposals repo, and a few engineers whose thinking I respect. When a new tool gains significant adoption I spend a few hours building something small with it to form my own view rather than relying on the hype cycle. I have declined to adopt several hyped tools that turned out not to fit our team's needs. Being selective about what you learn is as important as learning itself.

Give me an example of a time you had to balance shipping quickly against maintaining code quality.

During a product launch we had a three-day window to build a feature that would normally take a week. I had a direct conversation with the team about what we were trading: we agreed to skip unit tests for the new components, use a simpler state approach that we knew would need refactoring later, and defer accessibility improvements beyond keyboard navigation. I created a technical debt ticket immediately with the specific items we deferred and estimated the cleanup cost so it did not get forgotten. We shipped on time. Two weeks after launch I picked up the debt ticket and completed the refactor, including full test coverage and ARIA improvements. The key for me is making the trade-off explicit and tracked, not invisible. Invisible shortcuts are what create unmaintainable codebases.

Explain how you would optimise a page for Core Web Vitals.

I start by measuring the current state with Lighthouse and the Chrome User Experience Report to understand which metrics are failing in real user sessions, not just in lab conditions. For Largest Contentful Paint I look at whether the hero image or heading is being loaded with the right priority: it should have fetchpriority="high" and not be lazy-loaded. For fonts I use font-display: swap and preload the critical subset. For Cumulative Layout Shift I audit any element whose size is determined by content loaded after the initial render, including images without explicit dimensions and dynamically injected banners. For Interaction to Next Paint I profile JavaScript execution on slow devices and look for long tasks to split with scheduler.yield or move to a web worker. I also check for render-blocking scripts and stylesheets that can be deferred.

How do you approach accessibility in a frontend project?

Accessibility is something I build in from the start rather than audit at the end. I use semantic HTML as the foundation: a well-structured document with correct heading hierarchy, landmark regions, and native form elements handles a large proportion of accessibility requirements without any ARIA. When I do use ARIA I follow the first rule: do not use ARIA if a native element can do the job. For interactive components I check that all functionality is reachable by keyboard, that focus is managed correctly when modals or dynamic content appears, and that visible focus indicators meet WCAG contrast requirements. I test with a screen reader, primarily VoiceOver on Mac and NVDA on Windows, at least once per feature. I also run automated checks with axe-core as part of the test suite to catch regressions. Automated tools catch roughly 30 to 40% of issues, so manual testing is not optional.

How do you structure component architecture in a large React application?

I think about components in terms of their responsibility. Presentational components receive props and render UI, with no knowledge of where the data comes from. Container components handle data fetching and state management and pass data down. Shared UI primitives live in a design system folder and are kept generic. Feature-specific components live alongside the feature they belong to, not in a shared folder, because co-location makes it easier to understand scope and delete code safely. For state I keep it as close to where it is used as possible: local state first, then context for cross-component state, then a global store only when truly needed. I also think carefully about the API surface of each component, keeping props minimal and avoiding prop drilling past two levels by using composition patterns instead. A large application that is easy to navigate is the result of consistent decisions about where each kind of logic lives.

Frontend Developer Interview Questions

Frontend Developer

Frontend Developer interviews test your command of JavaScript and TypeScript, your ability to build accessible and performant user interfaces, and how you think about component architecture and testing. Interviewers want concrete examples of how you have solved real problems, not textbook definitions. This guide covers the questions you are most likely to face and the answers that demonstrate genuine expertise.

Behavioural Interview Questions for Frontend Developer Roles

What Hiring Managers Look for in Frontend Developer Interviews

What hiring managers really look for in Frontend Developer candidates:

Problem-solving process, not just solutions. Walk through your debugging and decision-making step by step. Candidates who can articulate their reasoning stand out from those who just name the right answer.
Performance and accessibility awareness. These are not extras. Interviewers at product companies expect you to consider Core Web Vitals, WCAG compliance, and bundle size as part of everyday work.
Collaboration with designers and other engineers. Frontend development sits at the intersection of design and engineering. Show you can work fluently across that boundary without friction.
Pragmatism about tooling. The ability to evaluate a new framework critically and decide not to adopt it is more valuable than enthusiasm for every new release.
Evidence that you write tests. Candidates who treat testing as an afterthought rarely make it past a senior engineering panel.

Questions to Ask Your Interviewer

→What does the frontend tech stack look like today, and are there any migrations or modernisation efforts planned?

→How does the team approach performance budgets and Core Web Vitals in practice?

→How are frontend and design decisions made: is there a design system, and who owns it?

→What does the testing culture look like here, and what coverage do you aim for?

→What is the biggest frontend challenge the team is working through right now?

Frontend Developer

Common Frontend Developer Interview Questions

Behavioural Interview Questions for Frontend Developer Roles

Technical Questions for Frontend Developer Candidates

What Hiring Managers Look for in Frontend Developer Interviews

Questions to Ask Your Interviewer

Practise These Questions Before Your Interview

Related Roles