For better or worse, a PhD is a time constrained endeavour. For me, this represented almost 5 years of full-time research in Computer Science at KTH. When approaching completion, the decision of whether to pursue a career in academia or explore other paths lay before me. After some key considerations, I decided to look for a job in the software industry,¹ and I’m thrilled to share that I have recently accepted a position as a Data Engineer at a big Swedish company. In this article, I aim to share insights from my personal job-seeking journey as a PhD student transitioning from academia to industry. My intention is to provide fellow PhD students (and anyone contemplating a similar path) with valuable advice and firsthand experiences that can assist them along the way. As someone who has gone through the process of securing a job prior to completing a PhD, I understand the challenges and uncertainties you might face. I hope my story will offer some clarity and inspiration for those about to embark on their own professional journey… way beyond academia.

Realization

The “default” decision to stay in academia after obtaining a PhD is often influenced by a myriad of factors, with one significant consideration being the natural and very human inertia of sticking with what is already familiar and known. As a result, many PhD students are not fully aware of the vast opportunities that exist beyond the confines of academia. For many, it is quite a challenge looking for a professional career elsewhere. Fortunately, I recognized the potential for growth and success outside the university, and made a conscious decision to explore my options beyond its gates.

Contrary to what is believed, academic freedom is not a holy grail for PhD students, researchers, and professors. As a PhD student, your supervisor essentially functions as your manager, overseeing your work and progress through regular meetings and updates, just like any other job. For many PhD students, this dependence on the criteria of their supervisor can be stifling, as the fruits of their hard labor often rest squarely in their hands. Furthermore, even supervisors themselves are under constant pressure of producing a certain number of publications within their field every year, especially if they are young. For supervisors, research is a means to an end, and the end is often recognition and tenure. For PhD students, to be the smallest fish in the food chain can create a lot of tensions and additional stress due to heavy workloads and multiple sources of mental pressure.

Financial considerations also play a significant role in the decision to stay or leave academia. PhD salaries for Computer Science students in Sweden are notably lower than those offered by tech companies such as Spotify, Klarna, Telia, or Ericsson. In addition, as a PhD student, you may be required to take on additional responsibilities that are not directly related to your research, such as teaching, handling workshops, and supervising Master’s students. In contrast, a career in tech at one of the big companies mentioned before (after graduating in Computer Science) can easily double the salary of a PhD student which much less work overload, making it an attractive alternative.

I also observe that the impact of a PhD student’s work can be quite limited sometimes due to the solitary nature of conducting independent research.² This lack of human collaboration can hinder the scope and impact of students’ work. In an industry setting, however, you could have the opportunity to work with diverse people and contribute to projects with a much broader impact (if being in the right place, of course). This prospect of having a good work-life balance without the stress of research ultimately solidified my decision of transitioning from academia to a career in the industry.

Preparation

Having a PhD in Computer Science is not enough to get a (good) job in a big company.³ You need to prepare yourself well for the interview process. In my case, I wanted to get a Senior Software Engineering position where I could apply the skills I learned during my PhD and also get some freedom to do my independent research.⁴

To qualify for these roles, you must hone the following three skills:

1. Solving technical problems: You must be able to solve coding problems under time constraints.
2. Understanding software systems: You must have an in-depth understanding of software systems.
3. Conducting independent research: You must be able to demonstrate your unique research capabilities.

In the following sections, I will give you tips and resources for enhancing the first two skills, whereas the third one can only be fully acquired upon completion of a PhD 😄.

Behavioral Interview

The behavioral interview is the first step in the interview process. It consists of a series of questions about your past experiences, why you want this particular role you’re applying for, and what you know about the company. It is a way for the company to know you better. There is no clear way to prepare for this kind of interviews. The only thing you can do is to be yourself, in a natural way.

Coding Interview

The coding interview is usually the second step in the interview process. It consists of a series of coding problems that you need to solve under time constraints. You can find such kinds of problems in sites such as LeetCode or HackerRank. Some companies do it on-site, while others do it remotely. The only way to do well in this kind of interviews is to practice a lot. I would recommend solving at least 30 problems before applying for a job.

