Q385: Implementation Planning Drill Turning a Feature Request Into Safe Frontend Work

What Interviewers Want To Evaluate

This drill tests whether you can turn a loose feature request into a safe frontend plan.

Senior frontend engineers clarify ambiguity, identify user states, define contracts, choose implementation boundaries, plan rollout, and keep the work reviewable.

The interviewer wants to know whether you can lead execution without waiting for perfect instructions.

Short Interview Answer

When I receive a feature request, I first clarify the user goal, success metric, constraints, and non-goals. Then I map UI states, data contracts, permissions, accessibility, analytics, error handling, tests, and rollout risk. I split the work into reviewable steps so design, API, UI, quality, and release safety can move without one oversized pull request.

Clarifying Questions

Ask:

Who is the user?
What problem are we solving?
What does success mean?
What is out of scope?
What data is required?
Who can perform the action?
What happens on failure?
What platforms must work?
When does this need to ship?

Good questions reduce rework.

They also reveal hidden risk.

UI State Map

Map:

initial
loading
ready
empty
editing
validating
submitting
success
error
permission denied
offline
partial data

If a state is not designed, engineers will invent it during implementation.

That usually creates inconsistency.

Data Contract

Define:

request shape
response shape
error shape
nullable fields
pagination
filtering
sorting
authorization behavior
versioning
runtime validation

Frontend planning must include API reality.

The prettiest UI cannot survive an unclear contract.

Component Boundaries

Plan boundaries:

page shell
data loader
stateful controller
presentational components
form fields
empty and error states
shared primitives
tests

Keep reusable components focused.

Do not turn a single feature into a design system unless repeated need exists.

Rollout Plan

For risky features:

feature flag
internal dogfood
limited audience
monitoring
rollback path
analytics validation
support notes
cleanup task

Rollout is part of implementation.

Shipping code is not the same as safely releasing behavior.

Pull Request Slicing

Good slices:

types and API client
static UI states
interactive behavior
integration with backend
tests and accessibility fixes
analytics and rollout
documentation

Avoid one giant PR with everything.

Smaller PRs improve review quality.

They also reduce merge risk.

Example Plan

Feature: saved search views.

Plan:

clarify which filters are saved
define saved view API contract
model URL state and saved state interaction
build empty, list, create, rename, delete states
add permission rules
add keyboard accessible menu
track create and apply events
test save, apply, delete, unauthorized, and network failure
release behind flag

This is more complete than "add saved searches."

Risk Review

Look for:

data loss
permission leak
incorrect analytics
slow query behavior
inaccessible menus
confusing empty state
broken back button
stale cache
mobile layout failure

Risk review should happen before implementation, not only during QA.

Communication

Keep stakeholders aligned with:

assumptions
trade-offs
open questions
scope decisions
test plan
rollout plan
known follow-ups

Senior execution includes making the work understandable.

Clear communication prevents surprise.

Definition Of Done

Include:

core workflow works
states are handled
accessibility checked
responsive layout checked
tests added
analytics verified
errors recoverable
flag or rollout ready
documentation updated if needed

The definition of done should match the feature risk.

Common Mistakes

• Starting implementation before clarifying success.
• Forgetting permission and failure states.
• Treating API shape as someone else's problem.
• Shipping without rollout thinking.
• Creating one oversized PR.
• Missing mobile and keyboard checks.
• Adding analytics after launch without validation.
• Not documenting assumptions.

Final Mental Model

Feature planning is:

clarify
model states
define contracts
slice work
reduce risk
verify behavior
release safely

Senior frontend execution turns ambiguity into a path the team can actually follow.