Deepvue FE Intern — Take-Home Assignment

Welcome. This repo contains everything you need.

Time expected: 8-10 focused hours Deadline: 2 days from receipt

---

What's in this repo

.
├── README.md # This file
├── workflows.json # Mock data for the Workflows page (~150 entries)
├── runs.json # Mock data for the Runs page (~20 entries)
├── runs-large.json # Optional stress-test data for Runs (~1500 entries)
├── reference/ # Aesthetic reference screenshots
│ ├── dashboard-home.png
│ ├── api-explorer.png
│ ├── dashboard-analytics.png
│ └── account-credentials.png
└── .gitignore

---

Context

This assignment is a realistic slice of what you'd do on the job. We care more about how you make decisions and how your work looks than ticking every requirement perfectly.

You can use AI tools (Cursor, Claude, Copilot, ChatGPT) — we expect you to use what you'd use on the job.
Note: the process includes a 1-hour live extension and technical discussion call after this take-home where you'll modify your own code in real time. Use AI strategically, not as a crutch.

---

The task

Build a two-route React application: Workflows Library + Runs. Both pages exist in our real product. You're building a small but representative version of both.

Route 1: Workflows (/workflows)

Functional requirements:

• Page header with title + brief description
• Search input — filters workflows by name (debounce welcome)
• Status filter pills: All / Published / Draft / Archived (each showing a count)
• Sort dropdown: Last Modified / Name / Nodes
• URL state synchronization — filters, search, sort persist in URL params. Direct-linking to a filtered view works. Browser refresh preserves state.
• Grid of workflow cards (responsive: 3 cols desktop, 2 tablet, 1 mobile)
  • Each card shows: name, status badge, node count, last-modified date, short description
  • Required hover/active states — your design judgment, explain choices in README
  • Card-level checkbox for multi-select
  • Primary action: "Run" — opens a modal with workflow name + single text input (subject_id) + Start button. On submit: console.log({ workflow_id, subject_id }) and close modal.
  • Secondary action: "Open" — console.log(workflow_id)
• Multi-select bulk actions — selecting 1+ cards reveals a sticky action bar at the bottom: "Archive selected" / "Bulk Run" / "Clear selection". Wire to console.log handlers.
• Performance — the page must remain interactive (no scroll jank, no input lag) at the full dataset size in workflows.json. Implementation choice — pagination, virtualization, infinite scroll, windowed grid — is yours. Be ready to defend it in the interview.
• Empty / loading / error states

Route 2: Runs (/runs)

Functional requirements:

• Page header with title + description
• Status filter pills with counts: All / Running / Waiting / Completed / Failed
• Run cards showing: workflow name, status badge, progress bar (for running), started-at as relative time ("3 minutes ago"), duration (for completed/failed)
• Cancel action on Running / Waiting runs — console.log(run_id)
• Performance — the Runs page must remain interactive with the dataset in runs.json. If you swap to runs-large.json (1500 entries), it should still be smooth. Implementation choice — pagination, virtualization, infinite scroll, windowed list — is yours. Be ready to defend it in the interview.
• Empty / loading / error states
• Clicking a run row navigates to Route 3 (Run Detail) — see below

Route 3: Run Detail (/runs/:id)

Clicking a run from the Runs list navigates here. There is no reference screenshot for this page — you're designing it. Apply the existing dashboard aesthetic (from reference/) to the functional requirements below. How a run detail view should look inside our dashboard is part of what you're being evaluated on.

Functional requirements:

• Header: status badge, subject_id, short run id (e.g., last 8 chars)
• Warning banner — if the run has a non-null warning field, render an amber banner near the top with the message
• Timeline column (main content):
  • Vertical list of steps from the run
  • Each step shows: status icon, node name, node type label, status badge, output as formatted JSON (succeeded steps), error message (failed steps)
  • Visually distinguish status: succeeded (green) / failed (red) / pending (amber, possibly with spinner) / not_started (gray)
  • Step metadata: started_at, duration_ms where available
• Run details sidebar (right side, narrower column):
  • Workflow id (short) + version
  • Subject
  • Started (formatted timestamp)
  • Completed-duration ("1m 18s") OR running-duration if still in progress
  • Collapsible "Trigger Input" section showing trigger_input JSON
