How To Ace The ML Engineer Take-Home Interview Exercise
By: David Chong
Tags: Editors Pick, Machine Learning, Data Science, ML Engineering, Interview Questions

Exploratory Data Analysis

Every dataset has its own nuances. Understanding the nuance behind the dataset you’re provided will allow you to choose the right model to solve the problem. Also, it is quite common for interviewers to “modify” a dataset just because they want to see if you manage to pick up these “mistakes” they have intentionally injected into the dataset.

Common things to look out for (non-exhaustive):

Missing data (choice of imputation method or removal of data)

Outliers (and how you deal with them)

Correlated features

Data that simply don’t make sense

💡 Takeaway: Understand and clean up the dataset you’re working with. Always provide clear explanations to important decision choices (e.g., dropping versus imputing). Start with univariate plots, then move on to bivariate and multivariate plots while providing clear insights.

⚠️ Gotcha: Steer clear of automated EDA/plotting tools. It generally doesn’t leave a good impression on the reviewer.

Modelling

Modelling is often less emphasised for ML engineers as it is often the DS’ job of creating and tuning these models. Whatever model you choose, ensure that you understand how it works under the hood.

💡 Takeaway: Choose a model that works well for the problem statement. A linear model is often sufficient (unless otherwise stated in the requirements).

⚠️ Gotcha: Do not choose a model you don’t understand or is overly-complicated (i.e., takes a long time to train).

API Service

The bread and butter of every ML engineer. As models are more and more commonly deployed as an API microservice, knowing how to serve endpoints is of utmost importance.

Things to take note and understand when building API endpoints:

Model loading/re-loading

Latency requirements of each endpoint

Method types

RESTful API

Folder structure of each router

💡 Takeaway: Use best practices when designing API endpoints — make sure you understand when a path or query parameter should be used. Use schemas to define responses and database models where necessary. Separate input processing and endpoint logic. Always test your endpoints!

⚠️ Gotcha: Do bear in mind that API services are commonly tested in take-home assessments but it is not the only microservice architecture. Messaging is also very commonly used (but harder to include as take-homes). Read up more here.

Logging

This requirement may not seem too important at first, but it separates the beginners from the amateurs and experts. Logging is crucial in a production setting as it informs the maintainer at which point the code is being executed and the severity levels that accompany it. In essence, these messages should inform you of your application’s health.

💡 Takeaway: Include logging in your modules. Such a simple yet often overlooked requirement.

Unit and Integration Testing

Testing is often overlooked by newbie programmers as they may not have sufficient experience to see the true value of testing. By writing effective tests, you can demonstrate to the reviewer that you understand its importance and how testing fits into a software lifecycle.

Containerisation

As microservice architectures become the norm, Docker has also become synonymous to containers. You’d likely be expected to containerise your application using Docker.

💡 Takeaway: Demonstrate best practices when containerising your application. As a rule of thumb, always create a container that is as ephemeral as possible. Remember — less is more.

Documentation

Always have good documentation of your functions and modules. Also, remember to document other high-level decisions either in a README or using a documentation generator (e.g., Sphinx). This includes things like:

Why the repo was structured in a certain way

Module usage

Setting up and running of code

Why certain models (algorithms) were chosen

Model evaluation metrics

Model results interpretability

Improvements that can be made with more time

💡 Takeaway: Your code should be mostly self-documenting. Focus on documenting design choices that are not explained by your code.

Congrats on securing your next round! Now, what?

Preparing for the follow-up technical rounds are just as important as the first. These subsequent rounds typically ask follow-up questions relating to the take-home assessment, such as:

Addressing some requirements that you may have overlooked/missed out

Alternative models that can be used to solve the problem (and their pros and cons)

How to scale up the API service (e.g. horizontal and vertical scaling)

How to make the API service more efficient (e.g. memory caching, database indexing, using message queues, etc)

Alternatives to design choices

Closing Words

The ML Engineer take-home assessment may take many forms, but I have found the above to be reflective of a typical “ML Engineer”. If your take-home assessment is more geared towards EDA and modelling, your role is likely more skewed towards a Data Scientist position. In that case, I’d recommend looking at this article.