AI research interviews

Bas van Opheusden, Aug 12, 2025

A few weeks ago, I started a new job at OpenAI. This document describes my interview process and lessons learned. If you’re reading this, I assume that you are on the job market or considering a career change, and at least tangentially interested in generative AI and Large Language Models. And if you’re not, I’d encourage you to check out openai.com, and read about our latest research. I hear gpt-5 is not bad ;)

Disclaimer: this is NOT a guide to get a job at OpenAI. It only describes my process and learnings interviewing at multiple AI/ML companies. All opinions are my own.

Protect your mental and physical health

Interviewing is stressful, the stakes are high, and you’ll have moments in which a single 30-minute conversation will change your life dramatically for the better or worse. When you come out on the other side with one or more offers, it’ll all be worth it, but it’ll be rough at times. Make sure you have a support network of friends and family, and don’t underestimate the physical effect that mental stress plus late nights can have.

Everyone wants you to pass your interviews and sign an offer

The interview process can feel adversarial, frustrating and unfair at times. Despite this,  remember that everyone involved, your referrers, recruiters, interviewers, hiring managers, etc, wants the same thing: for you to pass and accept an offer. Generally, companies will try to set you up for success and any other outcome is a loss for everyone. While we all play different roles, this is a team sport.

Failure is an option

At the end of my interview cycle, I had a bunch of rejections and 3 offers. If I'd had 2 or 1, I'd still be stoked. If I had none, I would have been sad. I'd have been emotionally crushed and it'd have been difficult to even consider applying to other companies for a while. But I'd get there eventually, and I'd have certainly reapplied to OpenAI in about a year. We're all on growing career trajectories, and if you pass even a single stage at any company, they generally would love to reconnect in 1-2 years. This has happened to me, and many people I know. This year was not the first time I applied to OpenAI.

Enjoy yourself!

It’ll be hard to do considering the stakes, but interviewing is also fun. You get to learn about new cool startups, you’ll get one-on-one time with world experts in your exact field of research, and you’ll learn a bunch of new skills. Coding interviews are kinda fun in a way too. A very type-2 fun way.

General advice

Prepare early

Any time spent preparing for job interviews is likely the highest return on investment of anything you do in life. I wish I’d started earlier. Preparing for interviews also carries side benefits: you get to learn new skills, read papers, or revisit some classics. Through practice interviews you’ll get to receive honest feedback and zoom out. I have noticed myself getting better at my previous job due to interviews. As an order of magnitude, I’d recommend around 100 hours of practice on leetcode or other platforms, and a similar amount of time reading papers, refreshing knowledge (use Deep Research!) and talking to friends.

There are no informal conversations. 

Recruiters may invite you for a chat with your hiring manager or to have lunch/dinner with the team and frame those chats as “informal”, but that mostly means that there is no formal grading rubric. Every interaction you have with any company or its representatives is an opportunity to show your character, competence and excitement (both positive and negative) and this remains true from the initial chat until the day you sign your offer.

Practice with friends

Interviews, and especially coding interviews, are awkward. They involve debugging off-by-one index errors while someone you have never met before is watching over your shoulder and expecting you to talk through your process. It also requires you to not use codex or cursor or any LLM tools in your regular workflow. You don’t want your first experience to be during a high-stakes interview. As much as you can, practice with friends, practice coding under time pressure, select annoying problems, and have your friends pretend to not know you. This will be awkward, but that’s the point. Learn to embrace the awkwardness.

Simple tricks

The interview process is designed to measure your competence and company fit, and to some extent, you either meet the bar or you don’t. However, there are many small things you can do to shift the odds in your favor - and doing them signals effort and professionalism.

• Invest in a good setup. I bought a Yeti Nano microphone and a C922 Pro Webcam. I have a dual-screen setup where I can take notes during a call, and I will move the video call window on my screen so that it looks like I’m making eye contact. My room is well-lit and in case audio fails, I have some headphones handy. I will clean my desk before every interview, and bring a pen and paper. I’ve only used them once but I probably would have failed that interview without them.
• Take care of your basic needs. Go to bed early the day before. Run an air purifier, AC or space heater as-needed. 30 minutes before your interview, go for a walk or play with your cat. Make sure you’re well-fed, have gone to the bathroom, and have water handy (I’d have water, coffee, ice tea and kombucha all lined up). If you have back or neck issues, take some Advil and stretch.
• Be early. If your interview is at 2pm, join the call at 1:55. Your interviewer might show up around 2:03. If they haven’t by 2:05, ping your recruiter (with a prewritten email), and they’ll usually show up around 2:07. This is normal.
• Make sure you understand the video call interface. Different companies may use Zoom, Google Meet, Microsoft teams, Amazon chime, etc. Make sure you know how to screen share or open the chat. Similarly, for coding interviews, get familiar with the tooling you’ll have. If it's Coderpad or Google Colab, you might expect syntax completion and highlighting, but other companies may use plaintext and some don’t even allow code execution.
• Make sure you use the same computer for interviewing and practice. If your job involves writing code and you are comfortable with the setup and layout of your work laptop, you might be tempted to practice coding interviews on it, but this will backfire. You’ll be less comfortable when you take the real interviews on your personal device.

