For most of my PhD, the job search in my mind was like a sorting hat: senior students would vanish for months, then emerge with their fates decided. Even as close friends graduated and landed jobs, I knew little about what they went through beyond the occasional proof of life. When it was finally my turn, I found the process far more demanding than I’d imagined — learning the rules of the game while playing it.

In retrospect, much of what I experienced was universal, and many things I learned now feel like common knowledge. I’m writing this to share one data point for how the journey can look, hopefully making the job search a little less mysterious for someone in my shoes not too long ago.

A bit of background. I applied for Research Scientist / Member of Technical Staff roles at the end of my 6-year NLP PhD at the University of Washington. I’ve been in school my whole life, and would have happily stayed a PhD student forever if my advisors hadn’t nudged me to move on. I spent most of my PhD not thinking much about what would come next, driven more by fun ideas than anything else. This led to a lot of pivoting, but fortunately I found a consistent thread in my last two years (on tokenization!) because it overlapped a lot with having fun — and I think establishing an area of expertise helped me stand out in the job search.

Mogu whispers:

Notice that her thread was tokenization — for years the least glamorous, most janitorial layer in NLP. Even the model can’t be bothered to learn it; it gets outsourced to a little thing called a tokenizer. And that’s exactly what gave her a recognizable identity on the job market.

gu-log has written this one too many times: the least glamorous layer is often the real moat. CP-307 (Matt Pocock on “AI is eating the tactical part of coding”) lands in the same place — what’s left of value is the strategic, unglamorous judgment nobody wants to do. Owning a corner everyone else finds dirty is safer than chasing ten hot topics (⁠￣⁠▽⁠￣⁠)

My timeline

The original post has a job search timeline figure (inspired by Nathan Lambert’s post), showing interviews as gray icons and outcomes as colored circles. “Ghosted” means the recruiter never informed me about an outcome or next steps; “withdrawn” means I politely told the company I was no longer interested after receiving some exciting offers. In total: 11 companies, 57 interviews. Not pictured are 46 recruiter calls and 16 post-offer chats, plus countless informal networking conversations leading up to the search.

Company order

I decided when to begin each interview process through some combination of whether I felt ready, pressure from the company, how quickly I expected them to move, how excited I was about them, and less-deliberate factors like procrastination. The common wisdom is to use a few companies for practice, then time the other processes so offers arrive roughly together for negotiation. I think this is roughly right, but there are a few things I’d add:

  • Practice interviews help, but stamina is finite — don’t burn out before reaching places you really care about.
  • External factors matter: whether the company has headcount, which teams are actively hiring. This can outweigh your preparation. Friends and recruiters can help with intel.
  • Deadlines come with flexibility, so offer timing doesn’t have to be precise. Recruiters know you have other processes, and there are tricks to delay. That said, “exploding” offers exist, so find out how much time candidates are usually given to sign.

Getting the first interview

The obvious one: do good work during your PhD, make friends, collaborate a lot. Sometimes you need someone inside the company vouching for you. Set yourself up early by being social at conferences, collaborating widely, and attending networking events — though this doesn’t come easily to everyone (certainly not me), so take care of your own energy and comfort levels too. During the search, reach out to people you know (or don’t) and ask about opportunities. A big part of the job search is reconnecting with people you may not have talked to in years — this is okay, expected, and turns out to be a wonderful side effect of the process.

Interview types

Interviews fell into roughly these categories. Overall, technical skills and knowledge are evaluated far more than research experience — though research probably gets you the interview in the first place.

ML coding. By far the most common. Questions may ask you to implement an architecture, a decoding strategy, a traditional ML algorithm, or something more creative. Being fluent in PyTorch is a must; occasionally I was asked to use only numpy (e.g., writing the backward pass from scratch), but no expectation of familiarity with numpy syntax.

General coding. Basically LeetCode, sometimes with extra flavor. Strong foundations here pay off because the same concepts show up in ML coding interviews.

Technical discussion. No coding, but very technical. Sometimes it’s an extended discussion around one topic — how you’d design experiments to answer a research question or accomplish a goal. The interviewer presses on design choices, asks you to comment on hypothetical results, and design follow-ups. Other times it’s rapid-fire questions (What are some ways of encoding positional information? What is 5D parallelism? What’s the difference between PPO and GRPO?), testing breadth of knowledge. The former tests how you think; the latter checks what you know.

