Machine learning internships: the gap after the notebook

What the job is made of

• Training models competently, which is table stakes rather than a differentiator
• Getting a model behind an interface something else can call, and keeping it there
• Evaluation that survives contact with real inputs, not just a held-out test split
• Noticing distribution shift — the data changed, the model did not
• Reasoning about latency, memory and cost, because a model too slow to call is a model nobody calls

Why deployment is the hiring signal

A team taking on an ML intern is not short of people who can fit a model. They are short of people who can take something from a notebook to a place where a colleague can use it, and who will notice when it degrades.

This is good news for students, because deployment is learnable in a weekend and almost nobody bothers. Wrapping your own model in a small service, putting it somewhere it stays running, and adding one check that alerts when its outputs drift puts you ahead of applicants with stronger theory and nothing running.

Building without a GPU lab

Not having access to serious compute feels disqualifying and mostly is not. Choose problems where the interesting part is not the size of the model — a smaller model on a well-constructed dataset demonstrates more judgement than a large one trained on whatever was convenient.

Fine-tuning something small, using a pre-trained model as a component, or spending your effort on the evaluation rather than the training all produce work worth discussing. The constraint also happens to mirror reality: most production systems run smaller models than students expect, because inference cost is real money.

What breaks in production and how to talk about it

Models fail quietly. The accuracy stays respectable in aggregate while collapsing for one segment; the input format shifts slightly upstream; a feature that was available at training time is not available at prediction time.

If you have hit any of these in your own project, say so in the interview. Describing a failure you caught and the check you added afterwards is one of the strongest things a student can say, because it is evidence of the habit that keeps deployed systems alive.

It is also a rare answer. Most candidates present their project as a success story with the difficulties sanded off, which reads as either luck or inexperience. A student who says the model looked fine until they checked one segment, and then explains what they did about it, is describing the actual working life of the role rather than a coursework summary.

Competitions with real evaluation pressure

See every curated opportunity →