How to get interviews

Getting your foot in the door at big tech companies is tricky. They’ll have careers pages with openings but they’re generally swamped and applying has a low success rate. I’ve had more success with inbound or referrals.

• Do good work, and do it visibly. Publish it and present it at conferences. Release github repos with demos and readmes. Attend networking events and career fairs, ask good questions at talks, offer collaboration and follow through. Acquire citations, github stars, contribute to open-source projects, win hackathons, etc. Companies employ recruiters and talent scouts whose job it is to notice extraordinary talent, and if you consistently do good work, they will notice. But the easier you can make it, the better.
• Connect with old friends. Given how many people work at Google, Meta, Apple, Amazon etc, chances are you have friends there. Networking is entirely normal, and I am confident you’ll rekindle some old friendships and get connected to friends-of-friends who will love getting to know you and share advice. On that note, if you are my friend, my DMs are open. And if our only interaction was a ski trip in Vermont 8 years ago and we haven't talked since, you are my friend. Let’s catch up!
• Have a good linkedin, resume and personal webpage. I don’t actually have all these, but maintaining a Linkedin profile is most helpful. If you list “AI research scientist - large language models” as your job title, you will get inbound traffic, and it will include cool startups that you’ve never heard about. For example, I interviewed at Lila, they are absolutely incredible, and I highly recommend anyone to check them out.

The recruiter intro call

Step 1 in the process at most companies will be a short “informal” call with a recruiter. They will explain their process, they’ll tell you who your hiring manager is and what team they’re on, and for startups, what the company’s mission and strategy is. They might also ask you about compensation expectations. During this call, take notes! I didn’t do this, and regretted it. This might be the last time someone will explain the org chart and team structure, and I’ve had coding interviews 2-3 weeks later where someone would ask what role I was applying to and I didn’t know.

The hiring manager chat

At some point, you’ll likely speak to your hiring manager. After this call, they need to be convinced that you have the skills to do the job that they’re hiring for, and that they will personally enjoy working closely with you for the next few years. There are no cheat codes or secret tips. Your hiring manager generally will have more experience than you, have good judgment and know proprietary information that you don’t (for example, the exact job description). However, there are a few things you can do.

• Do your research. If you’ve been told who the hiring manager is, look them up on Google scholar, read their papers, check their Twitter, watch lectures or talks they’ve given. You’ll understand what drives them, and people generally like it when you pay attention to their content. This isn’t some social engineering trick; investing effort in getting to know them ahead of time is a genuine way to demonstrate your excitement. If you ever have an interview with me, mention this blog post - I’d be ecstatic!
• Be genuine. I hate when people tell me to “just be myself”. But I do want to emphasize being genuine. If you go into interviews portraying a character of yourself, your interviewer will notice, and do so instantly. Humans are good at such things. I am lucky that my personal and professional character are somewhat complementary (a mix of Mr. Peanutbutter and Eeyore). So I can say something like “I want to work at OpenAI because OpenAI is the coolest company in the world” and sincerely mean it. If that sounds unnatural for you, don’t say it and find something that works for you.
• Be humble. This one is hard. You’re caught in a bit of a lose-lose situation where you want to demonstrate competence, explain previous work that you’ve chosen because you believe it reflects well on you, but you don’t want to come across as overconfident. In particular, your hiring manager may have confidential information that they cannot share, and a question like “given your research, do you expect extension A or B to work better” might be something that they know the answer to better than you do.
• Be passionate. I cannot overstate this enough. If you ever interview with me, I will likely ask you “Tell me about yourself, why you want to work at OpenAI, and what excites you about this role”. You should expect this question, have prepared a compelling answer, and it has to be genuine. This could be hard, because you may be applying to multiple places and only one can be the coolest company in the world. But if you do some soul-searching, you can find genuine things to be passionate about in many companies. For example, these are also true statements for me: “My internship at Facebook Reality Labs in 2018 is the happiest I’ve ever been, and I’d love to recreate that experience” and “I am currently writing a Google doc in Google Chrome using a hotspot from my Google Pixel phone. I’ve wanted to work at Google since I was 12.”

