What Makes Data Science Different From Other IT Careers

Same problem, two roles — "users are churning":

DEVELOPER receives:
  Ticket: "Add a save button to the settings page"
  Success: button works, no regressions
  Time: 2 days
  Deliverable: a deployed change

DATA SCIENTIST receives:
  Problem: "Users are churning. Can you help?"
  Success: identify drivers, quantify them,
           propose an intervention
  Time: 3-6 weeks
  Deliverable: an analysis with recommendations

What the DS actually does:
  1. Define churn precisely. 30 days? 60 days?
     Logged out? Cancelled? Silent?
  2. Find the right data. In 3 systems.
  3. Join and clean it. Discover that
     "active user" means 3 different things
     in 3 different teams.
  4. Explore.
  5. Model.
  6. Validate.
  7. Recommend one intervention.
  8. Present to a VP who says "but what
     about the pricing change last quarter?"

None of that was in the spec.
Because there was no spec.
That's the job.

What developers sometimes assume about DS:

✗ "You just call model.fit()"
  Reality: 60-80% is data work, and the
  modelling is often the last 10%.

✗ "You can give me a number I can ship"
  Reality: the answer is "probably, if
  we assume X, and the confidence is Y".

✗ "You can tell me exactly what to do"
  Reality: DS gives recommendations with
  uncertainty. The decision is still a
  business call.

✗ "It's like machine learning engineering"
  Reality: DS focuses on the question and
  the analysis. MLE focuses on the service.
  Different jobs, often confused.

✗ "It's easy because you don't ship code"
  Reality: the code is often notebooks —
  but shipping the insight to a business
  decision is harder than shipping a
  feature that a few hundred users touch.

What developers are right about:
✓ Debugging matters
✓ Code quality matters
✓ Clean abstractions matter
✓ Writing things down matters

The best DS teams have both kinds of
engineers, and they respect each other's
work. But the work is not the same.

MLOps — the bridge between DS and DevOps:

DS produces:
  - A trained model (pickle, ONNX)
  - Feature engineering code
  - An evaluation report

DevOps produces:
  - A deployable container
  - A CI/CD pipeline
  - Monitoring and alerting

MLOps combines them:
  - Model versioning (MLflow, DVC)
  - Feature stores
  - Model serving (TorchServe, Triton, BentoML)
  - Model monitoring (data drift, prediction drift)
  - Model retraining pipelines

The career picture:
  - DS without MLOps: models don't leave notebooks
  - DevOps without DS: pipelines deploy nothing useful
  - MLOps: the role that makes DS work in production

The honest overlap:
✓ Both use Docker
✓ Both use cloud
✓ Both use Python
✓ Both care about latency
✗ Only DS does statistics
✗ Only DevOps handles the K8s cluster
✗ Only DS frames the business question

If you're DS and want to be more hirable:
Learn basic MLOps (Docker, model serving,
basic monitoring). You don't need to become
a DevOps engineer. You need to deploy your
own model.

Why DS and DevOps get confused:

Common confusion 1 — "Aren't they both
about automating stuff?"
  DevOps automates infrastructure.
  DS automates decision-support.
  Different automation targets.

Common confusion 2 — "Doesn't DS need cloud?"
  Yes, but for running models. DevOps builds
  the cloud. DS uses it.

Common confusion 3 — "Isn't MLOps just
DevOps for ML?"
  Roughly, yes. But it requires DS fluency
  (knowing what drift means, why a model
  is stale) that DevOps usually doesn't have.

Common confusion 4 — "Doesn't data science
need a platform team?"
  Yes — and the platform team is often
  DevOps/MLE/MLOps, not DS.

The honest split:
  DevOps engineer → ships services reliably
  DS → answers questions from data
  MLE → ships models as services
  MLOps → builds the platform for DS/MLE

These are all different. They just sound
similar from outside the industry.

For career planning:
- If you like uptime and infrastructure → DevOps
- If you like questions and analysis → DS
- If you like both → MLE or MLOps
- If you're not sure → try a small DS project
  and a small Docker deployment. One will
  feel more natural.

