Skip to main content

Getting started as a PhD student

Since it's the beginning of the semester, I've been thinking a bit about the common advice that I give to incoming PhD students. Say you're a new PhD student in Computer Science. What are the main things you should know when getting started? Here are some of my favorite tidbits; feel free to chime in with your own in the comments.

(Turns out that Margo Seltzer blogged on the same topic this week too! Great minds think alike.)

This year I have two new students -- Amos Waterland and Youngjune Gwon -- I'm kinda bummed that I'm on sabbatical and can't interact with them as much as I'd like, but they will be busy with classes anyway :-)

Don't let school get in the way of your education. My advisor, David Culler, was fond of this misquote of Mark Twain, but it's true. Classes and program requirements are important but what is far more important is becoming an expert in your area. If that means taking fewer classes each term so you have time to do some real research, so be it. Harvard's PhD program is course-heavy and I often advise my students to ignore the requirements on paper and spread the classes out over several years, taking no more than two "real" classes at a time. Otherwise they would get nothing done for the first couple of years of the program.

Just dive in and have no fear. I often liken starting a research project (or career) to wandering into a dense jungle and blazing a path -- ideally a new path (but sometimes the jungle has overgrown since anyone wandered in your direction). There's only so much you can learn standing outside the jungle looking in, or reading about it, studying it, pondering it, whatever. I also feel that you can't really understand a problem until you've tried to solve it, even if your approach is somewhat naive. So rather than sit around reading a gazillion papers, just dive in and start doing some research -- anything -- even if you think it might be a dead end. Half the time you discover that something you thought would be easy or uninteresting actually leads to a bunch of open problems once you get beyond a superficial understanding of the area.

When I started on my thesis, I spent a lot of time reading and talking and thinking before writing any code, and at one point convinced myself that my project idea was stupid and not worth pursuing. (Whether this is true or not is still open for discussion.) Finally I sat down (during the sessions at OSDI 2000) and pounded out a simple prototype to test my ideas.

Don't read too much (at first). Obviously a huge part of grad school is reading and reviewing papers, but the problem with reading too many papers (especially at first) is that it can make it look like all of the interesting problems have already been solved. I've seen more than one grad student get into a rut because they read too many papers. Certainly you should never read anything from the 1960's or 70's or you will realize that it all has been done before -- by Real Programmers who had to code in assembly on a trinary architecture with sixteen levels of virtual address space segmentation and only two registers -- but I digress.

There is a real advantage to the Zen Mind approach of jumping in with your gut instincts about a problem and not worrying too much if you are treading familiar ground. At some point -- say 2 or 3 months into a project -- you should take a step back and compare your approach to what has come before, and correct course if necessary. Arguably all great systems projects are just reinventing ideas and reevaluating assumptions in light of changing technology trends, but don't let that stop you. I made my career that way, you can too!

Keep track of the papers that you do read. Come up with a good system for tracking the papers you have read, need to read, and take notes on them that you can easily reference later. Printing them out and scribbling in the margins is OK, though there may be more environmentally-friendly approaches. I am a big fan of the Mac application Papers, which is like iPhoto for PDF files. Mendeley, CiteULike, and Bibdesk offer similar functionality. In grad school I just kept a huge text file of every paper I read and my notes on it. When it came time to write my thesis, this was invaluable for putting together the related work list (same for papers that I wrote).

Finally, take a lot of notes. A couple of my students have the habit of coming to meet me empty-handed, which is a problem when I give them pointers to related work or ideas to chase down, which they really should be writing down. (Hell, I'm never going to remember what I told them from one week to the next, so they need to keep track.) I find it really helpful to maintain a group Wiki with meeting notes where I can go back and see what we were talking about week to week.


  1. In my experience students read too little of the literature rather than too much. Must be that Harvard has more erudite students than Hopkins.

  2. get a coach if you are not able to get organized

  3. Where do you even start when looking to locate a problem to research? (Especially in Comp Sci). Most of the problems I see are extremely out of my spectrum; or the problems are just too dull to spark my interests.

  4. @Jonathan Drouillard

    The a PhD is probably not for you! If there's not something keeping you up at night because you're pondering attack vectors to solve it, you shouldn't be contemplating a PhD. There's no particular method to find a problem to research, one tends to just stumble upon it in the course of reading/a masters/hacking/chatting/whatever.

  5. @Jonathan Drouillard

    One really interesting thing that I heard for looking into research problems is to ask someone (e.g. a professor) for 10 or so important papers in an area you are interested in (something in your "spectrum"). Start reading those 10 papers, looking for flaws in the approach or the solution, and potential problems that need to be addressed but are not covered. It could be big one or it could be a seemingly small problem; but some small problems can become a PhD dissertation if there isn't much research in the area.

    If you couldn't find any interesting problems by the time you finish reading all 10 of those papers in an area you like and have some background, maybe a PhD isn't your cup of tea.

  6. Jonathan - ignore what the commenter said about "then a PhD is probably not for you". The HARDEST PART of doing a PhD is deciding what problem to work on. It is never easy.

    This probably deserves its own blog post, but briefly, in my opinion the only way to decide what research you want to do is to do some research. You just have to jump in and work on something -- anything -- even if you're not sure it's the right area for you. New grad students shouldn't have a hard time with this since they will either have an advisor pushing them in some direction or course projects to pursue.

    The much harder time comes when you are 3-4 years into the program and need to embark on the dreaded THESIS PROJECT, which of course has to be something so utterly groundbreaking and critical to the future of humanity that the earth will shake when you get your dissertation signed... don't let all of those boring PhDs on minor tweaks to multi-hop routing protocols fool you!!!

    I am kidding, of course. Matt Might's got it right here:

    Deciding on a thesis project involves a lot of nuance. It has to be scoped right to do most of the work in about a year (writing it all up will take another 8-12 months). It's a lot like surfing: You need to pick a topic that will be sexy in 1-2 years when you are giving job talks on it, but not something that's so far out that you can't finish it in that length of time.

  7. A little more background:

    I'm still working on my Bachelors in bioinformatics. I have a ton of spare time right now. I wanted to begin side research on my own to see if it is the right avenue for me. The professors at Baylor haven't been very open to my questions about research. Flat out ignored by two. A PhD in Comp Sci is viable once I complete my BSI, but I haven't had the chance to research to make a judgement call.

  8. Matt gave me similar, but more direct advice when I started here at Berkeley a couple years ago: just build something. It's hard to find a research problem as all the commenters note, but it's slightly easier to make something useful. I'm pretty sure that's what Matt did in Grad School (nio, etc) and once you're down in the trenches it's a lot easier to see what the real problems are and where state of the art isn't good enough. This isn't to say you should necessarily go build something everyone knows how to do, but even that often yields unexpected benefits: you realize that there's a better way, or (at least) you learn a new skill.

    A side benefit of spending time on implementation is that you might become a much better hacker. Being excellent at implementation is probably one of the most valuable things I could recommend; just from observing successful grad students, the best ones are masters at taking ideas and making them real. By having deep knowledge of the tools in their area, they work faster and more efficiently. Also, I think this tip is often a little overlooked in the focus for research. You need both in an area like system which is so close to real-world engineering.

  9. Steve - you are right, that is a good way to get started. OTOH, it's important not to get sucked into doing *only* hacking projects. I've seen a few of my own students who are awesome hackers spend all of their time on infrastructure and not get very much "research" done. It's a fine line -- you gotta hack to learn how to do (at least systems) research, but the hacking by itself is not enough.

  10. I want to know if the subject of the thesis during PhD is important for future employments in R&D? For e.g. if I do PhD on computer networks, or say, on artificial intelligence or embedded systems will my job prospects be different? In others words, are there any budding areas in CS to do PhD? Let me put the question this way...........Will some company, say Google, hire any doctorate in CS for its R&D? Or, should he/she be specialized in one particular area in CS to bag the researcher job in Google?

    This may be a very stupid question. But then, it just occurred to me..........

  11. Chintan - sorry for not responding to this earlier.

    Certainly the area you specialize in is going to have some bearing on what kind of job you will have coming out of a PhD. If you decide to specialize in, say, some esoteric branch of number theory that only a few people in the world understand or care about, it's not likely to make you look very attractive to companies needing to hire good systems designers.

    That being said, unless your PhD is *really* obscure, to most companies (like Google and Microsoft) the exact topic of the thesis is not their main interest - they care to hire great researchers. If you want to go into academia after the PhD, it matters a lot more what topic you specialize in, since that will define what kinds of jobs are available to you.

    Of course, if you choose to do a PhD in an obscure theoretical area, you must like that kind of stuff, and wouldn't be happy being a "systems builder" anyway. And nobody can do a good PhD without being really passionate about their subject. So pick your PhD based on what you want to work on for the rest of your career - not what you think is going to land you a better job. Otherwise there's no point in getting a PhD - might as well go straight into industry.


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…