Navigating the career transition from physics to tech

I recently transitioned my career into the tech industry from academic research in physics. This is not uncommon these days among physicists — I recently browsed what my PhD classmates are up to, and found in fact that all except a few are now working as data scientists. However, I found relatively little advice online about how to navigate this particular transition. While there is a lot you will find about how to prepare for tech interviews in general, the vast majority is catered to folks with CS backgrounds. Much of this “standard” advice is indispensible – but I found that some of it was actually counterproductive. So I thought I would share a few thoughts on the process, in case this may be helpful to fellow academics looking to move into tech. I will try to keep this general, such that it is applicable to any technical role. At the end, I’ll share more specifics of my personal experience and prep strategy. Please let me know if you find any of this useful, and how your own search process goes!

Table of Contents

Three steps

One of the most challenging aspects of this process is that as an outsider, you will have a huge degree of uncertainty about the entire process. You may not know what roles you actually want, let alone how the tech ecosystem operates or how to interact with recruiters or interviewers. The most important advice I can give is this: think deliberately about how you will navigate each step in the search process. Take initiative, not just in your actions but in your strategizing. You likely carry many implicit assumptions about how these things work in academia, and those can mislead you here. For each conversation, each line on your resume, each week of prep – ask yourself what you are trying to achieve, what you are uncertain about, and how you will be perceived by folks in tech. You likely have nearly all of the core technical skills required to be successful in tech – and while your competence in technical skills is crucial, equally important in determining your success in the transition is whether you can step back to design, implement, and iterate a self-marketing campaign tailored to your strengths.

Before diving in, you’ll need to plan logistics. The amount of time it takes to go from “I’ve decided to transition into tech” to “I’ve signed an offer” will vary dramatically, depending on your background, the job market, your application/interview performance, and perhaps above all, luck. Generally, I would say you should expect to spend in the ballpark of at least 6 months with at least 50% of your time – often more. This is often a huge challenge since you typically still need to be working your academic job – gear up for an intensive period. Ideally you should lay the groundwork for this transition a year or more in advance by leading a project that is closely related to your desired position.

To my mind, there are three basic steps to a search process:

  1. Gather information
  2. Prepare
  3. Apply and interview

(1) Gather information

This is probably the highest leverage step – it requires you to put yourself out there a bit, but can have massive benefit. The idea is simple: talk to many people, and talk to them early in your process. Your initial goals should be twofold:

  1. What type of role(s) do I want to target?
  2. How should I prepare?

You should likely narrow down to one specific role: Research scientist, software engineer, data scientist, etc. – since the interview content will differ for each. Understand where the opportunities are (companies, locations, etc.) given your ultimate goals. For example, do you want to work at a large company or small company? If your goal is to do research, large companies offer more opportunity – on the other hand it is difficult to get a FAANG-type job in your first round. You may be able to do it — certainly not impossible, and certainly worth trying if you are interested — but a common path is to first work at a startup (for which the hiring bar is in general a bit lower, since compensation is lower) and after you gain experience you will have more freedom. Build an understanding of trajectories that can lead to your eventual goals, and how feasible they are.

Try to talk to a diversity of folks: physics-to-tech people, pure tech people, researcher vs. software engineer vs. data scientist. Of course, start by talking to your friends or classmates – they often may also have adjacent friends that they can connect you with for a brief chat. I also recommend to reach out on LinkedIn or by email to folks that you may not know personally but have some sort of connection to – a common workplace, a similar transition. The vast majority of these will not respond to you, but a couple likely will – and these can provide critical advice. The process of browsing for folks with your target position is itself highly valuable – look at their profiles to build an understanding of what to target.

When you set up chats with people, make sure to prepare for them. Don’t just ask them questions that you could look up online. A fifteen minute chat with the right person can be invaluable to your search process, but only if you prepare and make the most of it. Always be appreciative. Try to ask if they know of any useful resources or anyone else that might be useful to talk to.

Now, there is a major caveat that I would like to add to the above. I found that many people have strongly held (often implicit) opinions on what directions are good/bad. So you will have to use your judgment in how to synthesize the information that you gather. For example, I was very interested in a research or research-adjacent role, however many engineering-minded folks had negative opinions of this career-wise (but they do not share my passion for research). Be open-minded when gathering info, but also do not blindly take people’s word for everything.

  • Example 1: people told me that AI residencies were the best option to get into research. I think this was true probably 2+ years ago. My experience however was that there were only a couple options to apply for, and these were extremely competitive — they gave some automated coding assessments that if you do not ace, you will not get even a first-round interview. So for me that option quickly died, and I updated my goal to try to get to a place that can build my ML research / engineering skills and slowly move towards the direction that I want.
  • Example 2: the hiring market can vary dramatically over time. From e.g. 2012-2021, it was red hot in tech. In 2022, it froze, and in 2023-, it is in a middle ground. People who got their jobs pre-2021 simply had a much easier time, while people in 2022 had an almost impossible time. Often people do not realize this, and they have strongly held implicit opinions about how easy/hard it is to get a job.

