3 Mistakes to Avoid When Landing Your First Machine Learning Engineer Role
And What to Do Instead
Picture this: you’re lying in bed, it’s nine o’clock at night and all the lights in your room are off. You’re trying to sleep, but tossing over left and right. It’s the night before your job interview — you want to sleep, but you just can’t, and for some reason you’re unable to shake off the voice of one incessant interviewer in your head, asking you over and over:
“How would you explain linear regression to a five-year old?”
Let’s face it, searching for a job — even one as exciting as a Machine Learning Engineer — has its ups and downs. For someone with a nontraditional background (in my case, having gone to an innovative college called Make School rather than a traditional university), you’ll face some things in the interview process that you might not have planned for at all.
I’m writing this to you because although I have not (yet) successfully landed my first full-time, professional role as an ML Engineer, I’ve come close on several occasions. After much reflection, I have three takeaways to share with you today, so you can make it easier on yourself to land that role.
To make sure this is worth your time: here’s a list of all the pieces of advice I’m NOT going to go over in this blog, because I’m sure you’ve heard it before:
- Understanding the conceptual foundations of Machine Learning
- Having practical experience through research, OSS, internships in industry,
- Networking!
- Seeking out a coach who can calm your nerves and guide your focus, and/or
- Doing mock interviews to become more confident before the real thing.
If you’d like to go beyond this advice (which is not to say it’s not legitimately valuable, and you should probably spend 80% of your time on this), then let’s get started.
The Mistakes
#1: The Solutions You Give Are Too Complicated
This lesson took me a painfully long time to learn. About 2.5 months ago I interviewed with an AI team at a FAANG company, which was working on a personal assistant I won’t name (but I’m sure you’ve heard of before). One of their key features was to make sure the assistant gave notifications to users at regular intervals during the week, matching the time of the notification to the time of day they usually check-in that respective app (e.g. getting pinged at 7AM everyday, so you can check the schedule of yoga classes in your area). What was their interview question to me, you might ask?
“So, how would you go about building a recommender system for this feature?”
This memory still stings me: the truth is, at this point I had no idea what a recommender system was. That itself wasn’t the problem — the problem was the next thing I did was blurt out something that confused the interviewer (and myself, to be honest). Here’s a paraphrasing of how it went:
“Oh, well sure! Let me see… well, why don’t we make a bot, that could be used to understand ALL of a user’s habits, and using a convolutional function to predict when the user needs to see a specific notification…”
This is exaggerated, but the point is the same: the interview is the place to keep things clear, and clear communication is simple communication. One of the best things I do now when I get stuck in interviews is to simply ask: ask for a hint, ask for a different question, or a simpler version of the one you have. It’s in the interviewer’s best interest to help you succeed, so trust me that this is not as crazy as you might think!
Enter Recommender Systems
As a side note — for anyone who is looking for a great introduction to recommender systems (with code), I highly recommend this “Recommender Systems in Python 101” Kaggle notebook by Gabriel Moreira.
#2: The Code You Write is Too Slow
Maybe you read this and think, “well, isn’t Python supposed to be slow? What I can do about that?”
The problem here is, you’re actually right (and wrong) about Python.
Let me explain: in another interview process, I was given a take-home assessment by a computer vision startup, and asked to write a foundational algorithm (which I guarantee you’ve heard of if you’ve studied computer vision) from scratch in Python. After 7–8 hours of focused work, I did what I thought was the best job I could, and submitted it.
I lost that opportunity. And what did the feedback say?
“It could’ve been optimized more.”
This is the point where we either 1) pull our hair out, or 2) learn more about vectorization (and I recommend the second option). What are interviewers really looking for in optimized code?
The truth is, many things. As you might’ve already guessed, Python is indeed slow, in that it needs to be interpreted before it is compiled. But, that doesn’t mean we have to settle. How so?
Enter Vectorization
If you haven’t learned about how to vectorize your code yet and you want to get into machine learning (especially with respect to deep neural networks), now is the time to start doing so. Vectorization is a programming technique that allows your machine to run your code faster, by running instructions in parallel (as opposed to one at a time). This can dramatically speed up execution!
The best part about vectorization is although it sounds complicated, it’s easy for your interviewer to notice you’re doing it: for example, I recommend just using more of the functions built into the NumPy API, instead of your own. Like the gift that keeps on giving, vectorized code is also typically shorter than regular Python, because you’ll no longer need to explictly write out long for loops and such. Let’s look at an example: below, I have a function that projects a set of vectors from 1 plane to another in 3-dimensions (as explained by AGN Gazer on Stack Overflow). I’ll show you how it looks like un-vectorized (aka, with a for loop), and then again using NumPy functions:
The bottom line: vectorization makes code faster and shorter, and it’s one of the things that helps your Python code stand out.
If you’re looking for an introduction to NumPy for free, I would definitely invite you to try Stanford’s introductory tutorial for it, as part of their CS231n class. For a more in-depth look at vectorization specially, I highly suggest taking Andrew Ng’s “Neural Networks and Deep Learning” class on Coursera.
#3: Have You Thought About OOP?
On every team software project I’ve ever worked on, there was always at least 1 person whom I call “the nanny” — that’s the person concerned about code quality.
For many of us who are just starting out, we tend to moan and groan about nannies. Why? Because up to this point, our software projects have mostly lasted on the duration of days and weeks. You build something to learn a language X, then next week it’s framework Y, or a new command called Z, etc. If the code quality is messy or hard to follow, it’s not a big deal. You move on.
However when you’re interviewing at a company, your job is to please the nanny. The bar for code quality is higher, because they need to evaluate how you’re going to impact the team’s codebase for the months and years to come ahead. And one of the things that stands out as well-designed, high-quality code is incorporating the use of object-oriented programming.
This isn’t always needed — like mistake #2, this is mainly in the context of standing out on take-home assessments, and particularly when you’re not allowed to use libraries (aka, you’ll be building algorithms from scratch). For example, let’s say an AI company gives you the following challenges:
- Fit a polynomial to a set of XY points (without outside libraries).
- Fit a polynomial to a set of XY points, and make the model robust to outliers (without outside libraries)
- Fit a plane to a set of XYZ points (without outside libraries)
What’s the real challenge with this assessment? For me in the beginning, it was just avoiding the trap of getting lost in my own code. I didn’t realize all the time I spent using the popular frameworks (e.g. Keras, Scikit-learn) actually trained my brain to go on autopilot on my machine learning projects.
To prevent falling into this trap, I would invite you to not start coding right away. If you do, it’s alot like mistake #1, where you’re likely to go with something that doesn’t work and is hard to explain. Instead, what you might want to do is scope out the problem: identify the right places to reuse code, and then build the right helper methods and classes. Continuing with this example, here’s what I might write in a util package in my project:
I encourage you to take a moment to walk through this code, and see what you like/dislike about it. Here are some questions for starters:
- Do I know what this is doing?
- Is it easy to understand?
- Where would I want to use this? How much would this give me “out of the box” to go do that thing?
This should hopefully give you a good chance to reflect on your own coding style, and to start evolving from a developer who’s merely comfortable with using other people’s libraries (e.g. Scikit-learn, Keras, PyTorch, etc.) to one that your team could rely upon to build their own internal API from scratch.
It might be alot of work, but believe me it sends the right signal — on multiple occasions, I’ve received compliments from managers at companies about my code. If you’re interested for more tips on passing take-home assessments for software engineers, I recommend this other great blog by Jane Philipps on freeCodeCamp.
Conclusion
Like I said, searching for a job — even one as exciting as a Machine Learning Engineer — has its ups and downs. How do you justify putting yourself through all that?
Frankly speaking, I think every person discovers (and if you’re like me, you occasionally lose and rediscover) a personal answer to that question. In my own example, as I write this I can’t help but think of what AI could eventually do for us all.
Imagine this: one hundred and fifty years ago, almost no one had light bulbs in their home. Then in 1882, Thomas Edison turned on the first commercial power station ever in New York City, changing everything. Now fast-forward to today: all our homes, biomedical devices, and even the device you’re reading this on wouldn’t be possible without the grid. And suddenly, now “AI is the new electricity”, or so says Dr. Andrew Ng of Stanford.
Why does this matter? For most of us, 1882 is a distant memory. But every ML Engineer I’ve ever met, every AI company I’ve interviewed with, reminds me we are trying to become the Edisons of our time. Before we get to change the world though, we need to get great experience. So… why wouldn’t that be challenging?
