# How to Become a Better Data Scientist: The Definitive Guide

Alexey Grigorev, OLX Group | MLOps Meetup | Episode 24 | 1:00:42
Hosted by Demetrios Brinkmann

Source: https://www.youtube.com/watch?v=f531HULH8KA
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/how-to-become-a-better-data-scientist-the-definitive-guide
Published: 2020-07-10
Tags: careers, deployment, engineering-culture

## TL;DR
- A full-stack data scientist can own a machine learning project from defining the problem through deployment without being an expert in every part of the process.
- Data scientists become more useful when they understand product work, communicate clearly, and learn enough infrastructure to work independently in a safe environment.
- The best way to learn tools and theory is to start with a real problem, use the available abstractions, and go deeper only when the problem requires it.

## Summary
Alexey Grigorev describes a full-stack data scientist as someone who can own a machine learning project from requirements gathering to deployment. This does not mean becoming an expert data engineer, DevOps engineer, and machine learning researcher at once. It means knowing what each stage involves, doing the basics, and asking for help when necessary. He recommends using staging environments or separate clusters for infrastructure experiments, then earning access to production through repeated, trusted work. Grigorev also argues that data science roles are splitting between analytics-focused work and engineering-focused machine learning work. As tools make model training easier, connecting systems and making models useful in products will still require software engineering. He advises learners to focus on problems instead of trying to master every model or tool first. Communication, documentation, product thinking, and practical projects matter as much as technical skills.