(2) Prepare

Once you identify your desired role, it’s time to prepare. In terms of time spent, this stage should take the most. There are two very different types of preparation you will need to do: prep to get interviews and prep to pass interviews. For each of these, you will need to find a prep strategy that works for you. This means finding a balance between trusting people’s advice and trusting your own instincts.

(a) Getting interviews

To get interviews, you need to create strong application materials – a resume and an online presence showcasing some of your work (e.g. GitHub). Figure out how to position yourself, both strategically and in presentation. Most places do not care if you wrote 10 papers in physics. They certainly do not want to see the titles, unless they are clearly relevant. Try to have at least one project before transitioning that will be directly relevant, e.g. applying ML to your research. My strong suspicion is that it really doesn’t matter all that much whether you have 10 relevant projects or 1. The key thing is that it gives you something concrete to focus on in your resume and in your interviews. Of course having 10 projects is better, but for getting interviews the returns I think are highly diminishing. But going from 0—>1 is hugely important. Similarly important is that the project is actually centered around cutting-edge methods – a project using diffusion models can often get you noticed whereas a generic classification task may not. Remember that due to high employee turnover companies will not hire for “potential” – you need to demonstrate that you already have the skills to hit the ground running.

A common pitfall is that you may want to comprehensively list all the accomplishments you have accrued in academia. Don’t do this. Your biggest challenge to overcome is not a lack of general experience – it is being an outsider. A concise resume that highlights the 20% of your accomplishments that are actually relevant, and omits or confines to a couple lines the remaining 80%, is a winning resume. There is an analogy to pursuing faculty interviews – if you approach it with a mindset of “if I write N papers my prestige will be recognized”, you will almost certainly fail. You need to think strategically – how to present yourself. Your goal is never to list all the work you have done. It is to present a compelling image.

In addition to your application materials, networking is of course important. This is especially true at the extremes of company size – early-stage startups, which are less advertised, and big tech, for which referrals are often a prerequisite to anyone ever seeing your application. Keep iterating on your application materials as you network, and get feedback from insiders.

(b) Passing interviews

Given your target role, you can find loads of information online about the specifics of the common interview processes. Almost certainly this will require you to train extensively for coding interviews. I’m not going to repeat the basics that you can read about elsewhere, but I will just say this: adapt your prep strategy to your own strengths and weaknesses. The common online advice (implicitly meant for CS-related backgrounds) may or may not work well for you.

  • Example: People with a tech background typically told me to prep by doing leetcode problems every day. However eventually I got advice from a physics—>tech person that told me they found it very useful to not just do problems every day, but to first spend some hours studying each of the different patterns to make sure you really learn and engrain them — and then do practice problems. I found this tremendously more effective. The tech people’s advice was probably right for a tech person who studied these things already in CS courses, but for me, having only vague familiarity with many of them, the right strategy was different.

And of course: make sure you are sufficiently prepared before wasting real interviews before you have a reasonable chance of passing them. As you near that threshold, do mock interviews – training your nerves is just as important as your coding patterns.

(3) Apply and interview

Once you feel you can pass the interviews that you expect for your role, it’s time to apply. A few interview tips:

  • Use their jargon – make them feel you are one of them, not an outsider
  • Move quickly — communicate and listen to feedback from your interviewer, but at the end of the day it is up to you to make sure you demonstrate the skills they are looking for
  • Adapt the skills you seek to demonstrate for the specific role (e.g. lean into SWE for MLE roles, lean into math expertise for applied scientist, etc)
  • You may encounter some interviewers who are incompetent to judge your skills. This happened a couple times to me. This is part of the luck that is out of your hands. Be patient, do your best with them.

Do your best to stay in a mentally good place. This part of the process is gruelling. You have to put yourself out there completely, make yourself vulnerable, make uncomfortable introductions when networking, and most of what you will get back is rejection after rejection. Tech is worried about false positives, and is willing to tolerate false negatives. Don’t take it personally. This is the nature of the process. But you only need one offer. So it becomes really important to keep yourself in a good place, since your ability to keep prepping and your interview performance and your strategizing can get boosted a lot by this. For me, this meant getting enough sleep and exercising frequently to reset and de-stress. And having some personal outlets to talk about your process with (partner, friends) — being mindful to not let your interactions only be you complaining.

Keep notes of your goals. You will likely oscillate between feeling excited and feeling hopeless. You may have lofty goals to start, which then gradually get whittled down to moderate goals, and you may have to make judgment calls about how much to push for exactly the thing you aimed for vs. what you can immediately get. It is difficult to keep perspective on what you really want when going through this difficult, extended process that is filled primarily with rejections. I found it helpful to keep a log of some notes as time went on — e.g. what my goals were and how I planned to divide my days (e.g. coding prep / ML prep / networking / etc). Looking back on these was helpful to keep me on track, and to make sure I was thinking deliberately as my situation evolved. Another great way to do this is to have periodic conversations with friends who can ground you with bigger picture goals or questions.

