Behavioral Interview

The interviewer checks whether you can give a short, relevant summary and why you fit this role. Answer in one to two minutes: present (your role, stack and current work), past (how you got here, one result), future (why this role is your next step). Tailor it: lead with what the vacancy asks for; skip school, hobbies and the full CV One result with a number: a faster cold start, a crash rate you cut Red flags: retelling the CV job by job, a five-minute monologue, nothing about what you want next Example Present: "Frontend developer, three years in React and TypeScript. I own the tables and filters of a B2B analytics dashboard." Past: "I started with layout work, then helped move the dashboard from Create React App to Vite." Future: "I want to grow in performance and design systems, which this role is about."

The interviewer checks your motivation and whether you would leave them for the same reason. Give one honest reason framed as moving toward something (harder problems, a bigger product, a stronger team), then name two specific things that draw you to this company. Toward, not away: "I've outgrown my tasks" or "I want more scale", never "my manager is useless" Specific about them: their product, stack, a blog post or a talk; "a great company" says nothing A layoff or a short job: say it plainly in one sentence and move on Red flags: badmouthing your employer, "only the money", knowing nothing about them Example "I've built our dashboard almost alone for two years, and I miss a team to learn from. You have a design system team and a strong frontend platform, and that's where I want to grow."

The interviewer checks the scale of what you have built and what you personally did in the team. Use STAR: the situation and its problem, your task, the actions you took and why, and a measurable result. "I" for your part: "we" only for the team's work; you are scored on what you did One decision in depth: expect "why that and not X?" A number for the result: crash-free users, load time, conversion, tickets Red flags: technologies with no problem behind them, an architecture you cannot explain, the team's success as yours Example Situation: operations staff worked in a 10,000-row table that froze on every filter change Task: I rebuilt the table Action: virtualised rows, filtering on the server, filter state in the URL so links could be shared Result: filtering takes under 200 ms, and two other teams now use the component

The interviewer checks self-awareness and honesty. Name two or three strengths that fit the role, each backed by a fact, and one real weakness that does not block the job, together with what you already do about it. Strengths with proof: a fact from your work, not adjectives like "responsible" A real weakness: speaking up in big meetings, asking for help late, little experience in an area the role does not centre on What you do about it: a habit that already works, so the answer ends on progress Red flags: "I have no weaknesses", a disguised boast ("I'm a perfectionist") Example Strength: "Accessibility. I catch keyboard and screen reader problems before QA does." Weakness: "I knew little about the backend. I've been writing small Node services and now review our BFF code."

The recruiter checks whether you fit the budget and know your market value. Name a researched range for your level and market, say whether it is gross or net, per month or per year, and add that the figure depends on the whole offer. Research first: surveys, similar vacancies, peers who changed jobs A real floor: offers land near the bottom, so name a number you accept Know the convention: gross per year internationally; net per month («на руки») in Russian-speaking markets Ask their range: normal here, and a growing number of employers must state it up front Red flags: "whatever you offer", a number from thin air, volunteering your current salary Example International: "For middle frontend roles I'm looking at X to Y gross a year. What's your range?" Russian-speaking market: "I'm looking at X to Y a month after tax. What's your range?"

The interviewer checks your interest and what matters to you; "no questions" reads as indifference. Prepare three or four questions about the work itself (the team, how they ship, what success in this role looks like) and pick those that fit the person in front of you. The work: "What would I do in the first three months?", "Who reviews code, and how big is the team?" How they ship: release cadence, testing, on-call, tech debt and who decides about it Success: "How will you know after six months that I'm doing well?" Match the person: process for the team lead, product plans for the manager, conditions for the recruiter Red flags: no questions, asking about holidays in a technical round Example "Is it Next.js or a single-page app, and how is it deployed?" "Who owns the design system, and how do teams contribute to it?"

The interviewer checks how you debug: how you narrow a problem down, which tools you use and whether you fix the cause or the symptom. Tell it as STAR, with most of the time on the actions: your hypotheses, how you tested them, and what stops the bug from returning. Why it was hard: only on some devices, only under load, no stack trace; say it first The search, step by step: crash reports and logs, a profiler, a minimal reproduction, git bisect, the false leads you ruled out The root cause in one sentence: so the interviewer can follow it Prevention: a test, an alert or a lint rule added afterwards Red flags: a trivial typo, "I don't remember", a bug a colleague found, a fix you cannot explain Example Situation: after product pages moved to server rendering in Next.js, Sentry filled with hydration errors and delivery dates flickered Task: I took it Action: only users outside the server's time zone were affected: the date was formatted with toLocaleDateString() on the server and in the browser, so the HTML differed. I moved it into one helper with a fixed locale and timeZone, so both sides render the same text Result: the errors disappeared, and end-to-end tests now run in a time zone different from the server's