You are pitching your current employer almost as much as yourself

I was surprised how often I’d be asked about Imbue, from our research and technical approach all the way to the company mission, business plan, revenue model etc. I’m not sure why  - especially since I cannot disclose that information - but my sense is that some interviewers are just curious, and some interviewers may treat your ability to explain the company mission as a sign of competence and your current choice of employer as a sign of good or bad judgment. Regardless, make sure you have practiced your company pitch, and are able to connect your day-to-day technical work to the overall goal of the company. This shows leadership, I guess.

Behavioral interviews

Most big tech companies have a version of a leadership interview. The Amazon Bar Raiser and Googleyness interviews are notorious. With preparation and practice - around 10 hours is probably enough - you can ace these. There are many articles and videos you can watch and I have little to add.

• Make sure to have anecdotes lined up with rough themes, so “tell me about a time you disagreed with your manager” and “tell me about a time you showed leadership when you were not directly responsible” might point to the same story. When I started preparing these, I realized I had many more stories than I initially thought. Use the STAR(I) format, and try to tell stories with a redemption arc in which you are the protagonist: “I failed to meet a deadline because we had underestimated the workload. I communicated with the customer, put in an all-nighter and we delivered double the value to the customer!”
• In my opinion, this is all a bit performative, though one piece of advice is to have a good answer to “tell me about a time you failed”, because “I never fail at things” can be interpreted either as arrogance or attributed to a lack of trying.

Coding interviews

Coding interviews will make up the majority of your time and it is where the battle is often won or lost. One very important concept is to understand the psychology of the coding interview, and leverage it to your success. The goal of the interview is not to write good code, or to pass tests, or to calculate complexity - it is to make the interviewer feel positive about you as a future colleague. I’ve passed interviews in which I wrote almost no code.

• The interviewer wants you to pass. Because the interviewer is the one giving you problems and judging you, you might assume an adversarial relationship. The opposite is true: the best-case scenario for the interviewer is that you do well and they get to write a glowing recommendation, and watching a candidate struggle is the worst. Generally, they’ll be trying to get you to pass, and you can leverage this. I’ve occasionally straight-up asked: “I would like to pass this interview. What can I do to make that happen?”, and I passed at least one interview this way that I otherwise wouldn’t have.
• Keep intros minimal. Time is against you, and introductory chit-chat is wasted time. You should prepare a short intro like: “My name is Bas van Opheusden, I’m on the research team leading evals for safety & alignment”.
• When you’ve solved a problem, move on! There’s a temptation to spend more time on a problem than necessary, but if you’re doing a multi-stage interview, getting to the next problem as fast as possible is the main goal. You can always do cleanup or chat later.
• Practice coding under pressure. Coding and debugging are hard because you have to accurately simulate machine logic in your head. This is harder when someone is watching, when you’re on the clock, and when that person is giving you “help”. You should practice in the same conditions as the interview: under time pressure and stress.
• Prepare whiteboard coding interviews. Some companies do these. No idea why, but it’s a skill you should prepare for. Practice coding without execution environments, and coding without syntax highlighting. It’s the worst, but you’ll be glad you practiced.
• Practice Python. Most tech companies use Python and pytorch. Some companies will require Python in interviews, some won’t, but there’s a decent chance that your interviewer is most fluent in Python and they’ll be able to help you better.

What to prepare:

• There are loads of databases of coding problems: Leetcode, Codeforces, Kattis etc. To some extent, it doesn’t matter much which you pick, as long as you put in consistent effort and focus on common algorithmic patterns (Binary search, backtracking, dijkstra).
• ML coding might be required! If you haven’t worked with pytorch or similar libraries before, you should get comfortable and be able to implement a simple RL or SFT loop, and understand how transformers are actually implemented in code. For reference, check out nanoGPT, or Let's build GPT.
• For concrete problems - ask chatgpt! You can write a prompt like “I have a coding interview tomorrow at an AI/ML company. Help me practice by designing an interview question”. With a bit of prompting and conversation, you should be able to get pretty reasonable practice problems. Make sure to also ask chatgpt/codex for reference solutions for those problems, I found this extremely helpful ;)

Tricks:

• One trick that I picked up during interviews is the strategic use of todo’s. Imagine you’re writing a bubble sort algorithm. It might look something like:

1 def bubble_sort(arr: list[int]) -> list[int]:

2     n = len(arr)

3     for i in range(n-1):
        4         for j in range(n-i-1):
        5             if arr[j] < arr[j+1]:
        6                 arr[j], arr[j+1] = arr[j+1], arr[j]

