Be Noticed In The MLOps Crowd

MLOps is an increasingly competitive hiring space. Whilst this article doesn’t aim to discuss why, a combination of massive funding in AI, mainstream interest and adoption of ML and improving economic conditions has meant increasing role volumes. To borrow a line from Marvelous MLOps Co-Founder and Booking.com Engineer Başak Tuğçe Eskili, to bring ML models to life, the operational side is essential. MLOps is inevitable.

More opportunities is great news! But there is a downside, more competition.

Awareness of, and interest in, MLOps is growing alongside hiring volumes. It isn’t unusual to see huge application volumes to advertised positions. You are also competing against applications from various disciplines due to the nature of MLOps. In a typical application pool, we would expect to see ML Engineering, DevOps & SRE, Data Science and Data Engineering profiles, and depending on the hiring need, any of these may be a fit. This means hiring teams have access to a broader pool of potential hires. If you’re a Java Developer, you are largely competing against other Java Developers. Not the case here.

Against this competitive backdrop, my aim is to help you stand out in the MLOps crowd when applying for a role, increasing your application response and success rates. I’ll provide my advice, alongside direct advice from hiring teams. I won’t go further than your initial application, interview advice and guidance is a different beast and for another time.

So How do you Stand Out?

For better or worse (I’m not opening that can of worms here), the vast majority of applications you make will be judged on your CV and online presence, so this is where we will focus. You have control over the snapshot you present, how do we make this as strong as possible?

Before jumping to my five core tips below, there is some general CV advice to keep in mind.

• Be conscious of CV length. There are differing opinions on this, but one to three pages is a good ballpark depending on your level of experience. If you are struggling to stay within this, look at reducing detail in previous roles, highlighting the most recent or most relevant experience. I talk about word real-estate with my team, viewing each word, sentence and section as important. Does what you include add value to your application in a clear and succinct manner?
• If you have academic achievements, include these. Whilst educational background isn’t everything, it can be important, particularly for ML hiring teams. This also includes relevant courses, research papers or publications.
• Spelling and grammar. For the love of God, please, please, please check for grammatical issues and spelling mistakes. Your CV, LinkedIn profile, blogs, GitHub, your Kaggle profile. There are almost no excuses for this. Creating a profile in a foreign language, maybe. But that’s the only reason I’m letting you off.

Whilst this last point is said slightly tongue in cheek, it highlights an important point.

Don’t give a hiring team an easy reason to say no.

I’ve always taught my teams to look for reasons to say yes, giving someone the benefit of the doubt, but this isn’t always the case, particularly if there is a large volume of applications and review time is limited. Strong basics will set you up well going into these next points.

Tip 1. Align your application to the role.

This one is hiding in plain sight. It sounds so obvious, but in reality, it almost never happens. It’s my number one tip for increasing your application success for MLOps positions.

Why? It’s a very broad role. There is absolutely no problem applying to multiple positions, but don’t make the assumption that each position has the same requirements. It’s very likely they don’t, and it’s really difficult to create a ‘catch all’ profile.

Read the role descriptions thoroughly, there may be a particular need that makes you perfect for that position. If so, exploit that fact. Don’t leave the decision to guess work or chance. Align your profile to that need. Whilst this will often be technical alignment, don’t forget cultural alignment. Good job descriptions will give you a detailed understanding of culture and values. If you share these, highlight it.

Application reviews are often brief. Hiring Managers and Recruiters are time poor. Even a short project description that aligns well with the requirement will stand out instantly against a sea of non-tailored applications. We will come on to how to do this.

It’s really important to note I’m not talking about exaggerating your experience here. It has to be an honest appraisal. If it doesn’t align, don’t force it. What I am talking about is making the most of your experience. The majority don’t take this opportunity, it’s a massive window of opportunity to stand out.

And I do hear you.

‘Why should I customise my profile when I don’t hear back in any case?’

‘I don’t have time to customise a CV for each application.’

Valid points.

On point one. This is in part why you aren’t hearing back. I can guarantee doing this will improve your response rates. It is also a great check and balance on whether you should be applying to that position in the first place. Can’t align your experience to the role? Maybe put your energy into another more suited application.

On point two. I’m not asking you to entirely re-write your CV. Use a solid base, and tweak. We are looking at making small amendments that twinkle in the reviewers eye. My next four tips will help you get there quickly, easily and within the limitations of a succinct CV.

Tip 2. Include figures and measurable results. Be a salesman.

