Most frontend hiring processes test whether a candidate can use a framework. That is a reasonable filter for a junior role, but it says little about seniority. A mid-level engineer can build the screen in the ticket. A senior engineer decides how the next twenty screens will be built, and notices which of them will break first.
This guide is written for hiring managers and technical leaders. It describes what separates senior frontend work from competent implementation, and which questions reveal the difference.
Beyond the framework
Framework knowledge expires quickly. The patterns that last are underneath it: semantic HTML, the browser's rendering pipeline, network behavior, state ownership, and the way users actually move through an interface.
A senior frontend engineer treats the framework as one tool among several. Ask how they would build a feature, and listen for questions before answers:
- What is the user trying to do, and what information do they need?
- Which states exist besides the ideal one: loading, empty, partial, error, and restricted?
- Does this need JavaScript at all, or can the server or the build step do the work?
- Who else will maintain this code, and what will they need to understand?
Watch for judgment about trade-offs. Every abstraction, dependency, and client-side feature has a cost. Senior engineers can explain the cost of their preferred approach as clearly as its benefits, and they can say when they would choose something simpler.
Architecture decisions that scale
Architecture is where seniority becomes visible over time. Poor frontend architecture rarely fails immediately. It fails when the second team arrives, when requirements change, or when the product adds a new user role.
Strong candidates can talk concretely about:
- Component boundaries. Which parts own behavior, which are layout, and which belong to a single feature rather than the shared layer.
- State ownership. The difference between server data, URL state, form state, and temporary interface state, and why mixing them causes bugs.
- Explicit contracts. Typed props and named states that make edge cases visible in the code instead of hidden in conditionals.
- Shared foundations. Design tokens and shared components that make the correct implementation easier than the inconsistent one.
Ask for an example where they removed complexity, not only where they added a system. Simplifying an over-abstracted component is often a stronger signal than building a new one.
Look for evidence of a quality system as well. A senior engineer protects decisions with automation: type checks, linting, end-to-end tests, and accessibility scans that run before release. The frontend quality system case study is one example of that approach, combining typed content, accessibility checks, crawlable routes, and responsive layout validation.
Accessibility and internationalization
Accessibility and internationalization are where many otherwise strong candidates show gaps, which makes them useful hiring signals.
For accessibility, look beyond awareness of ARIA. Senior engineers start with native HTML, test with a keyboard as a matter of routine, and understand focus management for dialogs, menus, and client-side navigation. They treat contrast, labels, and error messages as acceptance criteria rather than polish. They also know the limits of automated tools: an axe scan catches known defects, but it cannot confirm that a workflow is usable.
For internationalization, ask about more than translated strings. A senior engineer should be able to discuss:
- Layouts that survive longer translated text without breaking
- Right-to-left languages, logical CSS properties, and mirrored icons
- Locale-aware dates, numbers, and currencies
- Localized URLs,
hreflang, and search visibility for each language
The portfolio SEO and i18n system case study shows how these concerns combine in a static site that serves several languages without client-side content dependencies.
Performance ownership
Mid-level engineers fix performance problems when someone reports them. Senior engineers own performance: they set budgets, measure in realistic conditions, and prevent regressions before they ship.
Listen for specifics. A strong candidate can explain the Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift) and connect each one to implementation choices. They know that layout shift usually comes from content without reserved space, that slow interactions usually come from too much synchronous work in event handlers, and that the largest paint is often delayed by competing requests rather than by the framework itself.
Ownership also means questioning the default. Does this page need a client-side framework? Does this dependency justify its size? Can this work move to build time? Engineers who ask these questions keep products fast without heroic optimization projects later.
Questions to ask in interviews
The most revealing questions ask candidates to reason about real situations rather than recite definitions:
- Walk me through a component API you designed. What did you deliberately leave out?
- Tell me about a frontend decision you later reversed. What did you learn?
- How would you review a pull request that adds a modal dialog?
- A dashboard is slow after a recent release. What do you check first?
- How do you decide whether new state belongs in the URL, the server cache, or local component state?
- How would you prepare an existing interface for an Arabic translation?
- What would you automate before the team grows from three to ten engineers?
Good answers include constraints, trade-offs, and verification. Weak answers describe only the ideal path. Asking the candidate to review a real pull request, using a structure such as this frontend code review checklist, often reveals more than a whiteboard exercise.
Before hiring, it also helps to know where your current frontend stands. Count how many of these statements are true today:
Rate your current frontend setup
- Every data view designs its loading, empty, and error states.
- Shared components have documented, typed contracts.
- Colors and spacing come from design tokens, not literals.
- Every workflow can be completed with a keyboard alone.
- Automated accessibility checks run before each release.
- Core Web Vitals are measured and have agreed budgets.
- New dependencies need a stated reason.
- Layouts handle longer translated text and right-to-left languages.
- End-to-end tests cover the most important user journeys.
- Code review follows a shared, risk-first checklist.
Try the interactive scorecard with a live score in the original article.
A low score is not a failure. It is a map of where senior frontend experience will have the most impact, whether that comes from a new hire or from specialist frontend engineering services.
Originally published at suprabhat-dev.com.
Top comments (0)