I used to participate in competitive programming contests when I was an undergraduate student. So, I was familiar with this kind of problem and just need a few weeks of preparation to revive my dormant skills. Still, I solved around 30 problems before applying for a job. If you’re not familiar with these kinds of problems, you probably need at least one month to prepare yourself. Start with easy problems and then move to problems of medium complexity (I suggest skipping hard problems unless you’re applying to FANG companies).

Q: Do I need to pay for a particular course to prepare for the coding interview?
A: No, you don’t need to pay for any course because there are plenty of free and good resources available online, and you just need to know which ones are the best.

I recommend the following resources to prepare for the coding challenges (all available on GitHub):

• https://github.com/jwasham/coding-interview-university Knowledge
• https://github.com/alpha037/data-structures-and-algorithms Knowledge
• https://github.com/Avinash987/Coding Training
• https://github.com/lee-hen/Algoexpert Training

System Design Interview

For software engineering roles, the system design interview is usually the third step in the interview process. It consists of a series of questions about how to design a software system. For example, how to design a social network, a search engine, a video streaming service, etc. The goal is to test your ability to design a system that meets certain requirements (e.g., performance, scalability, maintainability, etc.). The requirements are usually not clear upfront, so your task is to ask questions in order to clarify them. Overall, the main goal of the interviewer is to determine if you have ground knowledge about how large software systems work and experience at working with such systems.

To be honest, I initially found myself unfamiliar with the intricacies of designing complex, real-world software systems. As a researcher, my expertise was more rooted in the realm of algorithms, data structures, and open-source software development. So, my abilities were applied to projects which much smaller scale. For me, expanding my knowledge to encompass large, multi-faceted software systems required some learning curve. I dedicated a couple of weeks to self-study about practical applications to grasp the complexities and interrelationships inherent to these kinds of systems.

I suggest first focusing on one particular large-scale system and learn how it works (for example, a global booking service). Given my previous expertise, I also decided to focus my training on one particular software stack: the Java stack. In particular, I learned about the following technologies:

• Spring Boot: The framework for building web applications.
• Hibernate: The framework for mapping Java objects to relational databases.
• MySQL: The relational database.
• Redis: The in-memory data structure store.
• Docker: The containerization platform.
• Kubernetes: The container orchestration platform.
• Azure: The cloud platform.
• Swagger: The API documentation tool.
• Postman: The API testing tool.
• JMeter: The load testing tool.
• Grafana: The monitoring tool.
• Prometheus: The time series database.
• Elasticsearch: The search engine.
• Kibana: The visualization tool.
• Logstash: The log pipeline tool.
• Jaeger: The distributed tracing tool.
• OpenAPI: The API specification tool.
• Kafka: The distributed streaming platform.
• Zookeeper: The centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
• … and many more.

I recommend preparing for the System Design Interview using the following two resources:

• https://github.com/donnemartin/system-design-primer

• The book “Designing Data-Intensive Applications” by Martin Kleppmann is a must-read for anyone who wants to learn about how large-scale software systems work.

I strongly believe that communication skills take precedence over technical skills in these types of interviews. The ability to ask questions, clarify requirements, and explain your design decisions often outweighs pure system design knowledge. It turns out that my years doing whiteboarding and exchanging research ideas with colleagues resulted immensely beneficial for doing well in this kind of interviews.

Application(s)

First, I recommend having a clear idea of your desired technical role, and then identify the companies you want to work for. For PhD students and researchers, the most common roles are: Software Engineer, Machine Learning Engineer, and Data Scientist. Then, you need to find the companies that have open positions for such roles. Just pick a company and search for the “Careers” section on their website. In my opinion, one of the best career paths for researchers is to work in an R&D department at a big company.

I use Glassdoor to check out salaries and reviews of companies. Then, I use LinkedIn to find recruiters and people that work in those companies. I “cold message” them asking for details about open positions. I also applied directly to the job offers that I find interesting and let recruiters known about my applications directly via chat. I believe the human factor is key to getting an interview. Being professional and polite is super important, thus I always thank the recruiters for their time and support.

I rely on a Notion sheet to keep track of my job applications. This is important because with the time you will have a lot of applications, and you will need to keep track of them. The worst thing that could happen is that you get a call from a recruiter, and you don’t remember the name of the company or the details of the position you applied for.

