Want to break into data science? Start building
Why you should build first and ask questions later
This post was inspired by a Twitter thread that got a lot of love.
Landing a job as a data scientist, machine learning engineer, or really any kind of role writing software takes more than just math and programming knowledge. In reality, these roles require you to make hundreds of decisions every day.
These might be big decisions, like:
- How and where should I store my data?
- Which algorithm(s) should I use?
- Which frameworks and libraries should I use?
- What platform(s) do I use to host my model?
Or tiny decisions, like:
- What do I name this function?
- Which formatting rules should I follow?
- How do I handle this edge case?
Getting better at making these decisions requires practice, and the only way to get that practice is to build things. This is why we strongly encourage the mentors and mentees at SharpestMinds to focus on building end-to-end ML projects. Collect and clean the data, train a model, deploy it. There are so many decisions of varying size hidden in that pipeline.
The pressure to build an end-to-end project forces you to make a lot of choices—similar to the ones you would make on the job building real products. In fact, it helps to think about your data science project as a product. Instead of just training a model to prove that you can, try to solve a real problem.
There’s no need to take this analogy too far. Building a profitable business as a hobby project, though impressive, would be overkill. The benefit of treating your project like a product is that encourages you to start with a problem and find a solution. The tech stack you use and the decisions you make while building will depend on the constraints imposed by the problem.
It’s rare in industry to go the other way—to start with a piece of technology and try find a way to use it. Yet this is the path many hobby projects take. If your only tool is a hammer, and that hammer is a deep neural net, then every problem starts to look like a deep learning nail. But most nails don’t need a neural net — they need a hammer, or maybe just a rock.
Companies don’t hire people because they know a specific type of algorithm (though data science interviews can sometimes make it look that way). Companies hire people to solve problems, to pick the best tools for the job, to make the right decisions.
Building something to solve a real use-case will introduce trade-offs that you don’t see in cookie-cutter data science projects and Kaggle competitions. If there is a real person on the other end waiting for results, you might need to optimize for inference time rather than accuracy. If it is a highly regulated industry, privacy and interpretability will be more important. These are the kinds of trade-offs you will have to make on the job.
It’s hard to get good at these decisions and trade-offs without experience. For many professions, you need to land a job to start accumulating that experience. But there is a wonderful difference when it comes to data science and machine learning—you can get plenty of experience before getting hired. How? By building things.
When you start building, the answers to the hundreds of decisions you’ll face won’t be obvious at first. You will make mistakes. But these mistakes are where the learning happens. Halfway through building, you might realize that your original choice of framework doesn’t support the functionality you need. But next time you face a similar decision, you will be more informed having experienced that mistake first-hand.
These types of mistakes also make great stories for interviews. Explaining the challenges you faced and the lessons you learned from building something is a great way to show off your problem solving skills and ability to learn. “I originally implemented this with X, but it turns out X is not very good at handling Y so I refactored to use Z.” That is the kind of story I would love to hear from a candidate — with more details of course.
However, there is a cold-start problem when it comes to building end-to-end machine learning projects. As a beginner, it’s easy to get get stuck trying to decide what the “best” framework or the “right” database is for the job. I see folks get stuck in this planning trap often. I’ve been there as well.
The way out of the trap is to realize that action is better than inaction. Start with the tools you’re most comfortable with. They will let you build faster and learn quicker. If they are the wrong tools, you’ll find out why from direct experience. If you’re completely new, just pick one of the popular tools and learn as you go. TensorFlow vs. PyTorch, PostgreSQL vs. MySQL—if you don’t know the trade-offs, it doesn’t really matter. Pick one and start building. That is the only way you will begin to learn the trade-offs.
