Skip to content
 
 

Latest commit

 

History

12 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Take-Home: Organizing a Live Stream of Development Events

Expected time: 1–2 hours. Please don't spend more than that — we'd rather see a clean core with honest notes about what you'd do next than a polished everything.

Background

We record AI-assisted coding sessions as a stream of events. There are two event types:

  • prompt — a request a developer made to an AI agent (id, session, ts, text)
  • subprompt — an atomic unit of work produced while answering a prompt (id, prompt_id, parent_id, ts, headline, files)

Subprompts chain together: parent_id points at the subprompt they built on (or null if they're the first under their prompt). A subprompt may branch — two subprompts can share the same parent (e.g. the agent retried from an earlier point).

There is a third level of the hierarchy that the stream does not contain: goals. A goal is the higher-level objective a developer was pursuing across one or more prompts (e.g. "add authentication" spans both "Add a login form" and "Store the session token"). Inferring goals is your job.

The task

Write an organizer (in organizer.py, or structured however you like) that:

  1. Consumes the stream. Use the provided Streamer (see streamer.py — do not modify it). Events arrive one at a time on an interval.

  2. Builds a DAG incrementally. As events arrive, maintain a graph: goals → prompts → subprompt chains (with branches). The catch: arrival order is not causal order. A subprompt can arrive before its parent subprompt, or before its prompt. Your organizer must cope — no event should be dropped, and the graph must be correct once the relevant events have arrived.

  3. Groups prompts into goals — your way. The data carries several signals you could use (sessions, timestamps and gaps, file overlap, the prompt text itself). Pick a heuristic, implement it, and document why you chose it and where it breaks. There is no single right answer; we care about your reasoning.

  4. Can report at any time. Expose a method like snapshot() that can be called mid-stream and returns/prints the current state of the DAG — including any events that are still "orphaned" (waiting on a parent that hasn't arrived). After the stream ends, print the final DAG in a human-readable form (an indented tree is fine).

Example of the kind of output we mean

Goal: billing cleanup (4 prompts)
  Prompt p1 "Support VAT for EU customers (cleanup)"
    sp1 Refactor the endpoint
      sp2 Refactor the client wrapper
        sp3 Validate inputs for the render path
  Prompt p2 "Show billing history page (cleanup)"
    sp5 Implement the background job
      sp6 Implement the retry logic
...

(Your goal names/groupings may differ — that's expected. The stream is 500 events; summarizing per goal instead of printing every node is fine too, as long as the full DAG is inspectable.)

Running

python3 streamer.py                  # watch the raw feed
python3 organizer.py                 # your program
python3 organizer.py --interval 0    # should also work at full speed

Python 3.9+, standard library only, no external dependencies please.

Organizer usage

Run the organizer from this directory:

python3 organizer.py
python3 organizer.py --interval 0
python3 organizer.py --interval 0 --full

The default output is a prompt-level goal summary; --full prints the complete subprompt forest. Both views always include unresolved and invalid relationship sections. A different feed can be selected with --path.

For programmatic inspection, ingest event dictionaries one at a time and take a JSON-compatible snapshot at any point:

from organizer import Organizer

organizer = Organizer()
organizer.add_event(event)
state = organizer.snapshot()
print(organizer.render(full=True))

Run the standard-library test suite with:

python3 -m unittest discover -s tests -v

Deliverables

  • Your code.
  • A short NOTES.md (a few paragraphs): your goal-grouping heuristic and its failure modes, how you handle out-of-order events, and what you'd do with more time.

What we look for

  • Correct incremental handling of out-of-order/orphaned events.
  • A sensible data model for the DAG.
  • A defensible, documented goal heuristic (simple is fine).
  • Readable code and a clear write-up. Tests are a plus, not a requirement.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages