Build an Event-Driven Folder Browser

Quick Overview

Design the state model and component architecture for an editable folder browser with unbounded nesting and stable identity. Support expansion, create, rename, move, subtree deletion, keyboard navigation, invalid-cycle prevention, persistence, and localized rendering updates.

Build an Event-Driven Folder Browser

Company: UiPath

Role: Frontend Engineer

Category: Software Engineering Fundamentals

Difficulty: easy

Interview Round: Onsite

## Question Build the state model and component architecture for an interactive folder browser. Opening a folder reveals its direct children. Users can create, rename, move, and delete files or folders. The initial nested input may omit stable IDs, but every item needs an identity before edits begin. An edit in one branch should not force the entire tree to re-render. ### Constraints & Assumptions - Folder depth is unbounded in the data model, though the rendered viewport is finite. - Names need only be unique among siblings. - Moving a folder into itself or one of its descendants is invalid. - Deleting a folder deletes its subtree after confirmation. - Expansion state is local UI state and does not need to be stored in the persisted tree. - The answer may use React-style terminology, but the state design should be framework-independent. ### Clarifying Questions to Ask - Are IDs supplied by the backend for newly created items? Assume the client creates temporary collision-resistant IDs and reconciles them after persistence. - Should multiple folders be open at once? Yes. - Is drag-and-drop required? The model should support a move command; pointer interactions are secondary. - Must the UI support keyboard navigation? Yes, describe tree semantics and focus movement. ```hint Normalize before editing Convert the nested input into an ID-keyed node map plus ordered child-ID lists. Expansion can then be keyed independently by folder ID. ``` ### What a Strong Answer Covers - A deterministic recursive import that assigns stable IDs once, not during render. - Normalized entities, parent/child relationships, and explicit edit commands. - Cycle prevention and atomic updates for moves and recursive deletes. - Fine-grained subscriptions or memoized selectors that update only affected nodes. - Optimistic persistence, conflict/error handling, and accessible tree interactions. ### Follow-up Questions 1. How would you virtualize a tree containing hundreds of thousands of visible items? 2. What happens when the server rejects an optimistic move? 3. How would you merge a remote rename with a local unsaved edit?

Quick Answer: Design the state model and component architecture for an editable folder browser with unbounded nesting and stable identity. Support expansion, create, rename, move, subtree deletion, keyboard navigation, invalid-cycle prevention, persistence, and localized rendering updates.

|Home/Software Engineering Fundamentals/UiPath
UiPath logo
UiPath
Aug 4, 2026, 12:00 AM
easyFrontend EngineerOnsiteSoftware Engineering Fundamentals
0
0

Question

Build the state model and component architecture for an interactive folder browser. Opening a folder reveals its direct children. Users can create, rename, move, and delete files or folders. The initial nested input may omit stable IDs, but every item needs an identity before edits begin. An edit in one branch should not force the entire tree to re-render.

Constraints & Assumptions

  • Folder depth is unbounded in the data model, though the rendered viewport is finite.
  • Names need only be unique among siblings.
  • Moving a folder into itself or one of its descendants is invalid.
  • Deleting a folder deletes its subtree after confirmation.
  • Expansion state is local UI state and does not need to be stored in the persisted tree.
  • The answer may use React-style terminology, but the state design should be framework-independent.

Clarifying Questions to Ask Guidance

  • Are IDs supplied by the backend for newly created items? Assume the client creates temporary collision-resistant IDs and reconciles them after persistence.
  • Should multiple folders be open at once? Yes.
  • Is drag-and-drop required? The model should support a move command; pointer interactions are secondary.
  • Must the UI support keyboard navigation? Yes, describe tree semantics and focus movement.

What a Strong Answer Covers Guidance

  • A deterministic recursive import that assigns stable IDs once, not during render.
  • Normalized entities, parent/child relationships, and explicit edit commands.
  • Cycle prevention and atomic updates for moves and recursive deletes.
  • Fine-grained subscriptions or memoized selectors that update only affected nodes.
  • Optimistic persistence, conflict/error handling, and accessible tree interactions.

Follow-up Questions Guidance

  1. How would you virtualize a tree containing hundreds of thousands of visible items?
  2. What happens when the server rejects an optimistic move?
  3. How would you merge a remote rename with a local unsaved edit?
Loading comments...