Most people are great at talking about the tasks they completed. Very few Engineers include the results and benefits of this in their CV. For a moment, I want you to think like a salesman, who is great at highlighting figures and measurable outcomes (unless the figures aren’t so hot, then there is a conspicuous absence).

It’s amazing you put a complex model into production, but what was the outcome? The more specific the better. What was the time benefit? What was the cost benefit? What impact did it have on the goals of the team and overarching business? It’s rare I see this, and when I do, it really stands out.

Example:

Automated data pre-processing pipelines using Python, Docker & SQL; significantly reducing data processing time by over 97% as well as enhancing model training efficiency.

Redesigned training and deployment workflows using MLFlow & GitHub Actions reducing size of API Docker image by 37%, speeding up CI workflows by 12%.

Orchestrated the design and deployment of a cloud based, AWS RDS database, achieving an 88% reduction in query latency, optimizing the data pipeline for rapid data access.

Tip 3. Scale, complexity and challenge. Talk about projects.

My previous point leads me on to how you describe your experience. CVs are bullet point central, and there is nothing wrong with this, but you may want to consider adding depth and detail to specific points or projects.

Show complexity and scale, particularly in difficult technical challenges you had to overcome. How many events did a system have per day? What was peak TPS? Have you worked on large dataset processing? Describe these challenges, what process you went through and the solution you found, even the problems you encountered before success.

I understand that there is a need to fit in the limitations of a relatively short and succinct CV here, you certainly won’t be doing this for every point you make, but expanding on particularly relevant points to the application you are making can add a lot of value. It also comes back to my earlier point about tweaks, rather than wholesale CV changes. Expanding or adding one or two key experiences is a quick and simple way to customise.

Some great advice to keep this succinct and clear is to follow the STAR technique. Describe the Situation you were in, Task at hand, Action you took, and the Result of that action. Don’t forget the R!

Example:

I was in charge of planning and developing an IoT infrastructure MVP. It consists of 3 tiers: sensors, on-premise gateway devices and a central management platform in the cloud. Sensor devices are programmed in C, using ESP-IDF (Espressif IoT Development Framework). On-site gateways and the central server are written in Java, leveraging Spring Boot and Vertx. As this is an MVP (to be installed in 2 factories over the summer), the main challenge was to identify corners worth being cut to meet deadlines, but to never endanger the future of the project. E.g., while there was never compromise on security, some features are only accessible through API, not UI.