• Empty state for steps array (e.g., for waiting runs with no steps yet)
• Loading state on navigation
• Not-found state if the run_id doesn't exist

Data note: Both runs.json and runs-large.json share the same schema — clicking into any run from either set should render the detail page. runs-large.json is ~2.5MB on disk; initial parse + render will hit harder than runs.json (that's intentional — part of what the stress file is meant to surface).

Shell

• Top nav with two tabs: Workflows | Runs
• Match our existing dashboard aesthetic (see reference/)
• Active tab visibly indicated

---

Mock data

Consume workflows.json and runs.json as if they were real APIs. Simulate 300-800ms fetch delays so loading state actually renders.

runs-large.json (1500 entries) is an optional stress file for the Runs page. Runs grow continuously in production; this simulates what a busy customer's Runs view actually looks like. Swap your data source to it to verify your implementation holds up at scale. We recommend doing it — and be ready to discuss what you measured and changed.

The data contains intentional edge cases. How you handle them is part of what we evaluate:

• Some long names that test text overflow
• A workflow with 0 nodes
• A workflow with a future last_modified date (data quality bug)
• A run that's been running for 30+ minutes
• A run with no subject_id

We won't tell you what to do with each — that's your judgment.

---

Stack constraint

Required: React + TypeScript + Tailwind CSS + React Router Components: shadcn/ui OR MUI (your pick — explain in README)

These match our production stack — we want to see your work in the tools you'll actually use on the job.

---

Design target

Match the aesthetic of our existing customer dashboard. Reference screenshots in reference/:

• dashboard-home.png — main dashboard landing view
• api-explorer.png — list-of-items view with filter pills (close analog to your Workflows page)
• dashboard-analytics.png — data visualization within the dashboard shell
• account-credentials.png — settings-style view with sidebar nav

There is no reference screenshot for Route 3 (Run Detail) — you're designing that page yourself, using these dashboard screenshots as the aesthetic anchor.

Aesthetic anchors:

• Light page background
• Card-based layouts with subtle shadows
• Purple/violet primary action color
• Clean sans-serif typography with clear hierarchy
• Status badges color-coded — palette is your judgment, explained in README

You don't need to build the sidebar — focus on the main content area.

---

Stretch

We don't penalize skipping these. We notice when you nail them.

• Run your Runs implementation against runs-large.json (1500 entries) and tune until it's smooth — be ready to walk through what you measured + changed in the interview
• Skeleton loading states (vs spinner)
• Keyboard navigation (esc closes modal, etc.)
• Runs detail expansion (clicking a run reveals more inline)
• A small element of your own design that elevates the page (motion, micro-interaction, density-tuning, attention to small things)

---

What we evaluate

Signal	Weight
Visual fidelity to reference	High
Component composition + reuse across routes	High
URL state handling	High
Multi-select + modal patterns	Medium
Edge case handling (the data quirks)	Medium
Stretch goals nailed	Bonus

What we don't evaluate

• Tests (don't write any — focus on the UI)
• Backend (mock data provided)
• Deployment (local npm run dev is fine)
• Algorithm complexity

---

Submission

• Send a ZIP of your project by replying to the original email thread. Exclude node_modules/, dist/, build/, .next/. If the ZIP exceeds your email's attachment limit, use a Google Drive or Dropbox link (set to "anyone with the link can view").
• Please do not publish your solution to a public GitHub repo or share it elsewhere. Keep it private to you and Deepvue.
• Your README must include:
  • A single command to install + run the project (e.g., npm install && npm run dev). The reviewer should be able to spin it up with one shell command after unzipping.
  • shadcn/ui vs MUI — what you picked and why
  • Color palette decisions for status badges
  • Estimated time spent
  • What you'd improve if you had another 4 hours

---

What happens after submission

After we review your take-home, selected candidates move to a 1-hour live extension and technical discussion call. You'll screen-share your code and extend it with a small new requirement in real time, explaining decisions as you go.

This isn't a gotcha — it's how we verify ownership and see how you think under live constraints.

---

Questions

Ambiguity is real in product work. Email chandrashekhar@deepvue.ai if anything is unclear.

Asking clarifying questions is a positive signal, not a negative one.