Same feature, three roles — "checkout":

QA asks:
  - Does the flow work on all browsers?
  - Does it fail gracefully?
  - Are there race conditions?
  - Have we tested the error paths?
  Deliverable: a bug list and a test suite.

DESIGN asks:
  - Is the flow obvious to a new user?
  - Are the trust signals visible at the right
    moment?
  - Does the empty state feel intentional?
  Deliverable: a designed experience.

DATA SCIENCE asks:
  - What fraction of users drop off at each step?
  - Which segment drops off most?
  - Does the drop correlate with anything we
    can change?
  - If we changed one thing, what would
    the impact likely be?
  Deliverable: a quantified recommendation.

These are complementary, not competing.
A team without DS ships features that work
but might not matter.
A team without QA ships broken features.
A team without design ships confusing features.

The DS contribution is specific:
"15% of users drop at the address step,
which costs us ₹40L/month, and fixing it
is worth more than the three features on
the backlog."

That's a very different sentence from a
design critique or a bug report.

Why "user-focused" is not enough to describe DS:

Everyone says they're "user-focused":
  - Product: "I talk to users."
  - Design: "I design for users."
  - QA: "I test what users see."
  - DS: "I look at what users do at scale."

All four are true. But DS does one thing
none of the others can:

It quantifies.

A designer can say:
  "Users seem confused at the checkout step."
A data scientist can say:
  "52% of users abandon checkout at the
   shipping address form; that's 3x the
   industry benchmark, and abandonment
   correlates with the number of fields
   (r=0.71). Reducing from 9 fields to 5
   should recover 8-12% of that lost
   revenue — approximately ₹35L/month."

Both are useful. Only one gets prioritised
in the roadmap. DS earns its seat at the
table by turning qualitative concern into
quantified priority.

This is why DS interviews focus heavily on
"what would you measure?" and "how would you
prove this worked?"

If you like the "why" more than the "how many",
design might fit you better.
If you like the "how many" more than the "why",
DS might fit you better.
If you like both, product management might.

The line between DS and PM is real:
DS answers "what does the data say?"
PM answers "what should we do about it?"

The five things that actually make DS different:

1. AMBIGUITY
   The problem arrives as a vague question, not a
   ticket. You spend the first week defining the
   problem, not coding.

2. DATA AS THE PRODUCT
   60-80% of the job is acquiring, cleaning,
   joining, and validating data. No other IT role
   spends this much time on this.

3. UNCERTAINTY AS THE ANSWER
   The output is never "yes". It's "probably, given
   these assumptions, with this confidence interval".
   Stakeholders must be comfortable with that.

4. BUSINESS METRIC AS THE SUCCESS
   A model with 0.85 AUROC that nobody acts on is
   a failure. A simpler analysis that changed one
   decision is a success.

5. INTERVIEW SHAPE
   DS interviews ask "how would you measure this?",
   "what would you look for?", "how would you prove
   it worked?". Not "write a function that...".

If you like:
- Clear specs → development
- Reliability → DevOps
- Catching edge cases → QA
- Shaping experience → design
- Quantifying decisions → data science
- Deciding what to build → product

DS is not better or worse. It's a different
relationship with uncertainty and with the
business.

Reality check on the five dimensions:

1. AMBIGUITY — real, not romantic
   You'll spend the first week asking questions
   like "what does 'active user' mean here?"
   before you can start analysis. This frustrates
   some people and liberates others.

2. DATA AS THE PRODUCT — not a phase
   In year 3, you'll still be cleaning data.
   The senior DS isn't exempt from this. They
   just do it faster and better.

3. UNCERTAINTY — the hardest part
   Stakeholders want a number. You'll give
   them a range and a caveat. Learning to
   communicate this without losing credibility
   is a skill of its own.

4. BUSINESS METRIC — sometimes out of reach
   Sometimes your analysis lands. Sometimes
   it sits in a slide deck and dies. The job
   includes that failure mode. Many DS careers
   stall because they can't accept it.