Every time I applied, I filled the database with the following fields:

• Company: The name of the company.
• Stage: The stage of the application process (e.g., “Applied”, “Rejected”, “Followed-up”, etc.).
• Position: The title of the position.
• Posting URL: The URL of the job posting (use the original posting from the official website, not the ad in LinkedIn which disappears after a while).
• Date: The date when the application was made.

Here’s an example of how it looks like:

Interviews

At large companies, the interview is usually a multi-step process. The first step is a phone screen with a recruiter.⁵ The recruiter will ask you about your background and your motivations for applying to the company, and (hopefully) the recruiter will also ask you about your salary expectations. It is important to prepare a sound argument about why you want to work for the company and why you are a good fit for the position in particular. For example, in my case, I only applied to companies that I have some reference about (e.g., I know someone who works there, or I know someone who knows someone who works there). Take into account that the recruiter may not be familiar with the technical details of your PhD, so you need to explain your research in a way that is understandable to a non-technical person. If the recruiter asks you about your salary expectations, this is a very good sign because it means that the company is really interested in you, so be prepared to give her a reasonable salary range.

As a PhD student, you don’t want to apply to companies that don’t take into account your research experience. If you get some questions such as “How many years of experience do you have?” or “Do you know what a pointer (in C++) is?” these are red flags, and you should reconsider applying to such kind of companies.

The second phase of the process typically involves a coding interview, which can be conducted either online or in person (I’ve experienced both versions). The in-person variant of the coding interview, in my view, offers a more engaging and rewarding experience. This is primarily due to the immediate feedback provided by the interviewer. This real-time interaction not only allows for instant clarification of doubts and swift correction of errors, but also fosters a dynamic environment where problem-solving becomes a collaborative effort. This interpersonal element tends to make the process more enjoyable and enriching. For example, in one of the interviews, I was given one piece of paper at a time and 5 minutes to identify bugs and vulnerabilities within the Spring Boot Java application. At the end of the task the conversation eventually delved into a more profound discussion regarding achieving thread safety, enhancing performance, and devising elegant solutions to eliminate issues such as SQL injection and other vulnerabilities in the code. I’m sure that with the time I’m going to miss doing these kinds of technical interviews.

The third step is a more high-level interview with engineers or system architects (a.k.a the System Design Interview). There a technical person will ask you (again) about your background and your motivations for applying to the company. Then, you will have a round of technical questions. The questions will be somehow related to the position you are applying for. For example, if you are applying for a Machine Learning Engineer position, the questions will be related to creating a new model based on some particular data or improving an existing model. I had this kind of questions, and my previous experience doing ML research in Sport Analytics was very helpful. If you are applying for a Software Engineer position, the questions will be related to troubleshooting a particular system or designing a new system from scratch.

Each company has its own interview process, but the goals are the same: determining if you are smart and able to get the job done.

The fourth step is an interview with the hiring manager. This signals that you are close to getting an offer. The hiring manager could invite you to a coffee or lunch. She just wants to make sure that you are a good addition for the team (i.e., just double-checking that you’re not an asshole).

Offer

Once you get an offer, I recommend spending some time to think about it (e.g., one day). Accepting a new job is an important decision in life, and as with any important decision, there should be no rush. Take at least one day before accepting your dream job! In any case, you don’t want to show that you are desperate for the job. Give time to yourself and demonstrate that you are a valuable candidate who has other options.

Once you decide to accept the offer, you need to negotiate things like the salary and the notice date. Always negotiate the salary! Even if you are happy with the offer, you should negotiate it. After all, that’s one of the main drivers of your decision to leave academia $$$. Isn’t it?

I recommend reading the following articles from freeCodeCamp for additional insights on how to negotiate a job offer:

• Salary Negotiation: how not to set a bunch of money on fire
• Ten Rules for Negotiating a Job Offer
• How not to bomb your offer negotiation

Conclusion

I hope this article has provided you with some insights and inspiration to make your transition from academia to industry. I believe this is a natural and rewarding step for many PhD students. It is a path that offers a wealth of opportunities for growth, learning, and personal development. Be brave and take the leap.

If I could do it, so can you too!

Further Reading

• Why I chose OpenAI over academia: reflections on the CS academic and industry job markets

Footnotes