I have (somewhat) recently undergone the rather painful process of finding a job after completing my Ph.D.. I initially wrote these notes around November 2024 after signing with Tesla, but somehow I forgot to publish them. Now that I am almost a year into my professional career, I revisited some sections and decided to share. It appears that numerous resources are available for interview preparation in software engineering positions, but fewer are available for more research-oriented roles. Hopefully, these notes are useful to current Ph.D. students seeking employment as they near graduation.

The following is based on my personal experience interviewing at tech companies. Obviously, my sampling is sparse and incomplete (the inverse would be a bit damning), so your milage may vary. Importantly, this write-up is based on my own understanding and may exhibit strong biases. Make what you want of it.

Types of job

Generally speaking, there are four types of positions one may wish to pursue after a Ph.D. in computer science and machine learning. This list is nonexhaustive, but it can give an idea of the possibilities.

Research scientist

This is the natural continuation of a Ph.D., where you are expected to conduct novel research within the company and make some progress vis-à-vis long-term company goals. Your key responsibilities include defining a research agenda that aligns with the company’s missions, prototyping and implementing novel research ideas, and sometimes publishing your findings in journals and conferences. Your performance will primarily be based on publication throughput and tech transfer (i.e., the process of converting research ideas into useful technologies for customers), or a combination of the two. Publication prioritization will heavily depend on the company.

Research engineer

This is similar to a scientist position, but your main duties are centered around assisting and supporting the researchers. In some companies, the line between research scientists and engineers may be a bit fuzzy or completely inexistent. Your performance may not be based on generating new research ideas, but rather on implementing and optimizing them for more immediate applications. You still need to stay up-to-date with the latest research trends, but you will not be evaluated based solely on your publications. You can still be a co-author on research publications, but rarely the main author. Since this job is more engineering-focused, the expectations on programming skills may be slightly higher than for scientist roles. Some companies, however, apply the same coding interviews across the board.

Software engineer

This is the default job for computer science and software engineering majors. With a Ph.D., you can generally work on cutting-edge technology, and the development may be more interesting than the one you would do with just a bachelor’s degree. This is not always the case, though. These roles generally do not have a research component. Here, your job will revolve heavily around coding as you will mainly develop and support one of the company’s products. This type includes machine learning engineers, which may involve more math in their routines.

Professor

This is the academia route. You will most definitely need a post-doc to be competitive, as very few professor positions are available worldwide. In most instances, you will have to relocate. God bless your soul and good luck.

Recommended timeline

It is recommended to start applying on jobs at least 5-6 months before your expected Ph.D. defence date. Depending on market conditions, this may take longer. You should also start practicing Leetcode at least 2-3 months before that if you want to improve your chances of getting full interview loops. This sounds crazy at first until you get absolutely demolished by your first live coding interview (yes, I’m speaking from experience).

Research scientist positions tend to be a bit more flexible regarding starting dates, as the impact of your work will be less immediate. Pure engineering positions, on the other hand, tend to be more stringent. For scientist roles, employers may wait up to a month for a candidate decision after an offer is extended. In my experience, this is less true for engineering positions, where employers generally expect a response within a few days or weeks at most, as their needs are more urgent. As usual, this may greatly vary depending on the company. If you are in doubt, you can ask your recruiter at the end of the HR screening round (see below).

A normal interview process with a company can take anywhere between 1-3 months, from time of application to an official offer. Different stages of the interview may span several weeks, but it is also possible that everything gets scheduled over just a few weeks. Generally, you will provide time slots for each stage, and the recruiter will assign and coordinate all interview rounds. If you have competing offers, companies will tend to move more quickly through the interview process if they believe you are a good fit.

Typical interview process

Every tech company will have a different interview process for candidates. There seems to be, however, a common pattern between them. Below, I list the most frequent steps I’ve learned to navigate; however, note that the order and nature of these interviews are always company-dependent. Smaller companies may also have fewer rounds than larger ones. In almost all instances, you will get a subset of the following steps.

