A hiring manager I trust screens data science applicants with a single filter, she wants to see something you built and can explain, not something you followed from a tutorial. Most infrastructure engineers fail that filter, not for want of projects, but because their resume describes a decade of keeping systems alive in language a data team does not read, and their portfolio, if it exists, is a Titanic notebook that a thousand other applicants also submitted. You already built the projects this series called for. This part turns them, and the operations career behind them, into the two documents that get you the interview, a resume a data team recognises and a portfolio nobody else in the pile could have made.

Seven Seconds of Screening and What Survives It

A resume is not read, it is skimmed. In the Ladders eye tracking study, 30 recruiters were watched over ten weeks and spent an average of 7.4 seconds on the first pass across a resume, most of it on the top third of the first page. Seven seconds does not read a tool list, it reads a shape, your most recent title, one or two lines under it, and whether numbers jump out. A common worry sends people the wrong way here. Job seekers are told the real gate is an applicant tracking system that auto rejects on missing keywords, so they pack the page with every term from the posting. Most tracking systems rank and search rather than silently reject, and a keyword only helps once a human is already skimming. So the winning move is not keyword density, it is putting an outcome with a number in the first two bullets, where the seven seconds actually land. Write for the skim first and the search second.

Recruiters read in an F pattern, across your most recent title, down the left edge of dates and employers, and into the first bullets of the current role. Design for that path. Put a one line summary under your name that states data adjacent work on production systems in plain terms, then make the first two bullets of your latest role the strongest results you have, each an outcome with a number. Keep the layout single column, because a two column resume is the most common format failure that confuses a parser and pushes your best line into the wrong reading order. Everything below the first third is confirmation rather than discovery, so it can hold the tool list a keyword search wants without costing you the skim.

Translating Operations Work Into Data Science Bullets

Operations resumes describe responsibilities, data science resumes describe results. That single shift, from what you were responsible for to what you produced and how you measured it, is most of the translation. A data team reads three things in a bullet, the outcome, the method that got there, and the number that proves it. Your operations work already has all three, they are just buried under duty language. Below is the reference artifact of this part, the resume translation table. Read the left column as the reflex phrasing an operator reaches for, and the right as the same work in the grammar a data team recognises. Fill the numbers with your own, and never claim a metric you cannot reproduce when an interviewer asks how you got it. Turning one of these projects into a real, importable module rather than a loose notebook is its own credibility signal, and the Data Science Series walks through that in its part on going from notebook to package.

Two mistakes show up in almost every first rewrite. One keeps the verb but drops the number, so maintained becomes built while the bullet still has nothing to measure, and a data reader treats an unmeasured claim as decoration. Another reaches for a method you did not really use because it sounds impressive, which collapses the moment an interviewer asks a follow up. Write the result you can defend, name the actual method, and attach a number you can reproduce, even a modest one. A bullet that says cut false alerts 38 percent with a seasonal model beats a vague line about advanced machine learning every time, because it is specific, honest and answerable.

Three Projects Built From Your Own Systems

Across parts 21 to 24 you built an anomaly detector, a capacity forecaster and a log clustering pass on your own metrics, and parts 17 to 20 served and monitored a model. That pile is your portfolio, it just needs curating. Two or three deep projects beat ten shallow ones, because a hiring manager who opens a repo wants to see one problem carried from messy data to a validated result, not ten half finished notebooks. Pick projects that show range across the pipeline, one that cleans and models, one that forecasts or detects, and one that serves and monitors, so together they prove you can take data science from question to production. Each row of the table below maps a project you already built to the skill it proves and the kind of role it opens.

flowchart LR
  P[Project on your metrics] --> R[Repo with a README]
  R --> W[Short writeup, the trade offs]
  W --> H[One hosted demo]
  H --> B[Resume bullet, outcome first]
  B --> A[Application, keywords from the JD]

Order the three as a story a manager can follow, from data to decision. Project one shows you can take a raw export and turn it into a clean, documented dataset, the least glamorous and most convincing skill in the set. Project two shows judgement, a forecast or a detector where you chose a method, backtested it, and reported the error honestly rather than the best run. Project three shows you can operate what you build, a served model with monitoring, which is the exact ground an infrastructure background already owns. Read together, those three say this person can find a question, answer it with data, and keep the answer alive in production, which is most of the job.