Takeaways: lessons as a physicist

  • Gather information – but keep a healthy skepticism towards what people tell you – tech folks are often overconfident in their assessments
  • Put a lot of effort into how you present yourself - your resume, your pitch, your online projects / portfolio. By default you will be perceived as an outsider – pre-empt this by dispelling common concerns, using their lingo, etc.
  • Adapt your interview prep strategy to your needs – e.g. find a balance between studying common coding patterns and solving example problems

Summary of my search

I outline below some details of my personal experience, in case it may be useful in some way. Full disclaimers to take it with a grain of salt – my goals, background, luck are probably different than yours.

My goals

I was aiming for technical roles in machine learning, spanning between research scientist and machine learning engineer.

Process

April 2023:

  • Interviewed at a startup that had reached out — did not do great but was very useful baseline. This kicked off my process.
  • Began prep — perhaps 50% of time. At this stage, the prep was varied:
    • Trying to determine roles to target — reaching out to many folks to gather info. Key step for (i) information gain, (ii) building network for referrals when you are ready to apply
    • Resume construction
      • This took quite a few iterations to get it right — probably 5 times I reached the point of “OK I think I am there” and then a week later I would look again and understand how I could make an important phrasing change or highlight a project in a better way.
      • Here it can really help to have a project on a “hot” topic, even if it is not the main thrust of your work. For example, despite that I had numerous papers on ML for physics, I had been recently working on graph networks and diffusion models (hot topics — unlike some of the ML for physics papers, despite that they were probably more important for physics). I got many interviews based on these two topics – I listed them as “active projects” and pointed to my code on GitHub and that was enough. The project of course needs to pass a certain threshold that you have a code base (doesn’t have to be huge) and can discuss the projects in some detail.
    • Portfolio construction, to link to projects in the resume. For me this was linking to GitHub repos that I curated a bit to introduce projects at a high-level. This is important (1) to signal to recruiters that you are a serious technical person, (2) Have serious content that technical people would respect in case they do look in detail.
    • Interview prep
      • I identified that coding interviews were something I needed to work a lot on. I am someone with a decently strong coding background, however I had been spending a lot of time lately in my physics career developing skills more aimed towards slow, deep thinking rather than quick, clever thinking. Coding interviews (and other technical interviews, e.g. ML/math) felt like going back to school. That requires both a mindset change (don’t get frustrated by going back to school) and a significant amount of studying and practice. I started doing leetcode regularly (ideally every day, in practice often in spurts on and off).
  • I continued like this until Sep, which is when I felt I was getting close to being ready to apply. I didn’t feel completely ready, but I felt close enough that I would have a shot, and that it was time to get in the game.

Sep: Began submitting applications. I applied to basically every company I could find that had a role I wanted (ranging from research scientist to MLE). I sourced job openings from a multitude of sources: LinkedIn, chats w/network, directly searching company websites, searching for startup lists from VC firms, etc. For large companies, I tried to identify a contact at each for a referral. I used a spreadsheet to keep track of everywhere I applied, along with notes for any interactions I had with them.

Oct: First interviews and recruiter chats. Continued to submit applications.

Nov 2023: More first round interviews, and passed to first final rounds. Received first offer. The moment I had an offer, I wrote to all of the companies where I was talking to someone (either a first-stage interview or a recruiter contact) to mention the offer and ask if there is anything they can do to help expedite. Most places jumped at this, and I went from having 2 final-rounds at the time of my first offer to having ~7 total final rounds by the time my process wrapped up 2 weeks later.

Dec 2023: Negotiated and signed.

Outcome

By the numbers:

  • Applications: 124
  • Screening rounds (primarily leetcode-style): 15
  • Final rounds: 7
  • Offers: 4

I found that there was openness to physicists in three specific ML areas: (i) autonomous vehicles, (ii) ML for science (mainly biotech), (iii) LLM-related startups who were looking for an applied researcher to read papers and incorporate into their product.

Aside: I also explored postdoc options in ML, in order to pave the way to research scientist roles — however this was largely unfruitful. I learned that postdocs in ML are much less common than in physics, since ML is “simple” enough that grad students can be highly productive, which is much less the case in physics — in physics postdocs are typically the best bargain you can find in terms of research output.

Some resources I found helpful:

  • Coding
  • ML
    • ML basics:
      • Textbooks, googling, reading blog posts to get sharp on all core concepts (e.g. backpropagation, attention, …)
      • Coursera’s deeplearning.ai
    • A bit of AI design, e.g.
    • Literature: go through a handful of the major papers (e.g. transformer, diffusion, etc) — but didn’t bother trying to follow all latest developments (most are not that important)
    • ML software: I maintained experience with pytorch and tensorflow, and some jax — important to know but usually don’t need lots of detail. More important is having some understanding of memory/compute tradeoffs, scalability, etc.
  • A few mock interviews through prepfully — costs money but well worth investment. Alternately you can ask friends to mock for you.
James Mulligan
James Mulligan
Machine Learning Researcher