hardarchitectureNEWAIGUIDED ANSWER

Design a Self-healing React Component

Interview Prep mode active

Interview answer templates and key talking points. Switch the mode in the header to change your experience.

Asked In

OpenAIVercelFigmaMetaGoogleMicrosoftDatadog

Key Challenges

·Notice mobile layout bugs such as overflow, clipped buttons, or overlapping text
·Collect useful debugging information without sending private user data
·Show a safe fallback UI so the user can still complete the main action
·Let an AI agent suggest a fix, run checks, and create a patch or PR
·Decide which fixes AI can ship automatically and which need a human review

Simple Mentor Explanation

Think of this as a React component that can notice when it looks broken on mobile. For example, the Buy button may go outside the screen, text may overlap the image, or the page may start scrolling sideways. A self-healing component should not wait for a developer to notice. It should detect the problem, show a safe fallback UI, and send useful evidence to an AI agent that can help create the real fix.

Mental Model

Use this simple mental model: detect, protect, report, fix, verify, rollout. Detect means the component notices a layout issue. Protect means the user gets a safe fallback immediately. Report means the app sends redacted debugging evidence. Fix means AI suggests a patch. Verify means tests prove the patch is safe. Rollout means the fix ships slowly with a rollback option.

Diagrams

Runtime Recovery Flow

Mobile user opens component
        |
        v
Layout health hook checks UI
        |
        +-- healthy --> render normal component
        |
        +-- broken  --> render safe fallback
                         |
                         v
                  send redacted diagnostics

AI Fix Feedback Loop

Diagnostics
  -> AI agent explains likely cause
  -> AI suggests CSS/component patch
  -> CI runs visual + unit + accessibility tests
  -> feature flag canary
  -> monitor metrics
  -> promote, rollback, or ask human

Who Is Allowed To Decide?

Low-risk CSS spacing/token fix
        -> AI can auto-canary behind a flag

Checkout, login, forms, user data, a11y, big rewrite
        -> AI creates PR, human approves

Step-by-Step Explanation

Start with the real mobile problem

Do not start by saying AI will magically fix the UI. Start with a concrete bug. On mobile, the component may overflow, hide an important button, overlap text, or shift after loading. The design begins by defining which broken states matter.

Simple Example

Product card on desktop:
[Image] [Title] [Price] [Buy Button]

Broken on mobile:
[Image] [Very long title overlaps price]
                         [Buy Button outside screen]

Say This In Interview

"I would first define the mobile layout failures we care about: overflow, clipping, overlap, layout shift, and hidden critical actions."

Add observability hooks

Observability means the component can measure itself. In React, I would wrap the component with a layout health hook. The hook can use ResizeObserver to measure size, IntersectionObserver to check whether critical elements are visible, and PerformanceObserver to watch layout shift.

✓Check if scrollWidth is greater than clientWidth
✓Check if the CTA is visible
✓Check if important text is clipped
✓Track layout shift and hydration errors

Simple Example

if (element.scrollWidth > element.clientWidth) {
  reportLayoutBug('horizontal-overflow');
}

Say This In Interview

"I would add layout health hooks so the component can detect mobile-only bugs instead of relying only on user reports."

Switch to a safe fallback

If the layout is broken, the component should immediately help the user. It should switch to a known safe mobile layout, not generate a brand-new AI layout at runtime. The fallback should preserve the main action, such as Buy, Submit, Continue, or Save.

Simple Example

Normal layout:
[Image] [Title] [Price] [Buy]

Fallback layout:
[Image]
[Title]
[Price]
[Buy]

Say This In Interview

"If the UI is broken, I would render a prebuilt mobile-safe fallback so the user can still complete the core action."

Send AI safe debugging evidence

Now AI can help. But AI needs evidence. The client should send a redacted diagnostic bundle: component name, route, build id, viewport size, element measurements, bug type, and maybe a privacy-safe screenshot. Do not send passwords, tokens, emails, payment data, or raw user input.

✓componentId
✓route and buildId
✓viewport width and height
✓overflow or clipping signal
✓redacted DOM measurements
✓safe screenshot reference

Say This In Interview

"The AI agent should receive enough redacted evidence to diagnose the layout bug without exposing private user data."

Use an AI feedback loop

The AI agent should behave like a coding assistant, not like uncontrolled production code. It reads the diagnostics, explains the likely cause, suggests a CSS or component patch, and then the system runs checks before shipping.

Simple Example

Bug: Buy button overflows at 375px
AI diagnosis: card uses fixed width: 420px
Suggested fix: use max-width: 100%; flex-wrap: wrap;
Validation: screenshot diff + accessibility tests + unit tests

Say This In Interview

"I would use AI for diagnosis and patch generation, but every fix must pass visual, accessibility, and regression tests."

Decide when AI can auto-fix

AI can auto-fix only small, low-risk layout changes. For example, spacing, wrapping, max-width, responsive CSS, or design token changes can be canaried behind a feature flag. The system should monitor metrics and rollback automatically if things get worse.

✓Safe: spacing, wrapping, max-width, responsive CSS
✓Ship through feature flag
✓Start with a small canary
✓Rollback if layout errors or conversion gets worse

Say This In Interview

"I would allow AI to auto-canary only low-risk CSS fixes behind a feature flag with automatic rollback."

Decide when humans must approve

Some areas are too risky for automatic AI changes. Login, checkout, forms, user data, legal text, accessibility semantics, and large rewrites should require human approval. In those cases, AI should open a PR with the evidence and suggested patch.

✓Login and authentication
✓Checkout and payments
✓Forms and user data
✓Accessibility roles and labels
✓Large component rewrites

Say This In Interview

"For high-risk flows, AI should create a PR and attach evidence, but a human should approve the production change."

Final Interview Answer

"I would design the component with a self-healing boundary. First, it observes its mobile layout using ResizeObserver, IntersectionObserver, and layout metrics to detect overflow, clipping, overlap, or layout shift. If the UI is broken, it immediately switches to a prebuilt safe fallback so the user can continue. Then it sends redacted diagnostics to an AI agent, including viewport size, component id, build id, DOM measurements, and safe screenshot evidence. The AI can suggest a fix, but the fix must pass visual, accessibility, and regression tests. I would allow AI to auto-canary only low-risk CSS fixes behind a feature flag, while login, checkout, forms, user data, accessibility, and large rewrites require human approval."

Key Takeaways

✓Start simple: first detect the layout problem, then recover, then ask AI to help fix it.
✓AI should not directly rewrite the live UI for every user. The component should use known safe fallbacks.
✓The AI loop should collect evidence, suggest a patch, run tests, and roll out slowly.
✓Humans must approve risky changes such as checkout, login, forms, accessibility, or user data flows.
✓A strong answer clearly separates detection, fallback, AI repair, testing, rollout, and manual override.