Concept questionMedium~7 minFrontend Foundations / 6 of 30

Interview question

How do you decide where to split React components and what props they should receive?

Design React component boundaries and props

Explains how to split components around ownership, reuse, readability, state, and API-like prop contracts.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would split components around responsibilities and state ownership. A container or page component can fetch data and coordinate workflow state, while smaller presentational components render specific pieces of UI from props. Props should be explicit and shaped around what the child needs, not the entire parent data object by default. If a child needs to change something, it receives a clear callback such as onSave or onSelect.

Full answer below

Practice focus

Component boundaries, state ownership, prop design, composition, reuse, readability, and maintainability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Component design is the frontend version of API design. Poor boundaries create tangled state, awkward props, and components that are hard to test or reuse.
I would split components around responsibilities and state ownership. A container or page component can fetch data and coordinate workflow state, while smaller presentational components render specific pieces of UI from props. Props should be explicit and shaped around what the child needs, not the entire parent data object by default. If a child needs to change something, it receives a clear callback such as onSave or onSelect.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid over-splitting every few lines into tiny components when it makes the flow harder to read. Reuse is useful, but premature generic components often become hard to understand. Composition can be better than many boolean props. For example, passing children or slots can make a layout component flexible without teaching it every possible business case. TypeScript props help document required values, optional values, and callback contracts.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would look for components with too many props, too many responsibilities, or state that belongs elsewhere. Those are refactor signals. I would also consider testing: components with clear inputs and callbacks are easier to test with user behavior. Design-system components should be generic and accessible, while feature components can know domain language. The boundary should help future change, not only satisfy a style preference.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Passing whole domain objects everywhere by habit.
Adding many boolean props instead of using composition.
Splitting components so aggressively that the feature is hard to follow.
Letting child components secretly own parent workflow state.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain state ownership across components.
A component has unrelated responsibilities and fragile props.
Generic components know too much business logic.
Callbacks and prop types are unclear.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is composition better than configuration props?
What makes a prop contract stable?
How would you refactor a component with too many responsibilities?

Continue the section

Next in Frontend Foundations: useEffect Dependencies

Step 7 of 30

Explain useEffect dependencies and side effects

Opening drill

Concept questionMedium~7 minFrontend Foundations / 6 of 30

Interview question

How do you decide where to split React components and what props they should receive?

Design React component boundaries and props

Explains how to split components around ownership, reuse, readability, state, and API-like prop contracts.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Component boundaries, state ownership, prop design, composition, reuse, readability, and maintainability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Component design is the frontend version of API design. Poor boundaries create tangled state, awkward props, and components that are hard to test or reuse.
I would split components around responsibilities and state ownership. A container or page component can fetch data and coordinate workflow state, while smaller presentational components render specific pieces of UI from props. Props should be explicit and shaped around what the child needs, not the entire parent data object by default. If a child needs to change something, it receives a clear callback such as onSave or onSelect.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid over-splitting every few lines into tiny components when it makes the flow harder to read. Reuse is useful, but premature generic components often become hard to understand. Composition can be better than many boolean props. For example, passing children or slots can make a layout component flexible without teaching it every possible business case. TypeScript props help document required values, optional values, and callback contracts.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would look for components with too many props, too many responsibilities, or state that belongs elsewhere. Those are refactor signals. I would also consider testing: components with clear inputs and callbacks are easier to test with user behavior. Design-system components should be generic and accessible, while feature components can know domain language. The boundary should help future change, not only satisfy a style preference.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Passing whole domain objects everywhere by habit.
Adding many boolean props instead of using composition.
Splitting components so aggressively that the feature is hard to follow.
Letting child components secretly own parent workflow state.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain state ownership across components.
A component has unrelated responsibilities and fragile props.
Generic components know too much business logic.
Callbacks and prop types are unclear.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is composition better than configuration props?
What makes a prop contract stable?
How would you refactor a component with too many responsibilities?

Continue the section

Next in Frontend Foundations: useEffect Dependencies

Step 7 of 30

Explain useEffect dependencies and side effects

How do you decide where to split React components and what props they should receive?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How do you decide where to split React components and what props they should receive?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section