Note: If what follows feels overwhelming and borderline abusive, it’s because it is for the most part. However, when you consider that 1) research/engineering positions in big tech companies pay upward of 200k USD for Ph.D. grads (sometimes even 300k+ with stocks) and 2) CS has never been this popular, you may start to understand why. It’s a supply-and-demand problem, so breaking the barrier to entry will be tough. The cost of hiring a bad employee is necessarily much higher than passing on a good candidate, so companies will always double-down on this.

HR screening

The first round is almost always with a recruiter. They are only 30 minutes on average. The recruiter will provide a more detailed explanation of the position and may ask you to summarize your work experience and general interests to assess your fit. The tone is mostly casual and the recruiter will lead the discussion for the most part. This is also where they will ask some logistics questions for relocation (if applicable) and if you are interviewing with other companies. One of the primary purposes of this interview is to provide you with details regarding the full interview process going forward, so you can prepare adequately. At the end, be prepared to ask at least 1-2 questions about the role (e.g., team size, team location, management style), as (good) recruiters will always save time for these.

Research talk

For research scientist roles, you will be asked to give a research talk to the team. This may also apply to engineering positions (this was the case at Tesla). The format of this talk will be provided by the HR recruiter, but it varies between 20-50 minutes. You will be asked to present what you have done during your graduate studies. Some companies may want you to discuss a specific project to dive more into the specifics. For research talks, this is somewhat similar to a Ph.D. defence, but the questions you will get from the audience will be nowhere near as precise. The audience will primarily consist of your potential manager, your team, the HR recruiter, and possibly a few other individuals in adjacent roles. It may also be recorded and broadcasted to a larger audience within the company. It is your time to flex your best and shiniest results, emphasizing broader impact. Importantly, you must highlight some research avenues you would like to explore if you were given the role. Of course, make sure this aligns with the position you are applying for.

Here’s a cute recipe that works well (courtesy of Peyman Milanfar on X):

  1. Short overviews of a few of your works, drawing a common theme across them, if there is one (15 mins).
  2. Deep dive into one project (20 mins).
  3. Summarize & talk about what you think are important new directions to pursue in research and how these could have an impact on the team and the products of the company (5-10 mins).

General coding

Most companies will want to assess your coding skills, and the industry standard for this is Leetcode-style questions. Anything you could be asked on an undergraduate-level algorithms and data structures exam is fair game, from linked lists to graph traversal to dynamic programming. Since a Ph.D. is not about being an expert in all of these, performing well on this round requires practice. There are uncountably many guides online on how to get better at these types of interviews, but the bottomline is: practice and voice out your approach. Do not take this step lightly and start early (a few months before applying). It can be as little as 15-30 minutes a day, but try to be consistent. You may strongly disagree with this industry practice, but you will undeniably run into Leetcode live coding interviews at some point during the hiring process, so you’d better be prepared.

Live coding interviews are usually scheduled early in the process, and getting to the next round is, more often than not, conditional on your success here. This interview typically lasts 45 minutes to 1 hour and is conducted in Coderpad. Generally, you can choose the programming language you’re most comfortable with unless the job has specific requirements (e.g., C++-only roles). Depending on the job title, you may not need to be perfect on all problems to reach the next round. It is possible to do well on these without much practice, but the outcome will be almost entirely based on luck. It is unpleasant, it is brutal at times, but it is a necessary step, so just bite the bullet and hit the Leetcode grind.

Technical knowledge

This is an interview with a technical team member (e.g., your potential manager), typically conducted after the coding interview. The goal of this interview is to assess your knowledge on the topic related to the role you are applying for. The interviewer may ask more in-depth questions about your Ph.D. and/or internship work. They may also give you hypothetical problems to solve just to pick your brain and see how you approach them. There is generally more than one technical interview, and your interviewers will touch on different subtopics (e.g., computer graphics, machine learning). These tend to be more verbal, but there may be a live coding portion that will correlate with the questions asked. There is no good way to prepare, as the breadth is simply too large to do anything meaningful beforehand. Be ready to talk about your accomplishments (problem → solution → outcome) and your research. Try to make it relevant to the role, but don’t force it if that’s not possible. Technical interviews tend to be scheduled back-to-back as 1:1’s with team members, so be prepared for a half-day of interviews.