The interviewer checks whether you measure performance instead of guessing, and whether you prevent the next regression, not just fix this one. Tell it with STAR: how it surfaced, how you found the cause with the profiler, the fix, and the guard you added. Where it showed up: real-user Core Web Vitals, a Lighthouse CI budget, a user complaint Measure the cause: the React Profiler for renders, the Performance panel for long tasks, a bundle analyser for size Fix the cause: a context that re-renders everything, a heavy library in the main bundle, an unvirtualised list Guard against the next one: a bundle size limit or a performance budget in CI, an alert on the field metric Red flags: wrapping everything in useMemo without measuring, "it's fast on my MacBook", no numbers before and after Example "After a release, INP on our search page went from about 150 ms to over 400 ms in real-user data. The React Profiler showed every keystroke re-rendering the whole page: a new filter value had been added to a context at the root. I moved the input state down into the search box and split the context. INP returned to about 150 ms, and we added an INP alert to our monitoring."

The interviewer checks ownership: whether you admit the mistake, limit the damage fast and change the process so it does not happen again. Pick a real mistake with limited impact, tell it with STAR, and spend the last part on what you changed. Own it plainly: "I shipped", not "it got shipped"; no blaming QA or the reviewer who missed it Damage control first: who you told and how fast, the rollback or hotfix, how many users were hit Fix the system: a test, a CI check, a review rule or an alert; "I'll be more careful" is not a fix Red flags: "I don't make mistakes", a story where it was someone else's fault, a disaster with no lesson, a tiny typo chosen to look safe Example "After a deploy, some users got a blank page with ChunkLoadError. The CDN cached index.html for a day, so returning visitors loaded old HTML pointing at JavaScript chunks we had just deleted. I rolled back, purged the CDN and set index.html to Cache-Control: no-cache, while hashed assets stay immutable. We now keep the previous release's assets for a week and show a reload prompt when a chunk fails to load."

The interviewer checks whether you can disagree without damaging the working relationship. Pick a real work disagreement, often a technical one or a code review, and show how you moved it from opinions to shared criteria, what was decided and how you worked together afterwards. Talk early and directly: move a long comment thread to a short call or a one-to-one Understand their side first: restate their position fairly before arguing yours Agree on criteria, then decide: numbers, team conventions, a quick prototype; if you still disagree, the decision's owner decides and you commit Losing is fine: a story where you accepted the other approach shows maturity Red flags: "I've never had a conflict", the colleague as a villain, going to the manager first, winning at the cost of the relationship Example "I wanted Tailwind for a new section of the app; a colleague preferred CSS Modules, which we already used. We built the same page both ways and asked the team. CSS Modules won on consistency, so I committed to it and helped write the shared tokens file. Losing that vote cost nothing; dragging it out would have."

The interviewer checks whether you plan realistically and raise a risk as soon as you see it, not on the deadline day. Explain how you break work down and estimate, then tell a story where you saw a slip coming, told people early and offered options. Break it down: pieces of half a day to two days, including tests, review, QA and release, which people forget Unknowns separately: a time-boxed spike for anything new to you; give a range, not one number Compare with the past: how long similar tasks really took When it slips: tell the lead or PM the day you know, with options: cut scope, move the date, add help; never quietly work nights and hope Red flags: "I'm never late", an estimate with no breakdown, announcing the slip on release day Example "A campaign landing page had a fixed date. On day two the animated hero broke in Safari and ate a day of debugging. I told the PM right away and offered a static hero for the launch with the animation a week later. We launched on time, and the animation shipped the next sprint."

The interviewer checks whether you think about the product and push back with arguments instead of silently building or refusing. Show that you asked about the goal, brought evidence of the cost, offered an alternative that reaches the same goal and accepted the final decision. Ask about the goal first: the requirement is often one way to reach it, and a cheaper way exists Bring evidence: a recording on a real device, a measurement, a platform guideline, an estimate for each option Offer an alternative: "Not X by Friday, but Y gives you most of it" Respect the decision: once the product owner decides with the trade-offs on the table, you build it well Red flags: "I just do what I'm told", refusing with no alternative, going over the PM's head Example "The designer wanted infinite scroll on search results. I pointed out that the back button would lose the position, the footer would be unreachable and search engines would see only the first page. I proposed a 'Load more' button with the page number in the URL. We tested both with five users, and the button won."