When implementing this, you may find yourself wondering (or your interviewer might ask) if it really should be n-i-1 or something else. You can handwave that away or try to talk through it at the time, but my solution is to leave todo’s, so on line 4: #todo: check indexing and line 5: #todo: < or >? And when you finally run this code and find that it is wrong (it sorts descending), having left the todo explicitly in the code allows you to turn a failure into a win: “Ah yes that’s what I worried about. It should be > not <. That makes sense. Cool, I’ll delete this todo now”.

One downside of leaving todo’s is that it might make it more obvious when you’ve overlooked something. For example, in one interview I had to implement a method from a paper and started with

X = torch.zeros([N,N]) #todo: check if initialized at 0?

and then forgot about it. I did not pass that one…

• Leave asserts. If you “know” that a particular variable at some line in your code should be sorted, you can write

assert all(x<=y for x,y in zip(arr, arr[1:])) #arr is sorted

And this might help you remember that fact, or catch bugs if that assumption wasn’t true in some edge case, or you made a typo in the upstream code. You can always comment them out or delete them at the end.

• Consider restructuring the problem. I had one problem in which I struggled because I had to find an event in a log that was sorted most-recent first, and I kept mixing this up. It’s totally fine to start your code with arr = arr[::-1] #now arr is ascending

ML Domain interviews

You may get scheduled for a domain interview, or something similar-sounding. These vary wildly in content, from exam-style questions and answers, to a discussion of a paper you’ve written to “tell me what you’re working on”.

• Prepare for exam questions. Know the basics! Your interview may start with “describe the difference between supervised and unsupervised learning” or “what is linear regression”. You need to be able to answer these concisely and accurately. Make sure you also know the state-of-the-art or recent developments. For example, how do you train a model with 10M context length? How does GSPO compare to GRPO/PPO? What are (toxic) persona vectors? Some interviewers enjoy asking about historical questions, like “name three major qualitative differences between the architecture proposed in Vaswani, 2017 and that of GPT-OSS-120B”.
• Use ChatGPT to prepare. Or Claude/Gemini if you must. But I’ve gotten extremely useful study guides, paper links and summaries from o3 and in particular, Deep Research. If you broadly know what you’re looking for, these tools are exceptionally useful.
• Prepare a talk. Some companies may ask you to give a talk, but even the ones that don’t might ask you to discuss some previous work, and going through a slide deck is far superior to just talking.
• Be ready to discuss your current work. You might get asked about your current projects, and you should be able to explain the goal, your approach, how far you’ve gotten, next steps and how you see it coming together eventually in the product. This can be awkward because you might get asked questions that you don’t know the answer to (it’s empirical and you don’t have the data yet) or your interviewer may have different intuitions than you do. Or they might already know that your approach won’t work but it’s confidential so they can’t share…

Negotiation & Decision

When I started applying, my mental model was that after you conduct interviews, you get rejected at 50-75% of places, get some offers, compare them, negotiate and make a decision. Sadly, this is not how it works. After you pass the official rounds and receive a congratulatory call from your recruiter, there can be more rounds of chats, you might have more onsites, and you might not actually get formal offers for a while. You also have the opportunity to negotiate. I don’t know this world well, but the one thing I’d say is to avoid focusing exclusively on compensation. We’re ML researchers, when we see a number for which higher is better, our instinct is to hill-climb. And you can. But don’t let the number distract you from everything else that influences your quality of life: your team, the mission, the location, the company culture, the food (but actually). Yes, money is nice, but don’t sacrifice happiness for money - that defeats its entire point.

Finally, there will come a point where you actually have to decide what you want to do with your life. If OpenAI has given you an offer, you should take that, it really is a blast here ;) If not, go work for whichever company will put a smile on your face every time you walk through the front door.

Final thoughts

Interviewing is rough and stressful, but also a skill you can master. I hope some of the above helps you in your journey, and I hope we’ll get to work together ;)

Appendix: Learning resources

Here are some resources that I or friends of mine have used to study. I cannot vouch for these, but I hear good things.

• OpenAI cookbook: link
• Huggingface Deep learning course: link
• deeplearning.ai
• The Annotated Transformer (Harvard NLP): Github
• LLM course (Maxime Labonne): github
• NanoGPT (Andrej Karpathy): github
• Let’s build GPT-3 (Andrej Karpathy): youtube
• Stanford CS229 Building Large Language Models (Yann Dubois): youtube
• Stanford CS336 Language Modeling from Scratch (Percy Liang): youtube
• Stanford CS25 Transformers United (Chris Manning): youtube
• MIT Han lab course: link
• Build a Large Language Model (Sebastian Raschka): link
• Build a Reasoning Model (Sebastian Raschka): link