Q082: Senior Frontend Code Review

What Interviewers Want To Evaluate

This question tests whether you can review code for behavior, risk, maintainability, accessibility, performance, and team standards. Interviewers want to know what you block, what you suggest, and how you keep reviews useful instead of personal or noisy.

Senior code review is not about catching every style issue. It is about protecting users and keeping the codebase understandable.

Short Interview Answer

In frontend code review, I prioritize correctness, user impact, accessibility, security, performance, state ownership, test coverage, and consistency with existing patterns. I separate blocking issues from suggestions and explain why a change matters. For senior-level review, I look beyond the diff: route behavior, failure states, loading states, responsive layout, keyboard support, API contracts, telemetry, and release risk.

Detailed Interview Answer

A strong review starts by understanding the intent of the change. The reviewer should ask what user problem is being solved, what flows are affected, and what risk exists.

Then review in layers:

Does it solve the intended problem?
Can it break critical flows?
Are states handled clearly?
Is accessibility preserved?
Is data trusted correctly?
Is performance acceptable?
Are tests appropriate for the risk?
Does it match local patterns?

Blocking Issues

Block issues that can harm users, break contracts, introduce security risk, damage accessibility, create significant performance regressions, or make future maintenance unsafe.

Examples include missing server-side authorization, inaccessible controls, unhandled failed submissions, incorrect loading states, data leaks, broken keyboard paths, and fragile assumptions about API data.

Suggestions

Suggestions are still valuable, but they should not feel like hidden requirements. Naming, small refactors, or stylistic improvements can be suggestions when they do not affect correctness.

Use language that makes priority clear: “blocking”, “suggestion”, “question”, or “nit”.

Frontend-Specific Review Areas

Frontend code has many user-facing states. Review loading, empty, error, disabled, optimistic, offline, permission-denied, and slow-network states.

Also review responsive behavior. A component that looks fine on desktop can fail on mobile or in narrow sidebars.

Accessibility Review

Accessibility review includes semantics, labels, focus behavior, keyboard access, color contrast, error messaging, and motion preferences.

Do not rely only on screenshots. Interactive behavior matters.

Performance Review

Look for large dependencies, unnecessary client components, broad re-renders, expensive derived calculations, huge DOM lists, unbounded effects, and layout shifts.

Not every PR needs deep profiling, but risky surfaces should include evidence.

Test Review

Tests should match risk. A small pure helper may need unit tests. A critical checkout flow may need integration and E2E coverage.

Avoid requiring tests mechanically when they do not increase confidence. Also avoid accepting high-risk changes without meaningful verification.

Common Mistakes

A common mistake is reviewing style before behavior. Another is leaving many vague comments that make the author guess what matters.

Another mistake is approving because the code “looks clean” while missing accessibility, permissions, or failure states.

Senior Trade-Offs

Fast reviews help delivery, but shallow reviews can create production risk. Deep reviews improve quality, but they can slow teams if applied to every trivial change.

The senior approach is risk-based review depth.

Code or Design Example

A review checklist can be embedded in team docs or PR templates.

type ReviewSignal = {
  behavior: "clear" | "unclear";
  risk: "low" | "medium" | "high";
  accessibility: "checked" | "not-applicable" | "needs-work";
  tests: "sufficient" | "missing" | "not-needed";
  releaseSafety: "safe" | "needs-flag" | "needs-rollback-plan";
};

This helps reviewers think beyond formatting.

Example Review Comment

Weak comment:

“This state is weird.”

Better comment:

“Blocking: if the save request fails, the button stays disabled and the user cannot retry. Can we move disabled state behind isSubmitting and render a retryable error message?”

The better comment explains the user impact and the requested fix.

Collaboration

Code review should improve trust. Ask questions when context is missing. Offer pairing for complex changes. Move architecture debates out of tiny PR comments when needed.

Good reviewers make authors feel supported, not inspected.

Lead Engineer Perspective

A lead engineer should define review standards and model healthy review behavior. That includes deciding what must block, what can be followed up, and when to create shared guidelines.

Repeated review comments are a signal that the system needs better docs, helpers, lint rules, or abstractions.

Revision Notes

Senior frontend code review is risk-based. Review behavior, accessibility, security, performance, test confidence, and maintainability.

Key Takeaways

The best review comments are specific, prioritized, and connected to user or system impact.

Follow-Up Questions

1. What issues should block a frontend PR?
2. How do you review accessibility?
3. How do you review performance risk?
4. How do you separate suggestions from requirements?
5. When should a PR have E2E tests?
6. How do you avoid noisy reviews?
7. How do you review client/server boundaries?
8. How do you handle disagreement in review?
9. What belongs in a PR template?
10. How do repeated comments improve team standards?

How I Would Answer This In A Real Interview

I would explain that I review based on user risk and system health. I would check behavior, states, accessibility, security, performance, API assumptions, tests, and local patterns, while clearly marking blockers versus suggestions.