## Key ideas
### A full-stack data scientist owns the whole machine learning cycle
[07:58](https://www.youtube.com/watch?v=f531HULH8KA&t=478s)
Alexey Grigorev defines a full-stack data scientist as someone who can own a machine learning project end to end. That starts with collecting requirements, talking to people, and deciding whether machine learning is needed at all. The work then includes preparing data, training and evaluating a model, deploying it, and checking how real users interact with it. He contrasts this with focusing only on modelling. The goal is not to perform every task at an expert level. It is to understand the whole process well enough to move a project forward and identify where specialist help is needed.

### Breadth is realistic when it means basic working knowledge
[09:59](https://www.youtube.com/watch?v=f531HULH8KA&t=599s)
Grigorev rejects the idea that a full-stack data scientist must be a superhero who can do every job alone. Each stage of a machine learning project can require several specialists. A data scientist can still work across the stages by learning the core activity at each one. For requirements, that means talking to people and prioritising needs. For data preparation, it may mean learning where the data is and how to extract it. For deployment, it can mean creating a simple Kubernetes service that scales, without managing the Kubernetes cluster. Asking for help is part of the role, especially after making a genuine attempt.

### Small infrastructure skills can remove long waits
[13:33](https://www.youtube.com/watch?v=f531HULH8KA&t=813s)
Grigorev learned infrastructure because waiting for busy engineers could block his work for months. His advice is to ask an infrastructure or DevOps engineer to teach the smallest useful set of skills. In his example, an engineer suggested installing Minikube and following a tutorial covering pods, services, and deployments. They did one deployment together, after which Grigorev could repeat the work independently. He says this made him less dependent on other teams and helped him iterate faster. The point is not to replace infrastructure specialists. It is to avoid making them perform every small task needed to test a data science idea.

### Use staging as a safe place to learn deployment
[16:48](https://www.youtube.com/watch?v=f531HULH8KA&t=1008s)
Grigorev separates experimentation from production access. In many projects, he did not have permission to touch production, but he could work in staging. A staging environment or separate cluster gives a data scientist room to experiment without risking live systems. Once a deployment is stable and tested, infrastructure engineers can move it to production with less work. Repeated, careful deployments also help build trust. He recommends asking for help when needed and showing that the service works before requesting a production change. This approach lets a data scientist learn infrastructure while keeping operational risk contained.

### Data science roles are splitting toward analytics and engineering
[21:42](https://www.youtube.com/watch?v=f531HULH8KA&t=1302s)
Grigorev sees the data scientist title dividing into different types of work. In some United States companies, data scientists focus on SQL, business insights, and experiments such as A/B tests. In Europe, he more often sees roles that combine SQL, Python, pandas, machine learning frameworks, Flask, and Docker. He expects some of these engineering-oriented roles to be called machine learning engineer. As automated machine learning tools make model creation easier, he expects more attention to connecting tools, understanding the business domain, and building software that can use the model. The role may change names while the underlying work continues.

### Tool choice should follow the problem
[28:52](https://www.youtube.com/watch?v=f531HULH8KA&t=1732s)
Grigorev advises learners not to study every algorithm, framework, and infrastructure tool before solving a real problem. Someone predicting churn can begin with a library, set up cross-validation, and treat the model as a black box. They can learn the mathematics later when the work requires it. For MLOps, he recommends looking at the tools already available in the organisation and using them to solve a specific deployment problem. If no suitable tool exists, build a small prototype, inspect what it does, and decide whether it is useful. This keeps attention on delivering a working solution instead of collecting disconnected knowledge.

### Kaggle teaches modelling, while production adds problem definition
[37:31](https://www.youtube.com/watch?v=f531HULH8KA&t=2251s)
Grigorev is clear that Kaggle competitions are different from a data science job. Kaggle develops skills in feature creation, model tuning, and cross-validation, and it exposes learners to machine learning problems and evaluation metrics that others have already defined. Real work also requires formulating the problem, collecting and preparing data, and deciding what success means. Competition participants may spend substantial effort improving a score by a small amount, while most products do not need that degree of precision. He still recommends following several competitions, even passively, because seeing different problems and winning approaches broadens a learner's understanding.

### Communication and product partnership affect technical impact
[41:35](https://www.youtube.com/watch?v=f531HULH8KA&t=2495s)
For Grigorev, communication is a core part of data science work. Before solving a problem, the data scientist needs to understand what the problem is, who it affects, and why the organisation is solving it. Afterward, they should demonstrate the result, explain complex ideas in simple words, write useful documentation, and communicate with stakeholders. When proposing a new framework or tool, he recommends first convincing the product manager. The product manager can help explain the value to the wider organisation and can give feedback on the data scientist's presentation, writing, and communication. Technical work has limited value when nobody understands the problem it addresses.

### Pet projects can create infrastructure experience
[51:15](https://www.youtube.com/watch?v=f531HULH8KA&t=3075s)
When a data scientist has no infrastructure opportunities at work, Grigorev recommends building a pet project. The project does not need to serve a huge number of users. It should take an idea from an initial concept to a prototype and then deploy it to AWS or another cloud. That process provides practice with deployment and gives the learner something concrete to put on GitHub or describe in an article. The project may also help create an opportunity inside the current company, because the data scientist can show colleagues what they learned and ask to apply those skills to a work problem.

## Notable quotes
- Alexey Grigorev: "A full-stack data scientist is somebody who can do the whole cycle, who can own the ML project end-to-end." (08:25)
- Alexey Grigorev: "We don't need to be experts in everything, so just to know a little bit of each." (10:47)
- Alexey Grigorev: "Focus on the problem and just don't try to spread your attention to too many things at the same time." (30:22)
- Alexey Grigorev: "Competing on Kaggle is not the same as working as a data scientist." (37:31)
- Alexey Grigorev: "The best thing you can do here is try to team up with your product manager." (44:46)

## Tools & references mentioned
- OLX Group
- Kubernetes
- Minikube
- AWS
- Amazon EC2
- Kaggle
- Python
- pandas
- Flask
- Docker
- scikit-learn
- XGBoost
- TensorFlow
- Spark
- Designing Data-Intensive Applications
- Andrew Ng
- Coursera
- Stanford University
- Machine Learning Bookcamp
- Mastering Java for Data Science

## Who should watch
- You are a data scientist who wants to work beyond notebooks and understand deployment without becoming a full-time infrastructure engineer.
- You are learning data science from a software engineering background and want a project-led route into machine learning.
- You work on simple models and reports but need a practical way to gain infrastructure experience and demonstrate it to your employer.

## Related talks

- [All Data Scientists Should Learn Software Engineering Principles](https://mlopstalks.com/talks/all-data-scientists-should-learn-software-engineering-principles) (Catherine Nelson, Freelance Data Scientist, 52:55)
- [Why Data Scientists Should Know Data Engineering](https://mlopstalks.com/talks/why-data-scientists-should-know-data-engineering) (Dan Sullivan, 58:28)
- [Data Scientists & Data Engineers: How the Best Teams Work](https://mlopstalks.com/talks/data-scientists-data-engineers-how-the-best-teams-work) (Beverly Wright, Wavicle Data Solutions & Sadie St. Lawrence, Human Machine Collaboration Institute / LinkedIn Learning & Joe Reis, Ternary Data & Victor Cuadros, Microsoft, 27:55)
- [How To Move From Barely Doing BI to Doing AI](https://mlopstalks.com/talks/how-to-move-from-barely-doing-bi-to-doing-ai) (Joe Reis, Ternary Data, 53:47)
- [AI Operations Without Fundamental Engineering Discipline](https://mlopstalks.com/talks/ai-operations-without-fundamental-engineering-discipline) (Nikhil Suresh, Hermit Tech, 49:28)