An undergrad in my lab recently asked me why I chose to do a PhD instead of going into industry.
I often get questions of this nature.
I’ve even served on three “why’d you go into research?” panels in the past year.
Inspired by these recurring questions, I’ve decided to finally consolidate my thoughts on the topic into one post,
which I’ll continue to update as I discuss with others.
An overview is as follows:
- I review the somewhat accidental path that led me to a PhD.
- I share advice I’ve given to undergraduates in the past about pursuing CS research and/or a PhD.
Disclaimer: My advice is by no means comprehensive or definitive.
I welcome questions about, and disagreement with, my opinions.
Also, note that when I say “industry”, I’m mostly referring to software engineering jobs.
Of course there’s more you can do in industry with a CS degree, but software engineering is one of the most common immediate outcomes, if not the most common.
Regarding careers after a PhD, it is perfectly possible to go into industry—actually most CS PhDs do—including roles in software engineering, management, and industry research labs (a PhD is usually required for the latter).
However, I won’t discuss the topic of post-PhD careers here.
Maybe I’ll write about it on my blog when it becomes more personally relevant.
For now, you can read our related paper for an academic perspective if you’re interested.
I joined my current research lab in the second semester of my junior year.
During that semester I was not as busy as usual and really just wanted something to do.
Maybe this isn’t a good thing to say, but I wasn’t actually that interested in the research my group was doing.
In fact, all ongoing CS research at Michigan seemed about the same level of (un)interesting to me.
During the first weeks of my “research” experience, I did and understood very little.
Fortunately, my adviser Danai soon included me in a project by having me use my existing operating systems knowledge.
I felt useful, which was nice, and as I got involved, I actually began to see the beauty and difficulty of the problems we were addressing.
I got excited.
One night I stayed up drawing furiously on a whiteboard.
I emerged the next morning with an idea, which in the next month became (semi-)coherent through discussion and experimentation.
Eventually my work became part of a research paper.
For the first time in college, I felt complete ownership over my ideas and writing.
I was hooked!
After all of the above, I did a software engineering internship at Microsoft and came back unsure of my future.
Microsoft’s work-life balance, pay, and location were ideal.
On the other hand, I knew that research fit my personality and preferences better for these reasons:
- Freedom. My favorite part about research has always been the freedom to pursue problems I consider worthwhile.
It’s not that I think all software engineering problems in industry are boring, but these projects are motivated by business needs, no matter what individuals say to the contrary. I don’t always like thinking in the “monetization” box, and I don’t have to as a researcher.
As long as I can convince people that the problems I’m solving are important, I can research whatever I want.
- A good adviser is hard to find. Fortunately or unfortunately, the quality of a research experience is highly dependent on the people around you. The most important of these people is your adviser. Luckily – totally by accident – I landed a good adviser who took me seriously even when I was an inexperienced undergrad. Rather than her telling me what to do, we traded ideas and hypotheses. We still do.
- The “now or never” argument. A mentor told me that if I eventually wanted a PhD, which I did, I might as well get it now. If you go into industry, he said, you’ll find it hard to come back. Existing data support his claim: we found in our own paper on CS research careers that people rarely leave industry for academia. I assume this is due in part to the difficulty of giving up an industry salary once you get used to it.
Long story short, after talking to a lot of other people—PhD graduates, those who decided against or quit a PhD, those who recently started a PhD, and those who were currently applying to PhD programs—I decided to stay in school.
I don’t think I’ve ever made a big decision I was completely sure about, and this was no exception.
I still occasionally wish I’d made a different choice, especially during moments of self-doubt or isolation, or even when I’m just missing the view of Mount Rainier.
That said, I’ve never doubted the necessity of a PhD for my long-term goal of being able to do (fairly) autonomous research.
This, as I explain below, makes it worth it.
Note: In this section I don’t discuss how to put together a strong graduate school application. I’ll probably write about this separately some other time.
Here’s the advice I usually give about getting involved in CS research:
- Shop around. Unless you have one interest and are absolutely sure about it, email and/or meet with several professors. A professor’s enthusiasm, or lack thereof, can change your mind about what’s interesting and what’s not. Also talk to grad students in the labs that interest you. They’re probably going to be more honest about the ups and downs of research, and can tell you what it’s like to work with a specific professor. Ideally, they should have good things to say about how the professor treats, mentors, and respects students of all backgrounds.
- Consider your ideal boss. Advising styles vary a lot from professor to professor. Beyond personality, the difference between professors is often tied to their faculty position. Assistant professors (pre-tenure) are usually more hands-on, which can be good if you struggle with self-direction or want others to push you, give you deadlines, etc. Tenured professors, who are more often hands-off, have more experience graduating students, playing the academic game, etc. It’s absolutely critical that you find an adviser who you can work with and trust. Many people say that whether you like your adviser is more important than whether you like your research topic. I agree.
- Avoid romanticizing research… I see a lot of undergraduates quit research because they become disillusioned with its scope or pace. Yes, sometimes your work will consist of hyperparameter tuning, making figures, or sifting through piles of esoteric literature.
- …but keep an open mind. Still, research might be cooler than you expect, which was my case. It’s all about managing expectations.
- Expect open-ended everything. Most people don’t understand this about research until they try it. Remember that the point is to push the boundaries of human knowledge. Solutions to many of the questions you’re asking probably don’t exist yet.
- Be clear about your goals. Make sure the professor knows what you’re trying to get out of your experience (go to grad school, just try something new) and what kind of work you like (implementation, theory, etc).
- Stop apologizing! I see this all the time. I was guilty of it too. You shouldn’t feel bad if you don’t immediately know or understand everything. Don’t be afraid to ask questions or say you don’t have a background in topic X. Also try not to be intimidated by a professor’s background or how many Nature articles they’ve published (I understand this is easier said than done). This is a good rule of thumb because, for better or worse, research is full of brilliant people. Plus, while CS culture loves to worship the successful “genius” types—I hear myths about the same few famous dudes all the time—a lot of these “success” skills are actually trainable, like persuasive public speaking, networking, and the abilities to follow through or pivot on a project. For more on this topic, read this blog post on the “genius fallacy” by CS professor Jean Yang.
Here are my final observations – general guidelines, because of course there are exceptions to every rule – about the tradeoffs of getting a CS PhD versus going directly into industry:
- Structure versus open-endedness: As I’ve said, research is open-ended. This Humans of New York post is an accurate summary. While this open-endedness is often liberating, it can also be intellectually and socially isolating. Unlike most office environments, PhD programs rarely have enforced structure. It is (unfortunately) easy to skip lectures, work remotely, etc. This is awesome when you don’t feel like putting pants on or leaving the house in the morning, and not awesome when you start to become depressed from a lack of social interaction.
- Practical versus proof-of-concept: In industry you’ll spend more time writing good code and deploying at-scale systems. As a PhD student you’ll be reading papers, investigating small but specialized problems, and communicating experimental solutions to these problems.
- Academic versus real-world learning: You’ll be expected to take some classes as a PhD student. Some see this as a unique opportunity to learn from world-class faculty. Others hate homework and exams. If you don’t want to take more classes, keep this in mind, especially because classes will get in the way of research during your first few years of the PhD.
As far as the quality of classes, some will be excellent or even life-changing, and others will be unreasonably hard and/or a huge waste of time.
- High versus low pay: This is a question of practicality. Do you need money to pay off student loans or support your family or continue your current lifestyle? Frankly, I consider the ability to do a PhD a luxury. Although you can consider a CS PhD an investment that will (hopefully) pay off after graduation, don’t get a PhD if you need or want money now, especially when the demand for software engineers is so high.
- Do you want to do research or teach at the college level? I put this last, but this is actually the first thing I ask people.
If you want to be a software engineer or a product manager or a stay-at-home parent, a PhD isn’t worth the opportunity cost.
If your long-term goals involve doing research, college-level teaching, or both, get a PhD.