{"repo": "anushka404/mini-exception-inbox", "files": {"INSTRUCTIONS.html": {"c887c1b9fd7dd6d3a68e8633246af8582496311f": {"t": 1786068567.1168926, "n": 19761, "h": "4ffd0506f4b8c466", "c": "\n\n\n\n\nIntern Hiring Test — Mini Exception Inbox\n\n\n\n\n\n\n
\n\n \n
\n
Intern Hiring Test
\n

Mini Exception Inbox

\n

Ingest messy factory data, detect deficits, serve through an API, and render a timeline inbox.

\n
Deadline: 4 days from receipt.
\n
\n\n \n
\n
Context
\n
\n

Factory data is messy. Turning it into decisions is the job. Instead of dashboards that show planners 500 alerts a day, the system we're building reasons across disruptions and writes the response back into the ERP. That means every piece of code — from data pipelines to API endpoints to the UI a planner clicks through — has to handle real-world messiness.

\n

This test is a miniature of that exact work. You're given two CSV files derived from real (Kaggle) store-item demand data, reframed as a manufacturing scenario: a production plan (what we said we'd make) and actual production (what we actually made). The gap between them — exceptions — is what needs to surface in an inbox someone acts on.

\n
\n
\n\n \n
\n
The Task
\n

Build a Mini Exception Inbox

\n\n
    \n
  1. \n
    Ingest
    \n
    Load both CSVs into a relational database. Keep raw data and cleaned data separable (separate raw vs clean tables, or an equivalent pattern).
    \n
      \n
    • actual_production.csv — daily units actually produced
      • \n
    • production_plan.csv — daily planned production
      • \n
    \n
    2. \n
  2. \n
    Detect Exceptions
    \n
    A deficit exception exists for a given product on a given day when units_produced < 0.9 × planned_units. Severity: high if units_produced < 0.7 × planned_units, otherwise medium. Exceptions must be materialized as rows in a database table with a status column (open, acknowledged, resolved).
    \n
    3. \n
  3. \n
    API
    \n
    Build a REST API (any language — FastAPI/Python scores familiarity points):
    \n
      \n
    • GET /exceptions — list, filterable by product_code and severity, sorted by date descending (worst deficit first within day)
      • \n
    • GET /exceptions/{id} — detail with planned, actual, deficit %, and last-7-days trend
      • \n
    • PATCH /exceptions/{id} — set status to acknowledged or resolved; must persist
      • \n
    \n
    4. \n
  4. \n
    Frontend
    \n
    Build a day-by-day timeline inbox (React preferred, any framework accepted):
    \n
      \n
    • Exceptions grouped by date (newest first), worst deficit first within each day
      • \n
    • Collapsible day groups
      • \n
    • Severity badges + filters (by product, by severity) across the timeline
      • \n
    • Click → detail panel with numbers and 7-day trend (table or chart)
      • \n
    • Acknowledge/resolve without full page reload
      • \n
    \n
    5. \n
\n
\n\n \n
\n
Data
\n

Provided Files

\n
\n
\n
actual_production.csv Clean
\n
1,080 rows · Columns: date, plant_id, product_code, units_produced
\n
\n
\n
production_plan.csv
\n
~1,085 rows · Columns: plan_date, plant, sku, planned_units
\n
\n

Note: Column names differ between the two CSVs — you'll need to map them. Look at the data before you load it.

\n
\n
\n\n \n
\n
Submission
\n

What to Submit

\n\n
\n

1. Code Archive

\n

GitHub link or zip file. One command to run everything in README.md; docker-compose up is a bonus.

\n
\n\n
\n

2. Presentation

\n

5–10 minutes max — PPT, video, HTML page, or any format you're comfortable with, covering:

\n
    \n
  • Demo of the app working end-to-end
    • \n
  • Walkthrough of your database schema and key decisions
    • \n
  • Explanation of your process: what you did, what you found in the data, tradeoffs you made
    • \n
  • Walkthrough of your process flow diagram
    • \n
  • Anything you'd do differently
    • \n
\n
\n\n
\n

Inside the Code Archive — Supporting Documents

\n
    \n
  • APPROACH.md — use templates/APPROACH_TEMPLATE.md (~1 page). Include a process flow diagram showing your pipeline from data to UI.
    • \n
  • AI_USAGE.md — use templates/AI_USAGE_TEMPLATE.md. Mandatory & Graded Tools used, key prompts verbatim, where AI was wrong, % split.
    • \n
  • README.md — architecture overview (use templates/ARCHITECTURE_README_TEMPLATE.md if helpful). Include a system architecture diagram.
    • \n
\n
\n
\n\n \n
\n
Resources
\n

Templates

\n
\n
\n 📄 APPROACH_TEMPLATE.md\n 📄 AI_USAGE_TEMPLATE.md\n 📄 ARCHITECTURE_README_TEMPLATE.md\n 📄 INSTRUCTIONS.html\n
\n

All templates are in the templates/ folder. A markdown version of these instructions is in ASSIGNMENT.md.

\n
\n
\n\n \n
\n
Scoring
\n

What Matters

\n

We evaluate submissions on five dimensions (in priority order):

\n
\n
\n 1\n
Data & database — Did you inspect the data, handle its quirks, and design a sensible schema?
\n
\n
\n 2\n
Backend completeness — Working API with correct exception counts, filtering, and status mutation.
\n
\n
\n 3\n
Frontend — Inbox works end-to-end, detail view is correct, status updates without reload.
\n
\n
\n 4\n
AI usage quality — Quality of prompts, evidence of verifying AI output, honest reporting.
\n
\n
\n 5\n
Communication — Clear approach doc, architecture diagram, and presentation.
\n
\n
\n
\n\n \n
\n
Rules
\n

Expectations

\n
\n

Using AI (Claude Code, Cursor, ChatGPT, Copilot…) is expected and encouraged. We are evaluating how well you drive it, not whether you avoided it. Hiding AI use, or an empty AI_USAGE.md, is a rejection signal.

\n

If you're looking for AI help: Open Code has free built-in LLMs (DeepSeek V4 Flash Free, Nemotron Ultra) that are enough to get the work done. If you already have a subscription to another tool, use whatever you're comfortable with.

\n

One hint: Look at the data before you load it.

\n
\n
\n\n \n
\n Dataset derived from the Store Item Demand Forecasting Challenge (Kaggle). Licensed under the competition rules.
\n \n
\n\n
\n\n\n"}}}}