5. INTERVIEW SHAPE — case study, not code test
   Interviews test your judgement, not your
   syntax. You'll be asked "what would you
   look for?" more than "write this function".
   Prepare accordingly.

If any of these surprise you negatively,
consider a different IT role.
If any of these excite you, you're probably
in the right field.

How DS interviews actually differ:

ROUND 1 — TAKE-HOME / CASE
  Not "write a function". It's "here's a dataset,
  what would you do?"
  What they test:
  - How you frame the problem
  - What data you'd need
  - How you'd validate
  - What you'd recommend

ROUND 2 — STATISTICS / ML
  Not "prove this theorem". It's "how do you
  know X?"
  What they test:
  - Why accuracy is wrong for imbalanced data
  - How A/B tests can fail
  - What calibration means
  - When correlation implies causation (never)

ROUND 3 — SQL / PYTHON
  Not "reverse a linked list". It's "write a query
  to find churn by segment".
  What they test:
  - Joins, groupby, window functions
  - Pandas fluency
  - Small, real tasks

ROUND 4 — BEHAVIOURAL
  Not "tell me about a conflict". It's "tell me
  about a time you changed a decision with data".
  What they test:
  - Business impact, not technical cleverness
  - How you handle ambiguity
  - How you communicate uncertainty

What you'll rarely get:
✗ Whiteboard DSA (except at some big tech)
✗ "Implement this algorithm from scratch"
✗ System design in the classical sense

What you'll definitely get:
✓ "How would you measure X?"
✓ "What would you do if the data was messy?"
✓ "What would you recommend to the business?"

Prepare accordingly. 70% of your prep should
be case studies and reasoning, 30% code.

Career trajectory — where DS actually leads:

YEAR 0-2: ANALYST / JUNIOR DS
  Focus: SQL, basic stats, reporting,
  learning the business.
  Next: prove you can move a metric.

YEAR 2-4: DS / SENIOR DS
  Focus: own a problem area, run experiments,
  build models.
  Next: prove you can frame a question
  independently.

YEAR 4-6: STAFF / LEAD DS
  Focus: set direction, mentor juniors,
  own a product area's data strategy.
  Next: decide between IC depth and
  management.

YEAR 6-10: THREE PATHS
  A. IC → Principal DS / Staff Data Scientist
     Depth on modelling / experimentation
     ₹40-70 LPA
  B. Manager → DS Manager → Director of DS
     Team building, hiring, process
     ₹45-80 LPA
  C. Product → Product Manager → PM Lead
     Decide what to build, use data to argue
     ₹40-80 LPA
  D. Engineering → MLE → MLOps Lead
     Ship models as services
     ₹35-60 LPA

What the trajectory requires at each stage:
- Analyst → DS: one successful analysis
- DS → Senior: ownership of a metric
- Senior → Lead: mentoring + strategy
- Lead → Principal or Manager: choice

What stops the trajectory:
✗ Never shipping a recommendation that lands
✗ Avoiding stakeholder conversations
✗ Staying in notebooks without business context
✗ Optimising model metrics over business outcomes

Notice the pattern: technical depth gets you
in, business impact gets you up.

Choosing between IT roles — an honest checklist:

If you enjoy:

Clear spec, clear code → DEVELOPMENT
  You like finishing a ticket, seeing it ship,
  knowing it works.

Keeping things running → DEVOPS
  You like the idea of a system that never
  fails, and the feeling of an empty on-call
  log.

Finding edge cases → QA
  You like breaking things, thinking about
  what could go wrong.

Shaping experience → DESIGN
  You like thinking about the user's emotion,
  their flow, their trust.

Quantifying decisions → DATA SCIENCE
  You like turning "I think" into "the data
  shows", and defending a number.

Deciding what to build → PRODUCT
  You like the trade-off between ideas,
  talking to everyone, and owning the outcome.

None of these is superior.
All pay well at the senior level.
All have career paths and ceilings.

The wrong choice is picking by salary alone.
The right choice is picking by what you
want to do on a Tuesday at 10 AM in year 5.

If you can't decide, try a small project
in two of them. The one you finish
without forcing yourself is the answer.