I recently wrapped up my ML PhD industry job search and experienced how stressful and overwhelming the process can be. While it’s still fresh, I wanted to share what I learned along the way in hopes it might help others navigating the same journey. Note: my experience was specifically on applying for Research Scientist positions.

I will cover my experience with the end-to-end process: the first thing I did from a “let’s graduate” conversation with my advisor, getting my foot in the door, prepping for different interviews, dealing with rejection, and choosing between offers.

From ‘wait, I’m graduating?’ to signing an offer

Last Fall I was in the first half of my 5th year, just wrapping up an internship and was excited to get back to school to kick off some new PhD projects. Back then I was still comfortable being a PhD student where I can freely explore even the most unhinged curiosities. Suddenly my advisor brings up graduating next spring.

It all feels overwhelming. How do I even start? With PhD research projects still ongoing, it was very tempting to procrastinate (and I did, for a while). But I eventually realized my advisor brought up graduation for a reason. I was indeed ready for independent research and to carve my path outside of the lab.

My “job mode on” switch didn’t really activate until I took my advisor’s advice to start getting organized: I made a spreadsheet to track places I applied to (or was going to apply to). Looking back, this making it official makes a lot of sense. We ML PhD students are used to filling up tables and feeling a sense of accomplishment from it (re: experiment tables ). The sheet literally looks like this:

Okay, now we are organized, we are keeping track of our applications, great. Next, how do we actually get interview invites from these places?

Getting interviews

To put into perspective: in the current market, just applying to the company’s job portal puts us into one of possibly hundreds of fellow PhD students in the market, each with their unique research and cool things to offer. How do we stand out?

Look out for people that are hiring. I kept an eye on X, LinkedIn, and AI/ML conference job expos for anyone posting “We are hiring in [blabla]” where the [blabla] was right up my alley, and I’d shoot them a message. A short message conveying I had worked on relevant stuff with a pointer to my website was usually sufficient. I was lucky that my job search timeline aligned with NeurIPS, so I had the chance to meet people at the conference. Before meeting anyone, I usually planned what to say. Nothing scripted, just enough to make sure I conveyed everything I wanted them to know about my work. I also made sure to ask them questions too: it’s a two-way process. After the conference, I shot an email to folks I talked to (some even reached out before I shot them an email). And when the stars aligned, interviews followed. Sometimes they didn’t, and that’s okay too.

Preparing for the interviews

This is where most of the beef in this blog is gonna be. I can only speak about the interview types I’ve gone through, it’s possible there are more out there. But generally, ordered by how often I encountered them:

• ML coding
• ML debugging
• ML concepts
• Deep Learning and LLM concepts
• Job talk
• Leetcode-style coding
• Probabilities/Statistics

Most companies I interviewed with didn’t test all of these, just a subset. Usually the recruiters or my points of contact gave me a brief overview of what the interview formats were going to be. At any given point when I was in the process with a company, I tailored my prep to their specific formats. Early on, when I was just starting to prep and waiting for interview calls, I focused more on ML coding, practiced leetcode problems for timed problem solving, and rehearsed LLM knowledge to make sure I understand even the smallest details. Next I’m gonna list the specific materials I used to prep for each topic. Shout out to my friend Harshay who recommended some of these list items when I started prepping.

ML coding.

• Karpathy’s NanoGPT
• Practice implementing these from scratch:
  • Transformers
  • Greedy sampling
  • Positional encodings
  • Simple MLP and backprop
  • Attention and its variants
  • KV cache
• Advanced NumPy indexing
• Sometimes more classical ML coding like K-Means
• Data mixture

ML debugging. This one is somewhat tied to ML coding. Understanding the implementation usually got me better at spotting errors. For extra exercise i usually ask Claude (my chosen LLM provider) to give me common implementation bugs and I try to spot them.

Classical ML concepts

• Brush up linear algebra basics (i watch 3b1b videos) and how the intuitions connect to ML concepts
• For list of ML topics to read/brush up, i refer to https://www.cs.cmu.edu/~hchai2/courses/10701/

Deep Learning and LLM concepts

• Make sure to know:
  • pre-training: scaling laws, chinchilla compute optimal
  • post-training: RLHF, SFT, DPO, GRPO, etc
  • efficiency: flash-attention, GQA, MQA
  • tokenization
• I refer to https://deeplearning.cs.cmu.edu/S25/ and https://pages.cs.wisc.edu/~fredsala/cs639/schedule.html for list of topics

Note: This field is very big and it can feel overwhelming to feel we have to know everything there is to know. I like to think the positions that are a good fit for me will test deeply on the topics related to my previous work. For example, I worked a lot on post-training, so I put an emphasis on deep knowledge in post-training (but also made sure I knew reasonably well about pre-training, efficiency, etc.)

Job talk.

I personally found this was a fun one to prep. I assume if you’ve made it this far, you have presented your qualifying/preliminary exam before. It’s very similar to that. Though, some things I tried to keep in mind while making my slides and practicing my talk:

• Do not present 3 different papers. Present a unified research theme consisting of 3 (or whatever number really) papers.
• Do presentation roadmapping (what we’ve covered so far, what’s next)
• I found it wise to not try to fit every single paper in (since time is limited anyway). I picked ones I was most proud of and could connect into a unifying theme.

Leetcode-style coding.

I initially debated whether to include this as a subsection. Combining what I heard from others and my own experience, leetcode-style testing fell into two cases for research scientist interviews. Case one: easy-level problems to gauge if we can code in Python reasonably well. Case two: medium/hard-level problems, usually for roles where RS work is very close to production. Case two was much less common in my experience, and when it came up, it wasn’t a surprise; the role description usually signaled it. As usual with leetcode prepping, the possibility is quite vast. I’d recommend being fluent on the basics: BFS, DFS, recursion, binary search, and always know your big Os.

Probabilities/Statistics

• Make sure to know the basics: Bayes’ theorem, common probability distributions, conditional probability/independence, expectation/variance, MLE, MAP, etc.
• Doesn’t hurt to skim standard statistics course lecture note
• I find this problem set very useful: https://jerryqin.com/posts/a-working-list-of-probability-problems

Dealing with rejection

There’s probably a lot of articles/books covering this already, so I won’t say much here. But I guess I’ll say something that especially worked for me. Often the pressure of “there is still another interview next week” lured me to toughen up and think “no time to dwell, GRIND”. It didnt work for me. I allowed myself to be dissapointed. One whole day of binging my fav show and lie down on the sofa usually did the trick.

Deciding between multiple offers

Different people have different situations and priorities when it comes to this. I found this twitter thread to be especially relevant in today’s market and environment. I guess I’ll lay out the consideration factors for myself and friends in the market.

• Surface area: how much does my output impact the team and organization
• Mentorship: how much can I learn from my peers and mentors
• Research match: can I contribute to the team’s mission with my current skillset

My Timeline

This will look very different for each person. But I’ll put my own timeline here:

• September/October: The “graduating?” talk and getting organized - procrastination cycle.
• November: Initial reaching out.
• December: Networking at NeurIPS, first phone screens, start technical prep
• January-early February: Interviews
• Mid-February: Final rounds, offers, and decision-making.

Final thoughts

The job search is stressful, and there’s no way around that. But looking back, it was also a time where I learned a lot about myself: what I want to work on, what kind of team I thrive in, and what I value in a workplace. It also honed my technical and communicaion skills. If you’re in the middle of it right now, I hope some of this was helpful. And if nothing else, make the spreadsheet. It really does help.