Frontend Engineer

Ability to structure a decision under uncertainty: identifying the conditions (browser support, team skill, existing codebase), explicit trade-offs, consulting the affected people (design, backend, PM), validating afterwards with data (bundle size, Lighthouse, error rate). Bonus: the candidate mentions changing their mind along the way or documenting the decision. Anyone who describes an obvious decision in hindsight rarely weighed it seriously.

A structured debugging method: reproduction in the browser (DevTools, Performance tab, Network tab), identifying the affected devices or browsers, hypotheses validated by experiment. Honesty about duration (a real production frontend bug is rarely done in under 30 minutes, especially with browser incompatibilities). Bonus: the candidate names the root cause and the systemic fix, not just the hotfix. Answers like I built a CSS workaround with no diagnosis point to weak investigative ability.

Technical humility and an ability to learn. Bonus: the candidate names what they would do differently from the start today (e.g. composition over inheritance, hooks extraction, clearer props contracts). Anyone who never really had to refactor their own components either shipped nothing into real production or never evolved the product over time.

Ability to flag a technical weakness without blocking: a factual comment in the PR (here is the risk for keyboard or screen-reader users, here is my suggested fix), an offer to help solve it, escalation to the tech lead if the PR is merged despite the comment. Anyone who lets it slide because the profile is senior, or who treats accessibility as a nice-to-have, shows a lack of technical courage and gaps in frontend understanding.

Clarifying the need before negotiating the timeline (perhaps the critical filter dimensions can ship in one week, the rest in V2). Offering options: an MVP in one week plus V2 in two weeks, an explicit scope cut, a workable UI variant with fewer edge cases. Answers like I can do it in a week if I work the weekend are a warning flag (a signal of poor self-management).

Diagnosis first: no attempt to fix everything at once. Prioritization by risk and impact (typically: first enforce TypeScript in new components and type the critical existing ones, then consolidate the 8-12 most-used components, then a lightweight test setup for the critical flows). Alignment with the team and tech lead before each move. Anyone who dives straight into a full rewrite or immediately declares a Material UI design system shows a lack of pragmatism.

Clarification before proposing (expected row count, data source, server vs. client sorting, accessibility requirements, how many places it is reused). A coherent architecture: composition vs. configuration props, a clear slot or render-prop API, virtualization above which row count, keyboard navigation, ARIA roles for tables. Bonus: acknowledging the zones of uncertainty (I'd build a POC with React Aria or TanStack Table before deciding what to build ourselves). Anyone who jumps straight into code without clarifying shows a design weakness.

A structured method: (1) reproduce on a real device or via BrowserStack, not just the desktop DevTools emulator, (2) profile with Safari Web Inspector over USB debugging, (3) order the hypotheses (a memory leak in a listener binding, excessive re-renders, heavy animations, layout thrashing, large images with no lazy loading), (4) compare metrics (CPU, memory, long tasks, FPS). Anyone who jumps straight to it's probably Safari without investigating has a bias and underestimates iOS-specific quirks (e.g. WebKit memory management).

Measure before optimizing: Lighthouse, WebPageTest, Chrome DevTools Performance tab, RUM data if available. Identify the bottleneck (render-blocking JS or CSS, large unoptimized images, no code splitting, heavy third-party scripts, unused JavaScript, missing caching headers). Prioritize by effort times impact: typically image optimization and code splitting first, then limiting third-party scripts, then server response time. Answers like I add server-side rendering with no diagnosis point to premature optimization. Bonus: recognizing that LCP problems usually sit with images, web fonts or a late hydration step.

Understanding of the frontend test pyramid (many unit tests on hooks and utilities, component tests with Testing Library on behavior rather than implementation, few E2E in Playwright or Cypress on the critical flows). Distinguishing coverage from value (90 % coverage on presentational components weighs less than 60 % on a checkout flow). Bonus: the candidate cites a case where a test prevented a real regression. Anyone who names snapshot tests as their core strategy or simply answers 100 % coverage with no distinction shows weak judgment.

useEffect: runs after commit, asynchronously to the browser paint, suited to data fetching, logging, subscriptions. useLayoutEffect: runs synchronously after commit, before paint, suited to measurements and imperative DOM access that must avoid layout flicker. Prefer a state-driven render when the information can be derived from props or state (no effect needed). Anyone who cannot separate the three mechanisms builds the classic frontend anti-patterns: double renders, flicker, race conditions in effects. Vue equivalent: watchEffect vs. computed vs. lifecycle hooks.

A stepwise approach: (1) map the critical components and recurring patterns, (2) first extract hooks or composables and business logic (high leverage, low risk), (3) split large components along functional boundaries, not technical schemas, (4) introduce a state manager only where props drilling actually hurts (Context or Pinia at an SMB, Redux or Zustand at higher volume), (5) unify the styling strategy without a big-bang migration. Anyone who wants to switch everything to React Server Components or Nuxt 4 right away shows a lack of pragmatism.

Openness: the ability to separate the code from personal ego. Bonus: the candidate cites a case where a review actually made them rethink (e.g. accessibility notes that seemed unimportant at first). Anyone who describes explaining their logic to the reviewer instead of listening shows a coachability weakness; at an SMB with a small frontend team that is a hard knock-out signal.

An active accessibility posture: semantic HTML as standard, keyboard navigation tested, focus order and visible focus checked, ARIA roles only where needed, contrast validated, a screen-reader test at least once per non-trivial component. Bonus: the candidate names a concrete tool (axe, Lighthouse, VoiceOver, NVDA) and a case where an accessibility audit delivered a real usage improvement. Anyone who treats accessibility as an end-of-project task or blanket-delegates it to QA shows a gap that gets expensive at an SMB (lawsuits under the BFSG since mid-2025 are real).

A partnership posture: constructive challenging on the basis of feasibility, performance or accessibility risk, alternative proposals with a sketch or prototype. Bonus: the candidate cites a case where they accepted the original brief after discussion (no systematic opposition). Anyone who describes designers as they don't understand the tech or PMs as they talk too much shows a teamwork weakness that gets especially expensive at an SMB with a small product team.