When I started preparing, the hardest part was knowing how much was enough. LeetCode, ML fundamentals, system design, papers, projects—any one of them could take all the time I had.
Last year I spread myself too thin, then discovered another gap whenever an interview came along. If I were arranging my preparation again, this is where I'd start. It's based on my own gaps, not a schedule everyone needs to follow.
Work out what you're applying for
I'd pick a few job descriptions I actually care about and look for what they have in common. I wouldn't assume two MLE roles need the same preparation just because they share a title.
Teams can put very different weight on modeling, data, training, and production work. I'd ask which part I want to do, what experience I already have, and what is missing. Location, graduation date, and work authorization belong in that first pass too.
This doesn't mean deciding on a lifelong direction before sending an application. Preparing mainly for one kind of role, while learning about others, would have worked better for me than starting everything at once.
Be able to explain what's on the résumé
I used to treat “I did it” and “I can explain it” as roughly the same thing. Follow-up questions made it clear that I needed another pass through the work.
For a project, I'd take the résumé bullet and try talking through it for a few minutes without a script: what was wrong, which part was mine, why I chose that approach, and how far the work actually got.
The places where I get stuck usually point to something worth reviewing. For example:
- I keep saying “we” without explaining my own contribution.
- I remember the model but can't explain why we chose it over another one.
- I can quote a metric without explaining the comparison, data, or evaluation conditions.
- I mix up a proposed design, an implementation, and a result that was actually validated.
Numbers help when I have them. When I don't, I need to be specific about what I delivered and what evidence exists—not turn an untested idea into an improvement because the résumé needs a strong result. Work that went badly can be worth discussing too, especially how I noticed the problem and decided what to change.
Practice the parts that don't come out reliably
Solving a problem once doesn't mean I can write it again. Studying a model doesn't mean I can explain it. Some preparation time has to involve writing code and speaking, rather than reading another answer.
For algorithms, there's LeetCode methods. For ML and design, start with the technical study index or system design. I won't duplicate the entire topic list here.
I'd rather keep a regular, manageable slot for revisiting things I got stuck on than restart everything when an interview arrives. For research-oriented roles, papers and project discussions need time too; preparation can't become only coding practice.
One detail I underestimated: I learned most technical material in English. For an interview in Chinese, I need to practice saying it in Chinese. Knowing the English term doesn't always translate into a fluent explanation on the spot.
Some things are easier to ask someone
A job description can be broad about what the work actually involves. Talking to someone doing that work may be more useful than guessing. I'd ask what a new hire usually takes on, how much time goes into experiments versus engineering, and whether my experience seems relevant.
It's okay to ask about a referral too, but I don't want every person I know to become a recruiting contact. Someone taking time to answer questions or read a résumé is already helping. I can explain my situation clearly without treating a forwarded application as a promise of an outcome.
Terms I had to look up
A small reference table to save some searching. These are common uses, not a description of any particular company's process.
| Term | How I would read it |
|---|---|
| OA | Online assessment; it may involve coding or other tests |
| recruiter screen | A conversation about background, interests, timing, and other basics |
| phone / technical screen | A technical screening round; the name doesn't necessarily tell you the format |
| onsite / loop | A set of interviews, not necessarily in person |
| BQ / behavioral | Discussion of how you handled past situations, usually using real examples |
| system design | Designing a system around requirements and constraints, and explaining the choices |
| HC | Usually headcount; sometimes hiring committee, depending on context |
| team match | Conversations about fit with a particular team; where this happens in the process varies |
| level | Seniority, with responsibilities and expectations worth asking about separately |
| base / bonus / RSU / sign-on | Salary, bonus, restricted stock units, and a signing payment; not every offer includes all four |
| refresh | An additional equity grant after joining; availability and timing depend on the arrangement |
| return offer | An offer to return after an internship; the role and start date depend on the actual terms |
| referral | A way to forward or recommend an application, not a guarantee of an interview or offer |
| ATS | Applicant tracking system: software for managing applications and recruiting; a clear, readable résumé helps |
Adjust after interviews
While I still remember, I'd write down a few specific things: the concept I couldn't explain, the project answer that ran long, whether the coding difficulty was in the idea or the implementation. My own example is this interview review.
It doesn't need to become an essay or a reason to rebuild the entire plan. If the same gap appears in several interviews, it deserves more attention. If it happened once, I can work on it without assuming everything is wrong.
Taking a break is an option too. There's no need for a rule about resting a certain number of days after a certain number of rejections. When I'm too tired to absorb anything, sitting at the desk longer may not help.
Applying and preparing can happen together. I don't want to wait until I know everything before applying—that probably won't happen. I also don't want every new opening to become a reason to learn an entirely new field immediately.