The problem you will solve
A small retailer needs next-week daily demand estimates for stock planning. The useful question is whether a model improves on last week's same-day sales, not whether it produces an impressive random-split score. Keep promotions known before prediction separate from outcomes recorded afterwards.
Before you start
Tabular data cleaning, regression metrics and train/test separation.
Suggested tech stack
Data plan
Generate two years of daily synthetic sales for five products, with weekday patterns, missing days and one demand shift. Store the generator seed. Declare that synthetic performance does not prove real retail performance.
Hardware and cost
Keep the dataset and neural baseline small enough for CPU training. Start with a seasonal naive forecast; a large model is unnecessary for this exercise.
Define the input and output
Use this illustrative contract as a starting point, then specify required fields, validation and error responses in your own implementation. It is not a complete API schema.
Input: {"product":"P1","forecast_date":"2026-10-01","horizon_days":7}
Output: {"predictions":[{"date":"2026-10-02","units":18}],"model_version":"v1"}Your five build milestones
Finish and test one milestone before extending the system. Keep an experiment log with the decision, the alternative you rejected and the evidence behind the choice.
Specify prediction time
Write down exactly when a forecast is made and which fields are available then. Build a dated data dictionary and forbid post-sale outcomes from the feature set.
Make a chronological baseline
Reserve the final eight weeks for testing. On earlier data, compute same-weekday-last-week predictions and their mean absolute error by product.
Train with rolling windows
Construct lag and rolling-mean features using only prior dates. Tune a small model on rolling validation windows, never on the final test interval.
Package prediction
Bundle feature transformations and model version together. Validate missing dates and unknown products in an API; return an explicit error instead of an arbitrary forecast.
Explain the trade-off
Compare model and baseline on the same final dates. Include demand-shift failures, per-product errors and a rerunnable training command in the repository.
How to evaluate your project
Set your acceptance criteria before looking at the final test results. The checks below are proposed experiments, not measured outcomes or a guarantee that a particular model will pass.
- Report MAE by product and by forecast horizon, alongside the seasonal baseline.
- Add a test asserting that changing future sales cannot change an earlier prediction's features.
- Evaluate missing dates and sudden demand shifts separately; do not hide weak products in an overall average.
Save your test cases, run command, dependency versions and results together. Compare on identical inputs, retain failures in the denominator and report sample sizes. If a change improves one metric but harms another, explain which trade-off fits your use case.
Failure modes worth demonstrating
- Random splitting puts future patterns into training.
- Computing rolling statistics before shifting by a day leaks the target.
Optional extension
Track an uncertainty interval and compare empirical coverage rather than claiming every prediction is precise.
Turn the build into portfolio evidence
Your repository should let another person understand the problem and reproduce the core evaluation without needing your private credentials.
- A README with problem, intended user, architecture, setup commands and a small input/output example.
- A permitted sample dataset, its origin or generator, a frozen test split and a single evaluation command.
- A results table comparing your baseline with your final approach, including failures and sample counts.
- A short demo or screenshots, a limitations section and one decision you would change with more time.
- Environment-variable names without secret values, a dependency list and attribution/license notices for any reused code or datasets.
Resume framing
Describe this as a personal or educational project. State what you implemented, how you tested it and what your measured results were. Replace placeholders with your own evidence; do not claim employer impact, production traffic or accuracy you did not measure.
Built demand forecasting without future leakage using Python, pandas, NumPy; evaluated against [baseline] on [N held-out cases], documented [measured result] and [important limitation].Be ready to explain your decisions
- When could a seasonal baseline beat your model?
- How did you prove feature availability at inference time?
Answer with a concrete failure from your implementation, the options you considered, your measured evidence and the limitation that remains.
Google documentation and GitHub references
The project scope, milestones and evaluation plans above are original AIJobFever educational material. These official Google resources offer background or implementation examples; they are not finished implementations of this blueprint. No Google endorsement is implied. Review repository licenses, supported platforms and current costs before reusing code or provisioning services.
Our editorial policy