Question 1
Difficulty: easy
Can you walk me through how you would build a responsive landing page from a Figma design?
Sample answer
I’d start by reviewing the layout, spacing, typography, and interactive states in Figma so I can spot anything that might affect implementation early. Then I’d break the page into reusable components, like header, hero section, feature cards, and footer, instead of coding it as one large page. I usually build mobile-first with semantic HTML and CSS, then expand styles with media queries or a responsive layout system like Flexbox and Grid. I also pay attention to accessibility from the beginning, such as color contrast, keyboard focus states, and proper heading structure. Once the structure is in place, I’d add any required interactivity, test in multiple browsers and screen sizes, and compare the result against the design. If something doesn’t translate well, I’d communicate that clearly and suggest a practical alternative rather than forcing a brittle solution.
Question 2
Difficulty: medium
How do you make sure your frontend code stays maintainable as a project grows?
Sample answer
I keep maintainability in mind by organizing code around reusable, clearly defined components and by avoiding overly complex logic inside the UI layer. I try to separate concerns so presentational components stay focused on rendering, while data fetching, state management, and side effects live in a cleaner structure. Naming is important too; I prefer consistent conventions that make it easy for someone else to understand the purpose of a file or component without opening it first. I also like to write code that anticipates change, because frontend requirements shift often. That means using scalable styling patterns, keeping props predictable, and documenting any tricky behavior. On larger projects, I rely on reviews, linting, and testing to prevent drift. Most importantly, I refactor incrementally instead of waiting for code to become messy, because small improvements over time are much easier to manage than a major cleanup later.
Question 3
Difficulty: medium
Describe a time when you had to debug a tricky UI issue that only appeared in production.
Sample answer
In one project, a modal worked perfectly in development but broke for a subset of users in production. The issue only happened on smaller screens and under a specific sequence of actions, so it took some digging to reproduce it. I started by narrowing down the problem with browser dev tools and logging around the state changes that controlled the modal. Eventually, I found that a scroll-lock fix was interfering with focus handling, which caused the modal to close unexpectedly on some devices. I patched the issue, but I also took a step back and added more robust tests around the interaction so we wouldn’t repeat the same mistake. What I learned from that experience is that production bugs often come from edge cases that local testing misses, so I now make a point of testing across device sizes, browsers, and interaction patterns before shipping anything user-facing.
Question 4
Difficulty: hard
How do you ensure a frontend application is accessible to users with different abilities?
Sample answer
I treat accessibility as part of the core product, not as an extra layer to add later. My first step is using semantic HTML correctly, because that gives assistive technologies a reliable structure to work with. I make sure interactive elements are keyboard accessible, focus states are visible, and labels are clear and associated properly with form controls. For custom components, I’m careful to replicate native behavior as closely as possible, including ARIA attributes when they’re truly needed. I also check color contrast, text scaling, and how the interface behaves with screen readers. Beyond the technical side, I like to test with actual keyboard navigation and accessibility tools during development rather than waiting until the end. If I find something that creates friction, I try to fix it immediately and explain why it matters, because accessible design usually improves the experience for everyone, not just users with disabilities.
Question 5
Difficulty: medium
How do you handle working with backend engineers when an API doesn’t provide exactly what the UI needs?
Sample answer
I try to approach that as a collaboration problem, not a complaint. First I confirm whether the UI truly needs a new field or endpoint, or whether I can reshape the data on the frontend without creating unnecessary complexity. If the gap is still real, I explain the user impact clearly, with a simple example of how the missing data affects the experience. I’ve found that backend teams respond best when the request is tied to behavior, not just a technical preference. At the same time, I’m willing to compromise if the change would slow the project too much. Sometimes a temporary frontend workaround is the right move, especially if the release is urgent. What matters most is keeping communication respectful and practical. Strong frontend work depends on strong cross-functional communication, and I’ve learned that the best solutions usually come from proposing options rather than pushing for one rigid answer.
Question 6
Difficulty: hard
What is your approach to state management in a React application?
Sample answer
My approach depends on the scope of the state. I separate local UI state, shared component state, and server state instead of forcing everything into one solution. For example, a dropdown open state or input value usually belongs close to the component that uses it, while data that needs to persist across multiple areas may need context or a more structured store. For server state, I prefer tools or patterns that handle caching, loading, and synchronization well, because that reduces boilerplate and avoids reinventing the wheel. I also try not to overengineer. A common mistake is introducing a global state solution too early when simple prop passing would be cleaner. I think the best state management is the one that keeps the app predictable, easy to debug, and simple for the team to extend. I always ask whether the state really needs to be global before I promote it.
Question 7
Difficulty: medium
Tell me about a time you improved the performance of a slow frontend feature.
Sample answer
I worked on a dashboard where the initial page load felt sluggish, especially on lower-end devices. I started by measuring rather than guessing, using performance tools to see where time was actually being spent. The biggest issue turned out to be a large table rendering too many rows at once, plus a couple of heavy components loading immediately even when they were below the fold. I broke the table into smaller pieces, introduced virtualization for long lists, and deferred non-essential sections until they were needed. I also optimized some asset loading and removed a few unnecessary re-renders caused by prop changes. After those changes, the page became noticeably faster and much smoother during interaction. What I liked about that work was that it wasn’t just about making a page faster in theory; it improved the real user experience. I now treat performance as something to design for early, not a polish step at the end.
Question 8
Difficulty: medium
How do you decide whether to use CSS, a utility framework, or a component library for a project?
Sample answer
I decide based on team needs, product complexity, and long-term maintainability. If a project needs a fast start with consistent UI patterns, a component library can save time and reduce design drift. If the team wants tight control over design and there are many unique interfaces, I may prefer a more tailored CSS approach or a utility framework. I’m not loyal to one tool for its own sake; I care about whether it helps the team move quickly without creating future headaches. I also consider how much customization is needed, how easy it will be to onboard new developers, and whether the styling approach fits the product’s design system. In my experience, the best choice is often the one that balances speed now with flexibility later. I’m comfortable adapting to the stack in place, but I always try to understand why a styling approach was chosen so I can use it effectively rather than fighting it.
Question 9
Difficulty: easy
How do you respond when a designer asks for something that is difficult to implement in the browser?
Sample answer
I try to respond constructively and early. If something is difficult, I first check whether the issue is truly technical or just unfamiliar. Sometimes there’s a straightforward browser-native way to achieve the same result. If it is genuinely hard or risky, I explain the constraint in plain language and offer alternatives that preserve the design intent. I’ve found that most designers appreciate a solution-oriented conversation more than a simple no. For example, if a complex animation would hurt performance or accessibility, I’d suggest a lighter version that still feels polished. I also like to bring in examples or prototypes when possible, because it helps everyone evaluate the trade-offs visually. The key for me is respecting the design goal while protecting usability, performance, and implementation quality. Good frontend work often means translating an idea into something that works reliably in real browsers.
Question 10
Difficulty: medium
Why do you think testing is important in frontend development, and what do you test most often?
Sample answer
Testing matters because frontend code has a lot of moving parts: user input, asynchronous data, browser behavior, and visual state changes all interact in ways that are easy to break. I focus on testing the parts that are most likely to affect users. That usually means component behavior, form validation, conditional rendering, and key workflows like submitting a form or navigating between states. I prefer tests that reflect real user interactions rather than implementation details, because they’re more resilient when the code changes. I also care about visual and cross-browser checks, especially for responsive layouts and interactive components. Not every line needs a test, but important behavior should be protected. In my experience, good testing gives the team confidence to move faster, not slower, because it reduces fear around refactoring. It also helps catch regressions before users do, which is especially valuable in frontend work where small changes can have visible consequences.
