Every real deep learning project begins before a single line of model code is written: precisely defining the problem, its success criteria, and its feasibility. This opening note of the full project lifecycle covers exactly that groundwork.
The Core Questions to Answer Upfront
| Question | Why It Matters |
|---|---|
| What exactly is being predicted? | Determines the task type (classification, regression, generation) and everything downstream |
| How will success be measured? | Determines which evaluation metrics actually matter (see the Evaluation Metrics category) — decided before modeling, not after seeing results |
| Is labeled data available, or obtainable? | A deep learning solution is only feasible if sufficient, appropriately labeled data exists or can realistically be collected |
| What's the compute/latency budget? | Shapes which architectures and model sizes are even practical — a huge Transformer isn't viable for a millisecond-latency mobile app |
| What does a "good enough" baseline look like? | Sometimes a much simpler, non-deep-learning approach already solves the problem adequately — deep learning isn't always necessary or justified |
Defining Success Metrics Before Modeling
Deciding evaluation criteria only after seeing model results is a subtle but real failure mode — it invites unconsciously favoring whichever metric happens to look best, rather than the metric that genuinely reflects the problem's real-world requirements. Committing to specific target metrics (e.g. "F1 score above 0.85 on the minority class" rather than vague "good accuracy") upfront keeps the whole project honestly anchored to the actual goal.
A Feasibility Checklist
feasibility_checklist = {
"sufficient labeled data exists or is obtainable": None,
"success metric is precisely defined": None,
"compute/latency budget is known": None,
"a simple baseline has been considered": None,
"the problem is genuinely learnable from the available data": None, # not every problem is!
}
# Answering "no" to any of these is a signal to revisit the problem definition
# before investing significant time in modelingCommon Mistakes
- Jumping straight into model architecture selection before clearly defining what success looks like — this frequently leads to wasted effort building something technically impressive but poorly aligned with what's actually needed.
- Assuming deep learning is necessary without first checking whether a simpler baseline (a linear model, a rule-based system) already performs adequately — added model complexity should be justified by genuinely better performance, not assumed by default.
Interview Relevance
Q: "Why is it important to define your evaluation metric before you start training models, rather than after seeing results?" Choosing a metric after seeing results risks unconsciously favoring whichever number happens to look most favorable for the specific model you've already built, rather than the metric that genuinely reflects the problem's real-world requirements. Committing to specific, precise success criteria upfront keeps the project's evaluation honest and anchored to the actual goal, independent of how any particular model happens to perform.
Practice Question
A team wants to build a deep learning model to detect fraudulent transactions, but only has 200 labeled fraud examples out of 10 million total transactions. What feasibility concerns would you raise before proceeding?
