About getting a job with machine learning, things you should do during an interview, and some random thoughts that may help you land a job
↓
Before getting a job or making any money, you need to show that you are competent.
Put in the work right now and level up.
There are no hacks, no shortcuts, or magic words that will convince anyone to pay you for something you don't know.
↓
You don't need to get a Ph.D. or a Master's to work as a machine learning practitioner.
I understand many companies are still asking for a degree, but there are many that aren't.
Find and apply to those.
↓
Most of the time, you can start with machine learning without moving to another company, changing departments, or doing something radical with your life.
Don't look at this as "switching." Instead, look at this as "augmenting" your knowledge base.
↓
As demand increases, companies are willing to lower the bar they expect from candidates.
As the machine learning field matures, specializations become more important.
We will continue to see an explosion in open positions. The time to get ready is today!
↓
You can follow two different strategies when you start:
1. Aim to become the best machine learning practitioner you can be.
2. Aim to shorten the path from learning to getting a job.
Understand your goal. Understand that these two strategies don't always overlap.
↓
Nothing is more powerful than showing what you have done.
Yes, you can talk all you want, and your résumé may be great, but none of that will beat a strong portfolio.
• Solve problems.
• Write about them.
• Be ready to have a discussion.
↓
Many people feel that getting their first machine learning job is a catch-22: they can't get it because of no experience.
I see it as an opportunity: a blank slate to build the experience you want instead of working on what some else wants.
↓
Companies are looking to de-risk their hiring decisions. An experienced candidate is less risky.
You think they care that you worked for IBM, but they care much more that you worked on the same problems they need to solve.
What problems do you want to get good at solving?
↓
If you pick an area to specialize in and focus on it, you won't be able to apply to a fifth of the open positions out there.
But you'll increase your chances of getting hired by 10 fold.
Do the math. Pick your battle.
↓
You are probably looking for a recipe:
• Get foundational knowledge
• Solve problems
• Network with people
• Chose an area to specialize
• Solve toy problems
• Solve more complex problems
• Write about the solutions
• Prepare for interview
• Apply to job postings
↓
There are two parts to an interview:
• The part where they ask questions
• The part where they get to know you
For the first part, you need to study. The Internet is plastered with mock interviews and questions that they will ask.
Ace this part.
↓
Yes, a lot of companies ask stupid gotcha questions and data science trivia during an interview.
It sucks, but it's the game we all have to play.
Complain if you want, but prepare for it.
If you don't play, you don't win.
↓
The second part of the interview is the deciding factor between candidates.
This is your opportunity to beat everyone else!
Follow a three-step approach:
• Show what you have
• Blow them away
• Make them fall in love with you
↓
How do you blow them away?
One way is by showing the depth of your work:
• You hosted your model
• You built an API around it
• You set up monitoring
• You built a retraining pipeline
• You thought about versioning
• You thought about automating deployments
↓
Your GitHub portfolio should have:
• Every problem you have solved
• A full write-up of the analysis
• Fully reproducible code
• An explanation of the value of this solution
You can do this for real projects. You can do this for mock exercises.
↓
Showing ambition is a great way to show off and make them fall in love with you:
Think about a big-shot problem and develop some ideas to solve it.
You don't need to find a solution. You only need enough to have a conversation with your interviewer.
↓
Also important: be familiar with the latest and greatest research within your specialization domain.
You don't need to be an expert, but you have to understand where the world stands.
↓
I've interviewed dozens of people, and I can tell you the bar is really low for anyone willing to put in the work.
You usually need one good tactic to impress. More than one, and you'll obliterate that interview.
And no, this is not easy. But it's doable.
↓
If you are looking for more content like this, follow me @svpino.
I focus on practical machine learning and come here every day to tell you what's up with this thing.
And for a more polished take, subscribe to digest.underfitted.io. You won't regret it.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A lot in machine learning is pretty dry and boring, but understanding how autoencoders work feels different.
This is a thread about autoencoders, things they can do, and a pretty cool example.
↓ 1/10
Autoencoders are lossy data compression algorithms built using neural networks.
A network encodes (compresses) the original input into an intermediate representation, and another network reverses the process to get the same input back.
↓ 2/10
The encoding process "generalizes" the input data.
I like to think of it as the Summarizer in Chief of the network: its entire job is to represent the entire dataset as compactly as possible, so the decoder can do a decent job at reproducing the original data back.
We usually talk about two main types of machine learning models:
• A Classification model
• A Regression model
They are different, and it's essential to understand why.
↓ 1/6
Whenever the result of your predictions is categorical, you have a classification model.
For example, when your prediction is a binary value (True or False,) or when you want to predict a specific animal from a picture (Lion, Zebra, Horse.)
↓ 2/6
If the result of your predictions is numerical, you have a regression model.
For example, returning a stock's future price, the value of a house, or tomorrow's temperature.
Here are my thoughts about the "HTML is not a programming language" recurrent theme.
↓ 1/5
This question is controversial not because people care about HTML but because it is used as a proxy to classify their worth.
If HTML is not a programming language, then the people working with HTML must not be real programmers, right?
↓ 2/5
This is demeaning and completely unhelpful for those who are starting and looking to find a community.
Instead of drawing lines, we should be welcoming those who want to join us. We need more programmers, coders, developers, or whatever else you want to call them!