Example taken from (https://careers.loveholidays.com/pages/our-platform-and-you).

Tip 4. Choose your links wisely.

As mentioned earlier, you have the opportunity to guide a hiring team towards what you want them to see. Increasingly, LinkedIn profiles, personal sites & blogs, research papers, GitHub, Kaggle and a variety of other sources are used to make a decision.

If you’re a big GitHub contributor, make a point of highlighting the link on your CV. If you’re a Kaggle Master, do the same. Point towards a particular project you may want someone to look at. It could be specifically relevant to the role, it may just be something you are proud of. Both are great. On the flip side, remove dead links or sites that aren’t adding any value to your application. GitHub is a great example of this, if you contributed once four years ago, it’s probably doing more harm than good (remember, remove the reasons for someone to say no!).

If you have relevant blog posts or research papers, absolutely include these. You could even write a specific blog post to bolster an application. As we will see later, advice from the frontlines suggests these are hugely valuable as part of your application.

If you have one, and love it or hate it you should, make sure your LinkedIn profile matches your CV, even if you don’t include the link in the CV. The dates need to match up, and it needs to be up to date.

Many application portals, the likes of Greenhouse and Lever, have options to include supporting documents. Do so where you can and where it is relevant.

Make the assumption that hiring teams will be stalking your profile as part of an application. Better to be safe than sorry.

Tip 5. Don’t keyword. But do.

There is a common misconception that a large number of applications are keyword auto-filtered by Applicant Tracking Systems (ATS). Whilst this does happen, in my experience, most applications, particularly outside of enterprise environments, will still be reviewed by a human.

It’s also a misconception that human decisions are made simply based on keywords. Yes, I can’t escape the fact that some people will screen profiles like this. And yes, sadly external Recruiters have a reputation for doing this, but it isn’t everyone!

Looking for keywords, particularly the myriad tech and tooling someone is likely to need in an MLOps role, isn’t a bad screening strategy. But only if used alongside the above to build a more complete picture. And never if simply looking at how many times someone mentions a particular term.

So there is a balance to be had here. You should absolutely include the specific technologies you’ve used. Ideally tailored to the application as above. You can definitely list this in a skills section. But add some context. What are your strengths? What have you used most recently? What’s day to day usage and what’s once a year? Giving yourself a score out of five (or even better an usual number like six so you can’t sit in the middle) is an easy win. You should also build the key technologies you’ve used into the project based and measurable descriptions we’ve discussed (see above examples on how this is done well). This gives you the best of both worlds. You’ve got your keywords for the buzzword bingo Recruiters and the evil ATS. You’ve got context and depth for those doing it properly.

Don’t, whatever you do, simply create a huge list of technologies and leave a hiring team to guess what you’re good at.

From The Frontlines

Enough from me, let’s hear directly from MLOps hiring teams.

I spoke with Abi Aryan, Founder of Abide AI, who when reviewing applications looks for ‘focus’. By this, she means a deep understanding with a particular subject or tool. It is easy to be tempted to highlight any project or tool you have ever worked on, but this can dilute your real strengths.

On a similar note, Abi views referencing older techniques as a positive, rather than only focussing on the latest shiny tools and tech. For her, it demonstrates critical thinking, foundational knowledge and good reasoning. Sometimes a simple solution is the best route, and Abi is keen to see applications that demonstrate an ability to make this choice.

Abi felt a GitHub profile or an open source project are useful, but in her opinion have limitations. Instead, she prefers to see blogs and research papers, where someone is able to explain complex ideas clearly and concisely. Abi suggests writing a great blog post on a targeted, specific topic of interest to you and relevant to your application. Using this as part of your pitch. It’s a great point, and really makes you stand out from the crowd.

Matthias Vraeghe, Data Science Engineering Manager at Lighthouse, currently actively hiring for an experienced MLOps Engineer, gave a detailed insight into their review process.

Matthias confirms role and team context is an important factor.

At Lighthouse we currently have a Data Science department of 14 people, divided over 2 teams. At that size, we have quite a bit of Data Science knowledge in place already, by as we’re continuously pushing the scale (having 1000s to 10 000s of users depending on the product) and complexity (recently added some LLM-based features) of the models we use to serve our SaaS applications, we’re looking for an experienced MLOps engineer to solidly set up a framework, establish best practices and help enable all Data Scientists to productionalise their models and algorithms.

With that context, Matthias and Lighthouse look for specific ‘easily retrievable’ skills within a CV, from years of experience, specific technical knowledge (for Matthias this is things like Python, SQL, ML frameworks, Airflow and cloud infrastructure) and language fluency.

Next to these easily retrievable points, Matthias gives some great advice:

Things we like to already get a glimpse of in a CV — short descriptions of projects work well for that — and will ask about in a first interview:

• Experience with figuring out the best technical MLOps solution in an existing team. Being able to talk to technical stakeholders to find out the dependencies and limitations that exist, in order to get to that solution; and then plan and execute on the solution. When mentioning these types of things on a CV, do note your own role if part of a larger team effort.
• Being able to coach other Data Scientists in best practices, and make them independently able to productionalize models.
• Ideally: Being aware of the potential change and stakeholder management needed to establish new procedures and practices, and knowing how to approach this.

Aaron Hunsaker, ML Platforms & Operations Manager at Beyond highlights the importance of ensuring you understand a hiring teams needs. Aaron’s team has been ML and Data heavy, so his specific needs were adding Ops experience. For Aaron, candidates that ‘know every model and all the latest ML trends, but can’t tell me basic deployment patterns and have no experience productionizing anything’ aren’t going to be a fit. But he absolutely understands this is due to his environment and need. ‘If I was starting with a ton of ops people and no ML people it would be different.’

Reem Mahmoud, Director of Data Science at Intervu.ai ‘would prioritize a candidates portfolio (which if done well tells you a lot) and I also check the candidate’s LinkedIn account. I personally like to see what they talk about and share (if at all.) And then from there make the best selections I can.’

Dr. Lydia Nemec, Head of AI Accelerator at ZEISS Group reinforces a vital point.

‘Be clear and honest with your experience, and your technical know-how and skill level. For me, you do not need to convince me that you know everything already, you need to convince me you can learn, grow and live up to the challenges in a fast-evolving field.’

Final Points

I write this guide with the understanding each application is different, but hope to have provided some pointers that will improve your applications response and success rates.

Remember that MLOps is a varied role. Align your application. Include measurable results. Talk about projects. Include and highlight relevant links. Give context to you keywords.

And lastly, a huge thank you to all those who gave their valuable time to contribute and provided great insight and advice!