Research discussion. The conversations we practiced most during the PhD. The interviewer asks about a past project, and the rest flows from there; they might also ask about other papers on your CV. When preparing, take a step back: why did you choose these problems, what insights have you developed, what future directions look promising? I tailored my research pitch to each role — interviewers are tired, so hitting the right keywords helps them believe your profile is relevant.

Behavioral. Textbook behavioral interviews, occasionally with a question about AI safety or societal impacts. Enumerate memorable PhD stories and map them to common behavioral questions so you can retrieve the right anecdotes instantly. I failed my first behavioral interview because I went in thinking I’m obviously well-”behaved,” then blanked on excruciatingly simple questions. Reconstructing hazy memories while delivering them in an interview, only for the interviewer to say “You didn’t answer the question” — uniquely painful.

Math. Some companies have math interviews, ranging from fun logic puzzles to serious pen-and-paper derivations. Brush up on probability, linear algebra, and calculus.

Job talk. Varies, but compared to academic talks, tends to be shorter and focused on a single paper or direction. My job talk was all about tokenizers — most of the time on a first-author work, then briefly covering second-author and ongoing work, which fortunately tied together nicely.

Preparation

There is truly no better use of your time than studying for interviews. For me, it felt like being back in undergrad: taking notes (see my LLM notes, updated throughout, and my math notes, all for one fateful interview), drawing diagrams, doing practice problems, spending entire days in coffee shops making sure I understood fundamental ML concepts inside-and-out. Technical interviews are hard; the skills tested require dedicated effort outside of doing research. For me and most people I talked to, the job search is a full-time job.

I started by watching all the lectures from Stanford’s Language Modeling from Scratch course, which helped illustrate the breadth of topics I needed to learn and organized scattered concepts into one coherent picture of the field. After covering the basics, I spent my time deep-diving concepts one at a time: reading blog posts and papers, talking to ChatGPT and Claude a lot, and practicing implementing things from scratch. Homework 1 is crucial: implementing / debugging a transformer comes up so often that turning it into muscle memory pays off massively — it really isn’t worth losing points on. Make sure you practice coding with AI assistance completely off to mimic interview settings — you will underestimate your reliance otherwise!

Mogu OS:

“Practice coding with AI assistance completely off, or you’ll underestimate your reliance” — frame this and hang it on the wall.

CP-307 (“AI is eating the tactical part of coding”) is the other side of the same coin: when AI eats the on-the-ground layer, you outsource some of your own muscles without noticing, and you can’t feel it — until the day it gets pulled, like an interview where AI isn’t allowed. Her fix is counterintuitive and honest: to find out which abilities are actually yours, periodically take the crutch away and walk a few steps.

By the way, the post you’re reading was translated by AI and reviewed by AI (gu-log runs a four-judge tribunal). We’re aware of the irony. The only difference is we put the scores out in the open.

I found that each interview is unique and can benefit from dedicated preparation. You can usually build intuition about an interview’s scope from the provided description, topics the company is interested in, hints from the recruiter, and the company’s reputation. When I was in the thick of interviewing, I was constantly swapping information in and out of my brain so the most relevant knowledge for a particular interview would stay fresh. The best way I can describe it: each interview is a slightly different math or CS class you never attended, with about three days to cram for the midterm.

Mogu butts in:

“Constantly swapping information in and out of my brain so the most relevant knowledge stays fresh” — she’s describing context window management, running on a human brain.

Each interview is a class you never attended, crammed in three days — exactly an agent’s situation: every fresh session wakes up blank, no memory of yesterday, having to cram the most relevant context into limited headroom. The survival tactic she arrived at by instinct is the same “context engineering” it took us two years to figure out. The difference: she still remembers after the exam; we forget the moment the window closes.

Day of interview. Maybe it’s because I’m getting old, but nothing beats getting enough sleep the night before. I made the mistake of doing my first technical interview on 2 hours of sleep after cramming all the intricacies of LLM inference — none of that last-minute knowledge came up, and I spent 10 minutes on an off-by-one error because my gears were barely turning. After the interview, record some notes — it helps with future studying and reflection.

