Saturday, January 28, 2012

A Good Problem to Have

Last year's enrollment for CS 124 was 53.  So far, current enrollment for this year:  119. 

I imagine a few are still just taking a look and might drop.  But a doubling is looking possible.

This would be the largest CS 124 class since I started teaching it in 1999. 

Thursday, January 26, 2012

Faculty Applications

An anonymous commenter asked how we evaluate faculty applications.  While it's a little late, it's a valid question, so here are some high-level thoughts.  Here I'm speaking only for myself, of course. 

First, I should point out that ideally, we're not reading your application from scratch -- we already know you.  We've seen you give a talk we like, or enjoyed one of your papers, or otherwise formed a (positive) impression.  The most important things you can do when applying come well before you write up your application.  If you're not taking advantage of opportunities to make yourself known in the community as a graduate student, you're not doing your job.  [Obviously, we don't only look at applications of people we already know.  But that just makes our job harder, and makes it harder for you to get picked out of the crowd.]

After that, it's not exactly rocket science.  I'm looking for a strong record, and the first things I'm looking for are good publications and good letters.  Applicants on the first pass are usually sorted into 3 basic categories:  invite for an interview, decline, or study further.  The publications and letters are the best guide for what pile you'll go into.

Once the pack is cut down, more details will come into play.  Some of us will probably read your papers to get a better idea your work.  Natural more detailed questions come up:  How interesting is your work?  How well do you fit our department needs?  What teaching experience do you have?  Is Harvard a place where we think you would be successful?  (For example, what other areas of Harvard might serve as possible points of collaboration?)

The interview helps us answer these questions further.  At the end of the day, what we're deciding is if we want you as a member of our department.  Research quality is a primary issue, and usually the primary issue.  But at this point, hopefully all of the people we're looking at have high-quality research records, with results that we collectively find compelling.  So the secondary issues I mentioned -- are you a good fit for us, are we a good fit for you? -- do matter.      

In the end, I don't think there's too much you can do to "strategize" your application -- because the main issues are to have a good work record, get people who can write you good letters, and be an interesting person who seems like they'd make a good colleague.  I expect that's not surprising anyone.  Though I'm sure since I wrote this a bit hurriedly, someone will point out where I've not described things suitably carefully or in enough detail. 

Wednesday, January 25, 2012

Collective Coordination of Conferences?

Around this time of year, I get a number of messages from students:  I want to take your class, but there's a conflict with this other class I want to take, what can be done...  Sometimes a solution can be worked out, sometimes not.  It's not an easy issue to deal with.  In Computer Science, we take a look at our own schedule of classes, and try to make sure there aren't any particularly bad time conflicts among our own classes, although inevitably there are some hopefully minor ones.  Then we try to look at other big classes in related areas -- try not to have our intro classes the same time as the intro economics, physics, statistics courses, etc.  Of course we also try to let them know when our big intro courses are, so they don't reschedule classes into those time slots as well.  In the end I think we do a reasonably good job.

That was a long-winded roundabout to where I wanted to get to, which is conference scheduling.  It's something that I think is becoming increasingly broken -- at least for theory conferences* -- due to the fact that there is (as far as I know) minimal coordination going on with respect to the calendar, and there's an ever-increasing number of conferences and workshops.  The near-overlap of ITCS and SODA is one obvious example.  The nearly-overlapping SPAA and PODC deadlines are another.**  I'm sure one can come up with hosts of others, and that's excluding the issue of trying to coordinate with other adjacent fields.  (For many years, INFOCOM and SODA deadlines, as I recall, were within a couple of days of each other -- and July 4th!  Not friendly, especially not family friendly.) 

I'm not claiming we want full centralization of conference scheduling.  But I do think there should be a lot more of it than we have.  A lot of aspects of the conference calendar -- dates, how many conferences we have, where they're located -- don't make a lot of sense to me, and I think that's because they don't make a lot sense.  I don't know how we arrange for a body to try to look at where we're at and figure out how to make it globally better.  But I wish someone would!   

* I haven't noticed this so much for other areas -- in networking, SIGCOMM, INFOCOM, NSDI, IMC, and even Allerton have always seemed reasonably spread out to me, but perhaps I just haven't noticed the problem.

** I've thought SPAA and PODC should have some sort of "merge" for almost 20 years now.  You're different communities?  Fine.  Then arrange a permanent co-location agreement.  It would be better for both conferences.