Back to Machine Coding
Machine Coding
easy
mid

What follow up questions should you expect after completing a machine coding component?

An open-ended live-coding prompt — clarify the scope first (it likely means a follow-ups/comments/replies thread or a follow-up tasks list). Then model the data, build a recursive or flat-with-parentId structure, handle add/edit/delete, and cover loading/empty/error and accessibility.

5 min read·~25 min to think through

"Build a Follow-ups" is an under-specified prompt — the first move is to clarify scope, because "follow-ups" could mean a few different things:

  • A threaded comments / replies widget (follow-up messages on a post or ticket).
  • A follow-up tasks / action items list (e.g. after a meeting or a support case).
  • Follow-up questions in a Q&A or interview-prep context.

Ask which one. Below assumes the most common: a threaded follow-ups/comments component.

1. Data model

js
// Flat + parentId scales better than deep nesting:
comments = {
  'c1': { id: 'c1', parentId: null, author, text, createdAt },
  'c2': { id: 'c2', parentId: 'c1', author, text, createdAt },
}

Flat-with-parentId (normalized) makes add/edit/delete O(1) and avoids deep-nesting headaches; build the tree for rendering.

2. Rendering

  • A recursive <FollowUp> component: render the item, then map its children recursively.
  • Cap visual nesting depth (indent only so far; deeper replies flatten) — real apps do this.
  • Memoize items so editing one doesn't re-render the whole tree.

3. Interactions

  • Add — a reply form per item + a top-level form. Optimistic insert, then persist.
  • Edit — inline edit mode, optimistic update.
  • Delete — confirm; decide what happens to children (delete subtree, or show "[deleted]" tombstone keeping replies).
  • Collapse/expand threads.

4. The states + a11y

  • Loading (skeleton), empty ("No follow-ups yet"), error.
  • Accessible: semantic structure, form labels, focus management when entering edit/reply mode, keyboard support.

5. Scale concerns

  • Pagination — long threads load more on demand.
  • Virtualization if a thread can be huge.
  • Real-time — new follow-ups arriving via WebSocket, applied as targeted patches.

How to answer

"First I'd clarify what 'follow-ups' means here — a replies/comments thread, a follow-up tasks list, or follow-up questions — since the prompt is open-ended. Assuming a threaded comments widget: normalized flat data with parentId, a recursive render component with a capped indent depth, add/edit/delete with optimistic updates, and the usual loading/empty/error states plus accessibility. At scale, pagination and possibly virtualization and real-time updates."

Follow-up questions

  • Why clarify the prompt before coding?
  • Why flat-with-parentId instead of a deeply nested structure?
  • What happens to child replies when a parent is deleted?
  • How would you handle a very long or real-time thread?

Common mistakes

  • Jumping into code without clarifying what 'follow-ups' means.
  • Deeply nested state that's painful to update.
  • Unbounded visual nesting depth.
  • Skipping empty/error states and accessibility.
  • Re-rendering the whole tree on every edit.

Performance considerations

  • Normalized data makes mutations O(1). Memoized recursive items contain re-render scope. Pagination and virtualization handle large threads. Capped nesting depth keeps the DOM and layout sane.

Edge cases

  • Deleting a parent with existing replies.
  • Very deep reply chains.
  • Long threads needing pagination/virtualization.
  • Real-time follow-ups arriving while the user is reading.
  • Optimistic add that fails server-side.

Real-world examples

  • Threaded comments (Reddit/HN/GitHub), follow-up action items on a support ticket.

Senior engineer discussion

The senior move is clarifying the ambiguous prompt before coding — stating the interpretations and confirming scope. Then they reach for normalized flat-with-parentId data, a memoized recursive renderer with capped depth, optimistic add/edit/delete, full state handling, accessibility, and name pagination/virtualization/real-time as the scale path.

Related questions