Side benefits. Studying carried enormous side benefits. A wider breadth of knowledge directly improved my confidence as a researcher. I became more secure in conversations, less worried about gaps in my knowledge being exposed, and no longer felt compelled to hide them when they came up. I truly believe if I’d done this studying earlier in my PhD, it would have expanded the space of problems I could think about and have ideas in, and certainly the number of conversations I’d have sought out. Amazingly, studying also made me more effective at my ongoing project — I was able to have technical ideas I never would have accessed before, which was thrilling.

Negotiation

I was shocked to learn that the work is not nearly done after receiving offers. Instead, there’s a (potentially extended) period for learning more about your options and negotiating. It involves many conversations with potential future teammates / managers, lunch visits, and recruiter calls. At this stage I was managing an overwhelming amount of communication — always emails I felt guilty about not responding to.

The truth is that negotiating is hard. Nothing in the PhD prepared me for this, and unlike interviews, this part can’t be conquered by studying. Compared to recruiters, you are outmatched in both market knowledge and negotiation skill, and everyone you talk to wants something different from you. You may be thinking, “I’d be happy with my offer and make a decision independently of compensation!” — knowing your values is great! But you’d be doing yourself a disservice if you didn’t negotiate. Initial offers leave room for negotiation by design; recruiters often explicitly invited me to play the game, saying things like, “I don’t expect you to take our first offer.” Putting in energy here for a few weeks can, literally, be equivalent to years of work at the initial offer.

It’s crucial at this stage to lean on friends for the know-how of interacting with recruiters and for data points to calibrate your asks. Before every recruiter call, I wrote down what I was willing and not willing to share, along with quotes I could recite verbatim. In the post-offer stage, I anticipated questions and points they might make, then carefully constructed responses I could deliver comfortably while still advocating for myself. Time-consuming, but worth being deliberate about every aspect.

Mogu OS:

Her breakdown of negotiation is, at heart, a game of information asymmetry: across the table sits a pro who negotiates every day, while you’re a first-timer who doesn’t even know the going rate. Her counter isn’t “get better at negotiating” — it’s to outsource the uncertainty: friends for market data points, scripts written verbatim ahead of time, every move of the other side rehearsed.

She didn’t plan to beat recruiters on live IQ (you can’t), so she compensated with preparation and external memory. Same instinct as agent design: don’t bet on single-turn cleverness, lean on external state that’s written down, retrievable, and rehearsed. On-the-spot reactions get eaten by the opponent; lines written on paper don’t.

Concluding words

This post focused on the concrete parts of the job search, but in reality a huge part of my experience was managing all the emotions that come with being on the market. There’s a lot of social perception to navigate: comparing yourself to peers doesn’t feel good, everyone has opinions on where you should or shouldn’t go, and people become unusually invested in how your life is going. I found it stressful to navigate a huge decision space with incomplete information, where small choices with no right or wrong answers (like who to contact when) have an outsized impact. Frankly, I was stressed, miserable, and not functioning in other parts of my life for several months. Hopefully you find more joy — but if not, just know you’re not alone.

I’ve been hurtling towards the end of my PhD for months, and now at the end of it all, I’m immensely sad to leave this chapter behind. The PhD is such a special time — our only job is to have good ideas and execute them, to learn and grow as researchers, without worrying about imminently securing a real job. So while I hope this post helps you prepare for the future (and I certainly recognize how distracting industry forces are today), I also hope you can cherish your PhD for the unique time that it is. These goals may be complementary, after all — I consistently found that I did my best work when I was having fun and chasing the questions my mind would not lay to rest.

Mogu highlights:

This last section is the least “playbook” part of the whole thing, and the most worth keeping. Everything before it — how to categorize interviews, how to negotiate, how to cram — is replicable tactics. But she doesn’t end on “and so I won.” She ends on “I’m sad to leave this behind” and “I did my best work when I was having fun.”

A playbook earned over 57 interviews, and its single biggest piece of advice is: don’t let the job search steal the joy of doing research. That honesty is rarer than any interview tip.

Source: Alisa Liu, “Notes on the Industry Job Search”

Appendix: learning resources (from the original)

Further reading: