
You did it! You have studied, completed your degree(s), and battled through translating formulas to code. You’ve cut your teeth on some analytics projects and remembered to clean up your GitHub account. You successfully ran the interview gauntlet. You have landed that coveted Data Scientist role. It is time to dig in and get to work. You have been chosen because you’re smart, you’re confident in your coding chops and you’re productive. Those are great traits, but do not let them lead you astray. If you want to avoid a world of frustration and a quick exit, be sure to avoid these three mistakes.
You’re Smart: Ignore the Subject Matter Experts
You have a master’s degree in statistics and a PhD in physics. You contribute to open source projects. You rock the pub quiz nights! You got this.
Yes, you got this, but not alone.
Your SMEs will save you from incredible confusion and rework. They will prepare you for the difficult questions that will come from the business sponsor. Brush them off at your own peril.
The project SMEs know the business problem. You can work together to figure out what the most reasonable optimization goal will be. They can also help you measure the success (or "opportunity areas") of the outcomes.
If you are incredibly lucky, your subject matter expert will know the data. They know that in 2018 there was a bug in the system that rendered all data between March 12th and April 10th unusable. They do not think it makes sense that your query returned duplicates (hint: there is something askew with one of your joins – don’t just remove the duplicates). They can help evaluate the leading features and determine if they make any sense at all to the business problem.
You’ve Got Coding Chops: Hoard Your Code
Your code is like art. It contains your personal preferences and trademarks. You have come up with a new technique all your own. You must protect your ideas and lock the code down in your personal library. When someone asks for code, you send them snippets.
This will not be popular with your peers. Code hoarding is done for a variety of reasons, none of them exude confidence or transparency. The advice to avoiding all of these is the same. Be Humble.
Sharing your code for the first time is intimidating. If you ask for feedback or a review of small portions of code during the development process, you will build confidence sharing your final product with others. Testing the heck out of it helps as well.
On the opposite end of the spectrum, hoarding code to make yourself ‘indispensable’ with your unique skills will not Work out like you think. You will, at best, corner yourself into a niche role. It may feel safe now, but it usually does not turn out well over the long haul for your career.
You’re Productive: Blow your business sponsors away with detailed formulas, statistics, and graphs
You have worked for weeks to develop a kick-butt algorithm. It is fast, accurate, and interpret-able. It is a thing of beauty. When asked to present your findings to the business sponsor, you build a 20-slide deck (with an appendix of course) worthy of NeurIPS presentation. You practice in front of your mirror at home and you’re ready to go.
Not so fast. You want to be sure you engage your audience so that they are distracted from their phones and laptops. You want eye-contact and some hope that they understand what you are saying.
If you are presenting your work to a variety of roles within your company, you will need to tailor your message to each audience. You may need to create separate presentations entirely with varying levels of detail.
The feedback I have heard over the years is that business sponsors generally do not understand what data scientists are going on about. None of it. Ironically, the solution is NOT to go into great detail about your algorithms.

If you are presenting to a large meeting being held by the business sponsor, keep it simple and focus on business outcomes. If you do not demonstrate your progress towards solving the business problem, you might find your presentation interrupted. Difficult questions will be posed. You may be asked to come back later with a revised deck (if you are asked back at all).
I would recommend having your manager and a trusted peer review your presentation for feedback.
If you are itching to delve into the different feature transformations and algorithms, schedule a meeting with your fellow data scientists. They will ask the questions to help you validate your results and provide valuable feedback. You can geek out together on your choice of activation function.
Obviously, there are many ways to bomb a gig. Share your experiences below to serve as a warning to the others.