System design

Only a few companies may do this (e.g., Meta, Amazon), but this is where you will be asked a question that is intentionally ambiguous, aiming to design a larger system that may be more product-oriented. This is essentially to scope out how you would approach larger hypothetical systems from a top-down perspective, considering requirements such as scalability, consistency, and privacy, among others. Examples for SWE include designing a ticket booking app or an ML-based recommendation system. For research-oriented roles, it is usually more of a discussion relevant to the role and your background. There are no right answers, as the goal is to assess your problem-solving skills with specific requirements in mind. In this interview, you might use Excalidraw to draw the design of your system and how users will interact with it. There is usually a lot of engagement with the interviewer in this round.

Behavioral

In general, this is the final interview, and it is where the interviewer will quiz you on various situations involving human interactions. This can include anything related to conflict resolution, navigating ambiguity, receiving and giving feedback, company mission alignment, and more. Common sense is your best friend here, but be prepared to answer questions you’ve probably never been asked before. Be strategic and prepare stories that fit many questions, such as “tell me a time you had a conflict at work and how you resolved it”. These interviews can range from 15 to 45 minutes. People like to suggest the STAR method (Situation → Task → Action → Result), but personally, I prefer the SPSIL approach (Situation → Problem → Solution → Impact → Lesson) to answer. In the absence of a real-life story to answer the question, answer hypothetically. Never make up something on the spot, interviewers will see right through this with follow-up questions. It can be useful, however, to slightly blend and merge some stories together if you are completely blanking on a question.

Security check

Depending on the company and team you wish to join, you may have to deal with highly sensitive intellectual property (IP) and customers’ private data. While most companies will have security training courses to be completed upon joining, some have started conducting short interviews during the hiring process to make sure you fully understand what’s at stake. More often than not, this is folded in the behavioral round, but sometimes it will be a separate round with a security investigator. This round is quite short (15-30 minutes) and will ask you certain questions regarding restricted material handling. An example question could be: “If you see an employee using company material for their side hustle, what would you do?”. Again, just use your common sense.

The offer

If you made it this far, congratulations! Now it is time for the good stuff: negotiating base salary, sign-on bonus (if applicable), and awards (e.g., cash awards or stock options). Nowadays, job postings in tech will include the salary range for the role, so there should be no surprise there. If that is not the case, you may ask the recruiter in the screening round to save yourself the hassle: “I noticed there is no salary range for this role, could you tell me a bit more about this?”. Be polite and courteous. Most notable companies will accept providing this information to candidates.

Now, I don’t have a lot of experience here, but here’s what people seem to agree on. Upon receiving an offer and meeting with your technical recruiter, let them do the talking first. The general rule of thumb is to never accept an offer on the spot. Always take a few days to think about it, if you can. Always try to negotiate, but do so carefully. The recruiter will either say this is the best they can do, accept your counteroffer, or suggest something in between. Don’t be greedy; the salary will already be quite good in most cases. Asking an unreasonable amount can kill the offer entirely (yes, this actually happens, according to reddit). In doubt, you can check levels.fyi for ballpark estimates, but keep in mind that there is self-selection bias there.

In an ideal world, you would synchronize job interviews and receive multiple competing offers that you can leverage. In reality, this can be quite difficult to achieve as companies have vastly different hiring timelines. This is especially true for research scientist positions, as they are not always looking to hire immediately and may instead let the pool of applicants grow indefinitely until the right ones come along. Recruiters will often ask about your interviewing situation with other companies in the first round. They will then adapt the pace accordingly. Also, be sure to mention any other important deadlines you may have (e.g., thesis defense, paper submission) so that there are no surprises.

You will typically be asked to decide to accept or decline an offer within 1 week to 1 month, so make sure that you are clear with the deadlines this involves. Keep your recruiter informed about other offers that may arise, so you can re-negotiate when a better opportunity presents itself.

Finally, remember that different states have different income tax rates. For instance, a higher base salary in California (25.7% tax) does not necessarily mean a better deal than a lower base salary in, e.g. Washington (18.5% tax). You can use this tool to calculate your after-tax income for the US. This is a no-brainer, but you should always factor in the cost of living in your final decision.

