HR & Behavioural Frontend Development Interview Questions

Situation: a junior developer kept writing bugs with async code. Task: I wanted them to understand promises rather than copy fixes. Action: I drew the event loop on a whiteboard, wrote three small console examples for them to predict, and then reviewed one of their real pull requests together. Result: within two weeks, their async bugs stopped and they started explaining the concept to the next new joiner.

I like work where users see the result directly. In college I built a timetable app for my class, and watching classmates use it daily taught me how small UI details matter. Frontend combines logic, design and performance, and the ecosystem keeps evolving, which keeps me learning. I want to build fast, accessible interfaces for products used by millions of people across India.

Situation: our JavaScript app kept breaking after API changes. Task: I believed TypeScript would help but the team worried about slowing down. Action: I converted one small module as a pilot, showed three bugs it caught, and proposed gradual adoption with no deadline pressure. Result: the team agreed, we migrated over two quarters, and production errors related to wrong data shapes dropped significantly.

Situation: I joined an internship where the codebase was fully TypeScript, which I had never used. Task: I needed to contribute within the first week. Action: I read the official handbook basics, studied existing types in the project, and converted small JavaScript exercises into TypeScript each evening. Result: I submitted my first typed component on day five and became comfortable with generics within a month.

Situation: during my internship, the team wanted product images to load only when visible. Task: I was asked to implement it without adding a library. Action: I studied IntersectionObserver on MDN, built a small prototype, measured the page in Lighthouse and then applied it to the listing page with a fallback. Result: initial page weight dropped by about 60 percent, and the pattern was reused on other pages.

Situation: a product manager asked for 'offline support' in our web app without details. Task: I needed clarity before estimating. Action: I listed specific questions, which screens, read-only or editing, how long offline, and shared a quick prototype showing two options with effort estimates. Result: we agreed on read-only offline access for the order history, which shipped in one sprint instead of an open-ended project.

Situation: a designer flagged small spacing differences between Figma and my build on several phones. Task: I needed to address concerns while keeping the layout fluid. Action: I fixed genuine mistakes immediately, then showed how fixed pixel values would break on other screens and proposed shared spacing tokens. Result: we agreed on tokens and breakpoints, and future handoffs had far fewer revision rounds.

Situation: a senior engineer rejected my pull request for a new dashboard because the CSS was hard to maintain. Task: I had to rework it without missing the sprint. Action: I asked for a short call to understand the concerns, refactored styles into reusable components with tokens, and added notes explaining my choices. Result: the PR was approved, and the components were later reused in two other screens.

Situation: our product team kept postponing performance fixes for new features. Task: I needed to show the business value. Action: I correlated our real user data with conversion and found that sessions with LCP above 4 seconds converted at about half the rate. I proposed a two-sprint plan with clear targets. Result: leadership approved it, LCP improved by 40 percent and checkout conversion rose measurably.

Situation: a Lighthouse and field data audit of our app listed many issues. Task: I had one sprint to show improvement. Action: I ranked issues by user impact and effort, focusing first on the LCP image, render-blocking CSS and one oversized library on the most visited pages. Result: these three fixes delivered most of the gain, and I scheduled the remaining smaller items into later sprints.

Situation: in my internship, we resized and compressed product images manually before every upload. Task: I wanted to save the team time. Action: I wrote a small Node script using Sharp that converted images to WebP in three sizes and added it as an npm script. Result: a task that took an hour per batch became a one-minute command, and image sizes dropped by more than half.

Situation: half the team wanted a heavy state management library for a new app, while I felt it was unnecessary. Task: we needed a decision quickly. Action: I suggested building the same feature both ways in a time-boxed spike and compared code size, learning curve and bundle impact. Result: the data favoured the simpler approach, the team agreed, and we documented criteria for when to add the library later.

Situation: near a release deadline, a teammate suggested skipping tests for a new checkout coupon feature. Task: I felt the risk to payments was too high. Action: I proposed covering only the critical paths, valid, expired and invalid coupons, and wrote those tests myself in two hours. Result: one test caught a discount rounding bug before release, and the feature shipped on time.

Situation: a form validation change I made blocked some users from signing up with valid numbers. Task: I needed to fix it and be transparent. Action: I informed my lead immediately, rolled back the change, found that my regex rejected numbers with a +91 prefix, fixed it, and added tests for different formats. Result: signups recovered within an hour, and I now test with real-world data samples.

I treat QA as partners rather than gatekeepers. I share feature details and edge cases early, give them testable builds on staging, and add stable test ids or accessible labels that help automation. When bugs come in, I ask for clear steps and environment details instead of arguing. In my last project, this collaboration cut bug reopen rates because we agreed on acceptance criteria before development.

Situation: my team had almost no automated tests and frequent regressions. Task: as tech lead, I wanted testing to become a habit, not a mandate. Action: I set up Vitest and Playwright with examples, ran two short workshops, required tests only for bug fixes at first, and celebrated bugs caught in CI. Result: within six months, most pull requests included tests and production regressions dropped significantly.

Situation: our app's single global store had grown to thousands of lines and slowed every feature. Task: as frontend lead, I had to propose a better structure without stopping delivery. Action: I wrote a short design document comparing options, moved server data to a query cache module by module, and set guidelines for local state. Result: the store shrank by 70 percent and new features took noticeably less time.

I break the feature into small parts: components, states such as loading, empty and error, API integration, responsive behaviour, accessibility and tests. I estimate each part, add time for reviews and unknowns, and flag dependencies like pending designs or APIs. For example, a filter panel I estimated at five days was delivered in five because I had listed edge cases upfront instead of discovering them late.

In five years, I want to be a senior frontend engineer who owns complex features end to end and helps shape architecture decisions. I plan to deepen my skills in performance, accessibility and TypeScript, and contribute to a design system. I also want to mentor juniors, because teaching others is how I learned best. I hope to grow within a team where I can take on that responsibility.

Situation: our team constantly added features while an outdated build setup slowed everyone. Task: I needed time for cleanup without stalling the roadmap. Action: I quantified the cost, about 30 minutes lost per developer daily, and proposed reserving roughly 15 percent of each sprint for debt, starting with the biggest pain points. Result: the product manager agreed, build times halved, and feature delivery actually sped up.