I’m Daliana Liu, I’m a senior data scientist at Amazon. I build ML models to help AWS customers accelerate their business.
I used to work as a statistician/BIE, and when I got interested in ML, I took an internal ML course in Amazon, and also started to use ML in my projects to gain hands-on experiences. Courses are great for you to understand the knowledge, and work experience helps you transition to the role, and you need both.
Depends on the project cycle. In the beginning of the project, I spend a lot of time meeting customers, understand the requirements. Once the project is defined, we work on getting the data, understanding the data, creating exploratory analysis. This part might take longer than expected, and once data is ready, we start model training, and in this stage we spend more time writing code, reading papers, and having discussions with colleagues.
Once a week, we’ll sync up with customers to get feedback and give updates. Towards the end of the project, we work with engineers to deploy the model, and might have more meetings with customers to make sure it meets their goal. When the project is almost finished, we start documenting the project, and will spend most of the day writing.
Work with them to see what’s their biggest pain point, what’s most manual and what has most data ready
ML is a team sport and you don’t need to do everything on your own.
It’s great to have the skill sets of data engineering to create ETL jobs. SDE skills for deployment work, but if you feel they take too much time from your modeling work, find collaborators. There are people with different skill sets that are interested in ML work and you don’t know whether they want to help you until you ask.
Be a leader.
Even if your title is IC you are still a leader, it means that you need to know when and how to leverage resources. ML projects fail often because of the lack of ownership/leadership when stakeholders and partners are not aligned.
What does it mean to be a leader? It means that when business and moving slow, you put out on the business hat to help them identify the issue and keep the momentum; if the data needs to be put in the pipeline, you put on the DE hat; when evaluating model performance to current status, you put on the product manager/business analyst hat to dive deep into the metrics and use case; when thinking about the launch, put on the user researcher hat to understand the customers.
Through all these hat-juggling, you are the unofficial program manager to make sure every part is moving in the right direction
Wearing multiple hat doesn’t mean you do everything on your own, it means you take the initiative to learn other collaborators skills enough to know how to work with them and speak their language
Sometimes when things are not moving, it could be issues with leadership buy-in and you might not be invited in the room when those discussions happen. If you have doubt, communicate with stakeholders to gauge their interest.
Instead of pitching your ideas. Sometimes it’s more important to listen and gather puzzle pieces of what could be the block of the project.
You might say, your managers or your TPM should do so, but they might not know the details and progress as you do, and not have the relationship you built when you collaborate with people
Being an owner is the way that you make sure your work will be delivered. If you just stay in the science and modeling bubble, it’s possible that your stakeholder changed their interest or has re-org that could affect the project, but you don’t even know.
They focus on solving the problem, understanding the data, instead of focusing on the model.
You don’t have to spend 3 months to improve 1% accuracy. It’s important to know when it is good enough for the constraints of the project.
Read more mentor interviews?