The interviewer checks whether you can turn a design system into components both sides trust and handle the gap between a mockup and the browser. Describe a shared source of truth, a review loop with designers and a story where you settled a disagreement. Same names on both sides: Figma variables exported as design tokens (CSS custom properties); no raw hex values in components Storybook as the meeting point: designers review the real component in every state, not a screenshot Visual regression tests: Chromatic or Playwright screenshots catch unintended changes in review A rule for one-offs: a new variant goes into the library, or the design changes; no copies in feature folders Browser reality: keyboard focus, screen readers, long translated text, zoom and narrow screens, which mockups rarely show Red flags: "I build exactly what's in Figma", or the opposite, changing the design without asking Example "Designers had drawn focus states for only half the components, so keyboard users could not see where they were. I collected the gaps on one Storybook page and showed it at our weekly sync. We agreed on one focus ring token, I applied it across the library, and focus states became part of our component checklist."

The interviewer checks whether you can hear criticism without getting defensive and tell a colleague about a problem without hurting them. Describe how you do both, and back it with one story where feedback changed how you work. Receiving: listen to the end, ask for a concrete example, thank them, and come back later with what you changed Giving: in private, soon after the event, about the behaviour and its effect rather than the person ("this PR had no tests, and the bug reached QA"), with a suggestion In code review: explain why, separate blocking issues from nits, say what is good Red flags: "I never get negative feedback", arguing with every point, feedback only through the manager, harsh public comments Example "A designer told me my components often differed from the mockup by a few pixels, and she had to file bugs for them. I started comparing the component in Storybook with the Figma frame before opening a PR, and those bugs mostly stopped."

The interviewer checks whether you multiply the team's output, not just your own. Tell a concrete story: what the person or the team struggled with, what you did regularly (pairing, review, gradually harder tasks, shared practices) and a result you can point to. Start from their gap: ask and watch what actually blocks them; a generic lecture does not help Teach through real work: pair on a task, then give a similar one to do alone; review with explanations and links instead of rewriting their code Grow independence: tasks a little above their level, and room for small mistakes where they are cheap Scale it to the team: a checklist, a lint rule, a PR template, a short internal talk, written decisions A result: they shipped a feature alone, review rounds fell, onboarding got shorter Red flags: "I just fix their code myself", mentoring as giving orders, no example Example "A junior used useEffect for everything, including derived state, and her pages re-rendered in loops. We paired on her tickets, I pointed her to the React docs page on effects you might not need, and gave her the refactor of one form as a task of her own. Afterwards she ran a short session for the team, and we made the hooks lint rules errors instead of warnings."

The interviewer checks whether you speak the business's language and prioritise, instead of asking for a rewrite. Translate the debt into a cost the business already feels (slower features, incidents, lost users), propose a small, measurable plan and report the result. Measure the pain: time to ship a typical feature, bugs per release in that area, incidents, build time multiplied by the team Prioritise by cost: debt in code that changes often matters; old stable code can stay ugly Small and continuous: a fixed share of each sprint, or the cleanup bundled with the next feature in that area, not a three-month freeze Report the effect: numbers before and after make the next request easier Red flags: "the code is ugly" as the argument, asking for a full rewrite, hiding the work inside feature estimates Example "Half of our codebase was typed as any. Sentry showed that most of our frontend errors were property access on undefined, which types would have caught. I proposed turning on strict folder by folder with a separate tsconfig, starting with checkout and enforced in CI for new code. Checkout errors fell by about two thirds in two months."

The interviewer checks whether you can lead a long change across the team and the business, not just run a codemod. Show the business reason, the incremental plan, how features kept shipping, how you brought people along and the result in numbers. A reason the business accepts: slow builds and dev server, a deprecated tool (Create React App is deprecated), a feature you cannot build otherwise Incremental by design: Pages and App Router routes can live in one Next.js app; a new build setup can run in CI next to the old one before it replaces it Keep shipping: no feature freeze; a route or package moves when a feature touches it, with a deadline for the rest Bring people along: a pilot, a written guide, codemods where they exist, pairing, one owner for questions Measure: build time, dev server start, bundle size and Core Web Vitals before and after Red flags: a big-bang branch that lives for months, migrating because the new thing is fashionable, no rollback plan Example "Our CRA dev server took 40 seconds to start, and hot reload took several seconds. I timed it, multiplied by the team and got a sprint for a Vite pilot. I moved the app in a branch that lived one sprint and was rebased daily, renamed the environment variables from REACT_APP_ to VITE_ with a script, and wrote a one-page guide. The dev server now starts in about 2 seconds, production builds went from 6 minutes to under 1, and feature work never stopped."