Successful AI projects mirror data science: define the problem, gather data, build a baseline, evaluate honestly, deploy with monitoring, and iterate. Skipping problem framing causes expensive science projects that never ship.
End-to-end stages
- Problem — user outcome, not "use AI"
- Data — sources, labels, privacy, bias checks
- Baseline — rules or simple model for comparison
- Model — train, validate, tune with held-out data
- Evaluate — metrics aligned to harm and business KPIs
- Deploy — APIs, batch jobs, edge devices
- Monitor — drift, errors, feedback loops
Baseline sketch
# Conceptual workflow checklist
stages = ["problem", "data", "baseline", "model", "evaluate", "deploy", "monitor"]
for i, stage in enumerate(stages, 1):
print(f"{i}. {stage}")Practice: Copy optional Python pseudocode into a local .ipynb notebook or REPL. This track is read-focused (execution_profile: none)—no in-browser AI lab; literacy first, not model training.
Common failure modes
- No baseline—cannot prove ML adds value
- Training metrics look great but production data differs (drift)
- Missing human review for high-stakes decisions
Pair with data science workflow lessons on exploration and communication.
Important interview questions and answers
- Q: Why baseline first?
A: Proves ML beats simpler alternatives and sets evaluation bar. - Q: Monitor after launch?
A: Data and user behavior shift—models decay without retraining and alerts.
Self-check
- List the seven workflow stages in order.
- Name one failure mode when skipping monitoring.
Challenge
Walk the seven stages
- Pick a product question (not "use AI").
- List data sources and gaps.
- Define a non-ML baseline.
- Sketch train/val/test split type.
- Name one launch metric and one harm metric.
- Plan monitoring owner.
Done when: you can explain each stage without skipping problem framing.
Interview prep
- Why baseline?
- Proves ML adds value over rules or simple heuristics.
- Monitor after launch?
- Drift and user behavior change degrade models without retraining and alerts.