Labs for DS

Science Stock Footage Video | Shutterstock

What Labs is like for DS

Labs simulates a fully operational software company that is engineering solutions for real stakeholders at either a cause organization. As a new developer, you will help in cultivating these solutions using the skills and tools acquired at BloomTech.

There are a couple of varieties of Data Scientist: type A and type B. Since Labs is a simulation of a real software company, providing real products to real stakeholders, we need to become type B data scientists. What is a type B data scientist? Is there a type A? Let’s explore.

• Type A Data Scientist: The A is for Analysis. This type is primarily concerned with making sense of data or working with it in a fairly static way. The Type A Data Scientist is very similar to a statistician (and may be one) but knows all the practical details of working with data that aren’t taught in the statistics curriculum: data cleaning, methods for dealing with very large data sets, visualization, deep knowledge of a particular domain, writing well about data, and so on.

• Type B Data Scientist: The B is for Building. Type B Data Scientists share some statistical background with Type A, but they are also very strong coders and may be trained software engineers. The Type B Data Scientist is mainly interested in using data “in production.” They build models which interact with users, often serving recommendations (products, people you may know, ads, movies, search results).

Now with a simple understanding of Labs, let’s take a look at the different staff roles in Labs:

• The ADSL (Associate Data Science Lead) is here to help make the transition from “new Labs learner” to “graduated” as smooth as possible. They can help with technical, administrative, or general questions. You’ll also see them reviewing PRs in the repo.

• The Stakeholder is your business executive. (A real-world “co-op” stakeholder or if a real stakeholder is unavailable, BloomTech staff may fill this role.)

• The DS Manager is here to guide you in major technical decisions during development throughout Labs. They hold Office Hours and Workshops throughout the week. They are here to help you, and hold you accountable, as your data science executive.

• The LPM (Labs Project Manager) is your project manager for Labs. They will conduct the Product Review meetings where they go over the Kanban board (Jira). They also overall progress of the application and where that progress is in relation to the roadmap.

• The RM (Release Manager) is responsible for merging the repo’s pull requests. This means you do not merge any code into the repo, but rather you submit a PR, the PR is reviewed and approved by at least 2 of your peers and/or staff. Once approved, they then confirm your code works and your PR is at least passable (score of 4 or higher on the PR Rubric) in order to merge the code.

What success looks like

Success is basically the same for all tracks: Each student is able to show & tell their work experiences during job interviews.

Your projects don’t speak for themselves. It’s the opposite: Your projects give you something to speak about in interviews and Labs gives you ample opportunity to hone those skills.

The Labs experience is consistent with this advice from a hired DS student:

Hey DS1, I just wanted to let you guys know, “Trust the process.” I was offered a job Monday! A job I always dreamed of having, but never really thought was possible before BloomTech.

The amount of interviews I failed before getting a hit? 40+. Sometimes interviewing really sucks. Sometimes it's not easy to feel embarrassed or ashamed at failing. But tomorrow is another chance to do better. If I could give two pieces of actual advice:

1. If you have a cat or dog, you should seriously start practicing teaching them statistics and machine learning. I knew many of the answers to interview questions, but failed horribly at explaining them. It turns out explaining things is a skill all of its own, and it won't be long before my cat is making his own models 😅

2. Have amazing visualizations. No one wanted to look at my code, everyone wanted to see the end result.

Visualizations should be a summarized representation of the entirety of your project. Make sure it represents all your work.

I also discovered people love seeing smaller visuals to summarize the unique parts of your project. I don't know why, but people really just didn't want to talk 20 minutes about code, they want something to look at!

“Visualization” means any visual from your project:

• Architecture diagrams

• Code snippets

• Data visualizations

• Database schemas

• Flowcharts

• Trello boards

• UI screenshots

• UX videos / animated gifs (short, silent loops)

• Wireframes

In interviews, you’ll rarely do product demos, and never do product “pitches”; however, you will always talk about your projects.

These are better than fumbling through a live demo. You’re not pitching your finished product. You’re pitching yourself, and employers want to see your problem-solving process. We’ll help prepare you in Labs!

View these great examples from data scientists in recent Labs cohorts:

• Aaron Watkins, Citrics

• Elizabeth Ter Sahakyan, Cryptolytics

• Lori Schlatter, Story Squad

• Tobias Reaper, Trash Pandas