Keeping a pulse on the market

The post-grad job market for computer scientists is entirely dependent on the economy. This can change drastically in a matter of a few months and there is nothing you can do about it. It can be cruel, and you don’t get to choose the timing. For instance, you may receive emails from recruiters well before you plan on graduating. This signals you are in-demand for the current job market but sadly it does not mean anything regarding the future job market. Always remember this.

As an example, neural scene representations were a very hot topic from 2020-2022 with the advent of NeRF. Companies were hiring hundreds of people in this domain. Then, LLMs emerged a year later, and generative AI ultimately dominated the vast majority of computer vision job postings by early 2024. Companies absolutely love the AI hype and constantly ride new waves. Today, it’s GenAI; who knows what it will be tomorrow? When the hype dies down, big tech companies just lay off people and rehire them elsewhere a few years later… by then, it’s too late. This was a harsh reality check for me: even with three research internships at top companies (NVIDIA, Reality Labs, and Adobe), it can be extremely difficult to land an interview, depending on market conditions and graduation timeline. For the record, I only got an interview at 1/3 of the companies I interned at and did not get an offer, despite strong referrals. I like to think the story would’ve been a bit different two years ago, but maybe I’m delusional.

Be prepared to navigate this environment and stay attuned to the market to minimize disappointments. This may further inform when you actually graduate. There is no need to rush graduation if the market is not in your favor. For example, the majority of tech companies went into a hiring freeze in early 2023 when the stock market took a dive in late 2022; graduating there would have been a terrible timing for new hires. If you have some wiggle room on your defence date and are privileged enough to have funding to continue, be strategic and use it.

Tips & tricks

There is an almost-infinite supply of tips online to prepare for SWE interviews, but here are a few that I found particularly useful:

  • Interviewing requires preparation: you will not land your dream job simply off a good publication record alone.
  • Practice Leetcode daily (yes, for real).
  • Adapt your resume to make it relevant to job, and make a 1-page version for more engineering-focused roles where publications may not be as central.
  • If you interned at a company, make sure to mention this in your application.
  • If the company as an explicit referral system (e.g., Meta), by all means use it.
  • While interning at a company, ask about the full recruiting process and take notes for the future.
  • Keep applying on new job postings daily/weekly even if you have secured an interview somewhere.
  • If you have some traction on social media (e.g., BlueSKy, X, LinkedIn) due to prior publications, make a post about you seeking employment.
  • For live coding interviews, explain your reasoning as you code. It is fine to pause and ponder a bit, but most of the time you should be talking and describing what you are trying to achieve.
  • If you are not sure how an interview will be conducted, ask for more details from your recruiter. Remember, they want you to succeed, too!
  • Look up your interviewers beforehand so you can ask them relevant questions at the end.
  • Try not to visualize or to get emotionally attached to the role before getting an offer (harder than it sounds).
  • Use ChatGPT to come up with:
    • Mock questions for technical knowledge and system design for your area of expertise.
    • Good questions to ask your interviewers at the end of rounds.
    • Memory joggers to find good stories to tell in the behavioral round (this worked surprisingly well for me).

Example questions to ask your interviewers

  • What’s the best thing that happened to you here since you’ve joined?
  • What’s one thing you dislike about working here?
    • Better (and more honest) answers usually come from experienced employees, so check seniority first.
  • How does the team balance between research and tech transfer?
  • Are there any clear incentives to publish within the company?
  • Who creates deadlines and where do they come from?
  • How is the research team structured? Who leads and decides the general direction?
  • How often do priorities change within the company?
  • How often are employees evaluated? What makes your best researchers stand out in these evaluations?
  • Is this an entirely new role, or would I be replacing someone who left? If the latter, why did they leave?

Some personal statistics

  • 80 applications sent over 3 months between August–October 2024 across Canada, USA & Europe, primarily targeting rendering and ML roles.
  • 48 no answers / 23 rejected / 8 interviews granted / 1 interview declined (after accepting Tesla’s offer).
  • 7 did not move forward or no offer / 1 offer (Tesla, accepted).