If you are aiming at ML platform or AI engineering roles, add a short note on how you would evaluate a model or an LLM feature before shipping it, since disciplined evaluation is what those teams screen for, a habit the AI Engineering Series covers in its piece on evaluating generative output.

Where to Host the Work So It Gets Seen

Where the work lives decides whether it gets seen. A hiring manager opens a link, reads a README, and rarely runs anything, so the job of hosting is to make the result legible in a minute. Put each project in its own GitHub repository with a README that states the problem, the data, the result and one honest limitation, and use a src layout so the code is an installable package rather than a stack of notebooks. Add one short writeup per project, a few hundred words on the trade off you made and the failure you hit, because reasoning is what separates you from someone who ran a tutorial. Host a single flagship as an interactive demo if you have one worth the effort, and stop there. My pick is a GitHub repository with a strong README plus one hosted demo, the combination a manager can skim and an engineer can verify. Avoid two traps, a bespoke personal website you maintain instead of building, and a portfolio that lives only on Kaggle, where generic datasets make everyone look alike.

metrics-anomaly-detector/
  README.md            # problem, data, result, one honest limitation
  pyproject.toml       # installable package, pinned versions
  src/
    anomaly/
      __init__.py
      features.py
      model.py
  data/
    sample_metrics.csv # anonymised, no hostnames or IPs
  notebooks/
    exploration.ipynb
  tests/
    test_features.py

A writeup is where you win the roles that ask for judgement. A few hundred words per project, structured as the problem, the approach, one trade off you weighed, and one failure you hit, does more than another chart. Managers skim code for competence and read the writeup for how you think. Say why you picked a seasonal model over a plain threshold, what the model still misses, and what you would try next with another week. A candidate who names a limitation reads as more senior than one who claims a clean win, because operations teaches you that nothing is ever clean, and that instinct is exactly what a data team is buying from a switcher.

Your Own Telemetry Versus a Kaggle Notebook

Here is where the standard advice is wrong for you. Career switchers are told to grind Kaggle competitions to prove machine learning, and for someone with no data of their own that is reasonable. You are not that someone. A Titanic or house prices notebook puts you in a pile with thousands of identical submissions, judged only on whether your accuracy edged theirs. An anomaly detector on a quarter of your own cluster metrics, with the incident you caught and the false alerts you cut, is a project no other applicant can copy, and it carries the one asset a switcher owns that a fresh graduate does not, domain expertise in the systems that generate the data. Lead with your telemetry, not a leaderboard. One caution before you publish, infrastructure data leaks operational detail, so scrub hostnames, internal IPs, ticket text and anything a security review would flag, and say in the README that the sample is anonymised. Your edge is the data nobody else has, which is exactly why you handle it with care.

Say the advantage out loud in the interview, do not assume it is obvious. A fresh graduate can run the same scikit learn call you can, but cannot tell a story about the 2 am incident the metric came from, why the threshold was wrong, or what a false page costs a tired on call engineer. That context is the difference between a model and a useful model, and hiring managers for infrastructure adjacent data roles are listening for it. Frame your projects as problems you lived before you modelled them, and let the domain do work no bootcamp graduate can match.

Rewrite Three Bullets and Publish One Project This Week

You do not need more projects, you need the ones you have to read like data science. Two documents get you the interview, a resume whose top third is outcomes with numbers, and a portfolio of two or three deep projects on data your own systems produced. Market momentum is on your side, a 34 percent growth projection and about 23,400 openings a year reward the switch, but only after the translation is done. On Monday, open the resume translation table, rewrite your three most recent bullets into outcome, method and number, and push one project to a fresh repository with a README that states the problem, the result and one honest limitation. That is a morning of work against two documents that decide everything downstream. Next part closes the series on interviews, choosing a specialisation, and what to learn after you land the role. Rewrite those three bullets tonight and open the repository before you talk yourself out of it.

References

• US Bureau of Labor Statistics, Occupational Outlook Handbook, Data Scientists
• Ladders, Eye-Tracking Study, 2018
• Python Packaging User Guide, src layout vs flat layout
• Data Science Series, From Notebook to Python Package
• Data Science Series, What a Data Scientist Actually Does
• AI Engineering Series, Evaluating Generative Output

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts