What to Ask When You're Applying to Grad School

MIT had EECS visit days last March, when I first wrote a draft of this.  It was another year of meeting enthusiastic young'uns eager to publish papers and win Turing Awards, which can make one feel even older and crankier.

Since it's application season again, I thought it was time to dig this up. In computer science, prospective graduate students go on a whirlwind set of visit days, where they tour departments, talk to potential advisors, and chat with grad students. It's a heady experience -- famous professors try to woo you to their school. It seems to me prospective PhD students never ask the right questions, and thus don't get good answers to help them make a decision.  Which is unfortunate, because they are making a decision about the next six years of their lives! Where you go can greatly affect your happiness. So if you're applying to graduate school in computer science, you might find this post useful.

Here are some things to think about before you actually start chatting with students and visiting prospective schools:

Think about your goals.  Are you interested in pure academia, or would you like to do some work in industry as well?  What kinds of things do you want to learn, and what skills do you want to acquire? What might you do afterwards?

Figure out your learning style.  Do you prefer a lot of contact, or would you rather be left alone? Do you learn best by taking classes, or by digging into a problem immediately? Different research groups have different personalities and research styles.

Think about what advising style works for you.  It's hard to get a feel for this, but different professors have very different advising strategies. Some like to engage with industry and work on open source software. Some like to publish a lot, while others prefer to work on fewer big pieces of work. One thing that varies the most is the amount of contact you'll have.  Another complication is that some professors actually change advising styles as they progress through their careers; think about students who might know best what the advisor's style is currently, and what it will be over the next few years.

Ask the same questions to many graduate students, and particularly graduate students with different properties.  Everyone is biased! Find out about different experiences. For example, you should talk to students who plan on staying in academia and ones who intend to go to industry.

Formulate specific questions.  There is a natural tendency to gloss over the hard bits of grad school, so try to be probing and ask about specific things students can't fudge. As an example, "When was the last time you did X?" instead of "Do you do X in your group?"

Once you've done a little thinking, you'll be in a much better position to ask good questions and interpret the answers.  Here are some concrete questions you can use depending on your goals.  Be diplomatic; but don't be afraid to do some investigating:

If you definitely want to stay in academia, ask:

• How many students has this professor graduated? How many stayed in academia?  

• How many dropped out before finishing? What did they do after they left?

• Does your advisor introduce you to people at conferences?  Who have you met?

• Has anyone transferred out of the group recently?  Where did they go, and why? (Also try to talk to them.)

If you work best when people leave you alone/you work best when someone checks up on you a lot, ask:

• How often do you meet with your advisor? How variable is this?  

• When was the last time you just walked into their office without an appointment? How often do you?

• How often are they actually in their office? What hours during the day?

• How quickly do they respond to your emails? Do they email you often?

• Which sections of your last paper did your advisor write, and which did you write? Did your advisor read the whole thing? Did they edit your text?

• Did your advisor write code for your project? How much?

If you are not sure what to work on, and would appreciate guidance in picking a research problem, ask:

• Did your advisor give you specific problems to work on your first year?

• Have you ever felt lost, like you didn't know what to work on? How did you overcome it?

• Can you walk me through a typical research meeting with your advisor?

• What's the longest someone has taken to finish a PhD in your group?  How often does that happen?

If it's important to you to be in a positive, social environment, ask:

• What do you think about this paper, X?  (You're looking to see if they trash it out of hand).

• Do you do practice talks? How many? What's it like to do a practice talk in front of your group?  

• When was the last time your group socialized together outside of lab? How often does it happen?

• When was the last time your advisor said something positive and affirming about your work? What was it?

• Do you acknowledge birthdays in your group, or frequently talk about vacations and things outside of research?

If you really want to work with other people, ask:

• How do students in your group manage their code?  Do you use version control?  

• Are there centralized resources available to the group (like documentation), or does everyone do their own thing?  

• When was the last time you shared code (latex templates included)?

• How many of the last few papers from the group had multiple students publishing together?

If you really want to work on your own stuff, ask:

• How long were you here before you published a first author paper?

• Do students work on (and own) different projects, or do they all collaborate on a few big projects?

• Does this professor work mostly on a few specific topics, or do his/her students work on lots of different things? 

If you want to have a reasonable work/life balance, ask:

• Which professor's students would you expect to see in the lab on a Saturday night?

• What is the process for taking vacation? How much did you take last year? (Not counting conferences!)

• How late do students usually stay in lab when there isn't a deadline?

• How often did you TA?

I didn't touch on issues like funding, because it seems to me this isn't a problem in most computer science programs. And of course there are a lot of caveats to all of this; take each student's opinion with a grain of salt. But try to notice patterns! Sometimes the most highly-ranked graduate program or most rockstar advisor isn't the one where you, specifically, will be most successful. Getting a PhD is pretty amazing when you are happy and productive in your environment. Best of luck!

Thanks to Ted Benson, Jon Gjengset, Elena Glassman, Adam Marcus, and Jean Yang for reading drafts of this.

Learning to Code

First off, I'm not one of those people who thinks EVERYONE MUST LEARN TO CODE.  That said, if you don't know anything about programming, it can help to learn a little so you don't feel like everyone is speaking a language you don't understand.

I wrote up a little page on how to start if you know absolutely nothing.  TL;DR: work through this book.

Unintended Consequences

Paul Graham recently decided to change the way comments work on Hacker News, a popular and influential link aggregator website used by programmers and other techies.  Getting to the "top of Hacker News" is a big accomplishment in tech circles; I even hear people in my lab talking about it.

The change means that by default, comments are not shown on the website, and instead multiple users with a high enough karma must endorse a comment before it becomes visible.  Users seem to receive karma by posting and commenting things that get upvoted (I don't know the details).

I believe the users of Hacker News are mostly male.  I hypothesize that users with karma greater than the endorsement threshold skews even more male; I wonder if the percentage of women in that group is even over 1%.  If my hypothesis is correct, an interesting consequence of this policy change is that a woman's comment cannot appear on Hacker News without a man endorsing the comment.

How does that sit with you?  

I haven't even stated any opinions yet; I just pointed out a result if my hypothesis is true.  You might think that statement is fine; I find it troubling because it means that it's possible some users' voices and opinions won't get heard on a site that is influential and important, perhaps because the majority finds them controversial.  It also just feels wrong.

Sometimes criteria that appear to be based on "merit" have troubling consequences.  We should encourage people and companies to think deeply about unintended, potentially troubling consequences of their actions.

Disclaimer: My PhD advisor also runs Hacker News.

Lowest Common Denominator

This post probably won't say anything that hasn't been said before, but I was thinking about Whatsapp and their success.  A lot of people I talk to here at MIT find the whole thing insane and really don't understand how on earth this could happen.

Most people understand international SMS (and even SMS within some countries) is expensive.  But I've heard so many people ask "Why not Gchat?  Why not Facebook Messenger?  Doesn't almost everyone already have one of those accounts anyway?"

When it comes to group communication, you have to look at the lowest common denominator.  If you have 5 friends who all want to communicate and one of them is on an old Nokia, it doesn't matter if the majority of you have iPhones -- you install Whatsapp because it has an iOS and J2ME client.  It's the only thing that will work across all the phones in your group.  Once you're using it for that, if it doesn't suck, you'll use it for everything else.

Even if 99% of the world were on Facebook, if anyone wanted to talk to that 1%, they would have to use something besides Facebook Messenger.  Or leave them out, of course.  One person I talked to said in the above situation he'd obviously just drop the Nokia user as a friend :).  But for most of us, that's not how small group communication works.

I think this effect, combined with a decent chat experience, is what made Whatsapp grow so fast.  Think about that next time you consider only doing an iOS or Android app.

Who Really Owns Your Phone?

I was working on some text about interoperability on the web, and found myself getting up in arms about how far we've strayed from the initial ideals of the internet.  The web was founded on principles of open, democratic access.  Any computer could put up a website; given an internet service provider, any user could connect to it.

There has been a trend towards closed platforms controlled by a single company, the most popular being Apple's App Store.  These walled gardens offer many benefits -- users can (usually) trust the applications they install, there's one place to go to look for apps, and developers have a centralized place to focus on promotion.  Overall app stores greatly simplify the mobile app experience.

But of course, they have their downsides.  Namely, they are sucking away our freedom and rights to run whatever code we want on our devices.  Developers are subject to arbitrary rejections -- Omar said that a friend's app was recently rejected for being too "avant garde", whatever that means -- which keeps them out of the primary distribution channel, and not available to users at all.

So, just avoid the app store, right?  Not so easy.  The debate over HTML5 websites vs. native apps on mobile is an excellent example of this. HTML5 offers platform independence, ease of updating code, and freedom from app store censorship. Native means the app will be faster, work offline, and have more access to phone hardware.  Which app is going to be more pleasant for the user?

What really frightens me, and makes me feel incredibly hypocritical for writing this on a MacBook Air, is the thought that Apple might make this the dominant model for desktop apps, too.  They are already sort of trying with the App Store on OSX.  I definitely don't want an Apple approval process coming between my laptop and what code I can run.  To be fair, it's a bit worrisome that Google is trying to move to a world where I don't have any access to my hardware except through a (Google-controlled) web browser.

Downloading, compiling, and running arbitrary code is not just for hackers.  The ability to do this is vital for encouraging competition and giving users choice.

Similarly on the web, there's a movement to closed sites that hold our data hostage.  And even though they might offer ways to download our data in a lump, they don't offer easy connections to share and move data between services.  The worst is when they arbitrarily decide to treat services differently and promote or debilitate one over another; see the Instagram/Twitter fiasco.  More and more user creation is moving behind these walls, making it inaccessible to third party applications.  This stifles innovation -- we have to wait for a single company to decide to build and push out features, instead of farming out this work to the wide world of developers, and seeing what sticks.

Unfortunately I don't have any answers, just questions:

What kind of technology can we build that encourages and promotes interoperability in this new world? 

How do we solve the issues of safety and curation if we don't use app store walled gardens?  

What kind of understanding do users have about their choices, and how do we encourage them to make ones that are in their best long term interests?