Q376: Production Code Review Drill Reading a React Component for Risk

What Interviewers Want To Evaluate

This drill tests whether you can review frontend code like someone responsible for production outcomes.

Senior frontend reviews are not only about syntax.

They look for correctness, accessibility, state ownership, rendering cost, error behavior, API assumptions, security boundaries, testability, and maintainability.

The interviewer wants to see whether you can read a component and quickly separate cosmetic feedback from release-blocking risk.

Short Interview Answer

When I review a React component, I first understand the user workflow and the contract around data. Then I check correctness, loading and error states, accessibility, state ownership, rendering cost, API boundaries, and tests. I keep review comments specific: what can break, why it matters, and what change would reduce the risk. I avoid turning every preference into a blocker.

Review Order

Use this order:

user outcome
data contract
state ownership
render behavior
accessibility
failure states
performance
security
tests
maintainability

This order keeps the review connected to product behavior.

It also prevents the common mistake of starting with naming style while missing a broken empty state.

Example Component

Imagine reviewing this simplified component:

function UserSearch({ api }: { api: SearchApi }) {
  const [query, setQuery] = useState("");
  const [users, setUsers] = useState<User[]>([]);

  useEffect(() => {
    api.search(query).then(setUsers);
  }, [query, api]);

  return (
    <div>
      <input value={query} onChange={(event) => setQuery(event.target.value)} />
      {users.map((user) => (
        <div onClick={() => location.href = `/users/${user.id}`} key={user.id}>
          {user.name}
        </div>
      ))}
    </div>
  );
}

A shallow review might say:

rename users to results
move inline handler
format JSX

A senior review sees deeper risk.

Correctness Risks

Possible issues:

search runs for empty query
responses can arrive out of order
there is no loading state
there is no error state
there is no empty state
navigation uses global location
API instance identity may refetch unexpectedly

The most important issue is stale responses.

If the user types quickly, an earlier request may finish after a later request and overwrite the correct result.

Better Review Comment

A good comment is specific:

This effect can show stale results when multiple searches overlap.
Can we cancel or sequence requests so only the latest query can update state?
That will protect fast typing and slow network conditions.

That comment explains:

what breaks
when it breaks
why users care
what direction fixes it

State Ownership Questions

Ask:

Is query local UI state?
Should query be mirrored in the URL?
Are results server state?
Do we need cache ownership?
Who owns invalidation?
Should selected user be route state?

For a search page, the query often belongs in the URL.

For a small embedded picker, local state may be enough.

The answer depends on sharing, back button behavior, refresh behavior, and product expectations.

Accessibility Risks

The example uses clickable div elements.

That creates problems:

not keyboard reachable by default
not announced as interactive
no focus style
no semantic role
no accessible label for input

A better review comment:

The result rows behave like links but are rendered as divs.
Can we render semantic links so keyboard and screen reader users get the same navigation affordance?

Prefer semantic elements before adding roles.

Loading, Empty, and Error States

Ask what users see during:

initial load
typing
slow network
no results
API error
permission failure
partial data
retry

If these states are missing, the UI may feel broken even when the happy path works.

Senior review should protect the full lifecycle.

Performance Review

Look for:

expensive filtering during render
unstable dependencies
request on every keystroke without debounce
large result lists without virtualization
unnecessary client JavaScript
large child rerenders
layout shift from changing result heights

Do not optimize blindly.

Name the likely cost and the user situation where it matters.

Security and Privacy Review

For search components, check:

query logged accidentally
sensitive results cached incorrectly
user IDs exposed in unsafe contexts
HTML rendered from results
authorization assumed on the client
analytics firing with private query text

Frontend review should still respect trust boundaries.

UI code can leak sensitive data even when the backend is secure.

Test Review

Useful tests:

typing updates query
latest response wins
loading state appears
empty state appears
error state allows retry
keyboard can reach results
navigation target is correct

The highest-value test for this component is stale-response prevention.

That is a realistic production bug.

Review Tone

Good senior review tone:

clear
specific
kind
evidence-based
prioritized
actionable

Avoid:

vague comments
style-only blocking
rewriting the author's code in your own taste
missing production behavior
commenting without reading context

Interview Drill

When given a component, answer in this structure:

I will first identify the user workflow.
Then I will check correctness and state ownership.
Then I will inspect accessibility and failure states.
Then I will look at performance, security, and tests.
Finally I will separate blocking issues from follow-up polish.

This shows judgment.

It also shows you can review without creating noise.

Common Mistakes

• Reviewing only formatting.
• Missing stale async responses.
• Ignoring keyboard access.
• Treating every personal preference as a blocker.
• Not checking loading, empty, and error states.
• Forgetting that API contracts can be wrong.
• Asking for abstractions before proving repeated complexity.

Final Mental Model

Production code review is:

read the workflow
find the risk
explain the impact
suggest the smallest useful fix
separate blockers from polish

Senior reviewers make the product safer and the team better at the same time.