Book by FemaleScienceProfessor

I'm an occasional reader of the blog FemaleScienceProfessor. Often the blog is just about being a science professor, which is interesting, and I can relate to. And sometimes the blog is specifically about being a female science professor, which is also interesting, even if I relate to it less.

Well, FSP has re-worked past blog entries into an on-line book available at lulu.com. I haven't yet bought and downloaded it yet, but from the Table of Contents, it appears to be a particularly worthwhile book for graduate students thinking about a life in academia, and for new faculty. The bulk of the book seems gender-neutral, if that's a concern. I thought I'd give it a free plug.

The Job Market, Post Analysis

When I was in graduate school, the academic/research lab job market was pretty soft. By the time I graduated, it was a little better, but not great; you could see things heading upward, though. (Of course, I should point out here the caveat that generally the job market always seems a bit softer in theory than in anything else...)

So, looking back this last year, what is everyone's take on the job market this past year (and the trend for next year)? It seemed to me that while it's not in a completely disastrous state, it's not great, and it's been trending downward the last year or two. The effects of the economy and the long-term exodus of CS majors is not helping in academia, and while there's some availability in research labs, there doesn't seem to be a lot of spare capacity. Google is providing a much-needed outlet, as are (to a lesser extent) Yahoo Research and the new Microsoft Cambridge lab, but it's not clear (to me) how all three will play out long term, or even in the next few years. (If it weren't for sponsored search, I hesitate to think where the theory job market would be today. And if Yahoo ever does get bought out, what will happen to research...?)

There still seem to be jobs available for the best people (or, depending on your point of view, the people with the best buzz), and we still don't seem as saturated as I always hear physics and math are. But the market seems weak, and it's something students should be aware of.

I'd be happy to hear more informed opinions, or disagreeing opinions, or especially insights on the job market from non-theory people...

ISIT this week

While many theory CS people will be spending the week at ICALP (and
adjacent workshops and such), the information theory people will be
spending the week at ISIT. No wonder these communities don't get
together as much as they should -- conferences are cross-scheduled!
CS theory will be well represented at ISIT, however, as Avi Wigderson
is one of the plenary speakers.

ISIT is bigger than, well, any theory CS conference I know, because it
is the major IT conference each year. CS theory has nothing
like it, with more, smaller conferences throughout the year, and (it
seems to me) many more specialized conferences and workshops. So here are some things I think worth observing for theory CS people, just to think about how we do things, and if we'd want to change:

1) ISIT goes for a week. One day of tutorials, 5 days of talks, with
4 parallel sessions, and a plenary each day. So naturally, most everyone
comes. (Um, no, I'm not going this year. That new baby thing...)

2) There's specific time for the Board of Governors of the IEEE
Information Society to meet and do their business. A benefit of a
conference where most everyone comes is that having "business meetings" like this seems easy to set up. Similarly, there's a large Awards Luncheon, and most people are there to pick up their awards, and see/hear the award-winners.

3) There are several activities especially for students. Roundtable
discussions, a panel led by the student committee, and a panel on
balancing career and personal life (see here and here for recent related posts on Sorelle's blog on that theme). Generally these are done over lunch, and lunch is provided for the students. (Never underestimate how well students respond to free food.)

4) Part of the tradeoff in establishing a large conference is that a higher
percentage of papers are accepted. And there's an understanding that individuals are not supposed to submit large numbers of papers, as large-scale participation is one of the goals. (This used to be explicit in the call -- something about multiple papers from an author being subject to more scrutiny -- but I don't see it in this year's call.)

As a relative outsider, I enjoy the ISIT setup. There's one
conference I know I can send my IT papers too; when I go, there's a
chance to see everyone, though there is sometimes the challenge of
tracking them down and scheduling a meet. There's a clear and strong
sense of community at the conference, despite the size.

I'm not trying to say that CS theory doesn't have a community-feeling.
But it does feel like the CS communities tend to partition themselves
more into loosely overlapping subcommunities. There's no universal
conference, although perhaps SODA (moreso than FOCS/STOC, based on sheer size) comes closest. I wonder, sometimes, what we as a community lose from this.

Security, and Class Projects

As I was reading Freedom to Tinker, catching up on the latest reports of flawed voting machines, I remembered my favorite class project of all time.

My first year teaching Algorithms at the End of the Wire, I included a subunit on cryptography/security. (This was before Salil Vadhan arrived, and before Michael Rabin started regularly teaching a crypto course.) One group, for their final class project, decided to explore the potential security flaws in the Crimson Cash system, the local system where students put money on their ID. They got a card reader and figured out how to intercept and spoof messages from the vending machines in the Maxwell-Dworkin lobby. It was a standard man-in-the-middle attack -- you intercept the message from the vending machine so your account doesn't get debited, and tell the vending machine the message went through. For their demo, they showed how they could get a free soda. They got to learn about security by breaking an actual system (which, by the way, in retrospect was something of a bad idea -- next time students try to break system security, I'll make sure they do it in a closed, lab-type setting).

It was great stuff. All CS majors should do some sort of a-little-bit-out-there, hands-on project like that. And then, maybe, we'd have better voting machines.

Hunting for Problems

An anonymous commenter asked:

What advice do you give to graduate students hunting for problems?

I'd advise the following, though your working style may differ:

1. Read a lot. Nobody else wants their paper proceedings anymore, so keep those hefty tomes lying around and start reading from 2008 backwards whenever you can. I found problems (including my thesis topic) in graduate school just by reading proceedings and thinking hard when I thought I saw how to do something better. At worst, reading through proceedings introduces you to techniques, ideas, and problems, so it won't be a waste. Two notes about this approach: you'll probably have to read at least 40-50 papers before you find even one with a problem that appeals to you and that you have an idea on, and the problems you tend to find this way are generally incremental -- after all, they're based on somebody else's paper! For a beginning graduate student (with lots of time, and where publishing something incremental is just fine), those negatives aren't too bad.
2. Go to talks. For the same reason you should read a lot -- for exposure to problems and ideas.
3. Talk to people. Don't just talk to your advisor. Find other people with interesting problems and research, and see if you can help them, or if by talking to them you get a new idea for a research direction. I certainly don't come up with all of my own problems. Sharing ideas with others is key. In fact, I strongly recommend you talk with your other graduate students as much as possible, and try to start a paper-reading group/research group with them. Other students have more time than your advisor, so leverage that and work together to solve a problem. (Thank goodness we work in a field where cooperation is considered a virtue and collaboration is the norm.) At worst, it will make your work/social life at graduate school much better and less isolated.
4. Don't limit yourself to reading papers by/going to talks by/talking to theorists. If you're looking to come up with a new problem, odds are the motivation for that problem will come from outside the theory community itself. Find out what kinds of problems the systems people are having, and see if you can turn it into a theory problem. Even if your theory version is too toy to solve the real-world problem, you'll have a reasonable motivation for your introduction. And if your theory problem actually helps solve their real-world systems problem, bonus -- you now have contacts/letter-writers from outside theory that can help you in the future. And again, it will make your work/social life at graduate school better and less isolated if you talk to other people in the department besides theorists.
   

That's the top-of-my-head advice.

Meetings with Graduate Students

I think one of the signs a graduate student is on his or her way to graduating is when they start taking control of our meetings. With younger graduate students, I've found I have to set the agenda -- asking questions, pulling out information from them, and telling them things they need to do. Some time ago, I noticed that Adam was coming into our meetings with a written agenda. He asks me questions, gets information from me, and tells me what I need to do. And then, on a good day, we can collaborate on research.

I'm not saying that graduate students can walk in, day one, and take control like that. Indeed, most probably can't and shouldn't. But as a graduate student, the sooner you can take charge of your education and set your own agenda -- so your advisor is a resource, rather than your manager -- the better off you'll probably be.

Women in Theory of Computer Science Meeting

Although it's been well-covered in other blogs, I would be remiss not to mention the workshop for women in theory of computer science being organized at Princeton.

I'm always torn when I hear about such things. I think it's a very good and important idea, but at the same time, I look forward to the day when such workshops won't be necessary (and wonder why we're not there yet).

I do think that peer support is key to getting women into computer science, and having them stay. Some years ago at Harvard we were fortunate to have a group of four very mathematically talented undergraduate women, all of whom apparently had at least met each other in high school, come through the computer science ranks. It was clear that the "group dynamic" of being able to work together and talk with each other was very helpful to them. Three of the four went to graduate school in computer science; two are/have finished (in theory), one switched over to economics. While I have seen many strong women undergraduates come through Harvard, I haven't seen a group quite like this one, and I wish I saw more.

Of course, it also helps to have successful role models, so I suppose now is an apropos time to belatedly congratulate Susanne Albers for winning the Leibniz Prize. I had the great fortune to start working with Susanne while I was a graduate student at Berkeley and she was a postdoc at ICSI. It was a great experience for me, as at the time, I was still figuring out how this whole research thing worked; I learned a lot working with her. I'm thrilled she's getting this outstanding prize and the corresponding recognition for her body of work.

Preparing Students for Jobs

In a recent "discussion" on another blog, I repeatedly heard the refrain that we ivory-tower pie-in-the-sky university computer science professor types just aren't preparing students suitably for "real-world" employment. Personally, I think that's just BS. However, I realize I may have a fairly biased viewpoint. I teach at Harvard, and, if I may say so, our students are generally quite good and do well in the job market. Having spent some time in industry, and, if I may so so, being perhaps more interested than the average theorist about practical issues, I attempt to add "real-world" aspects to my classes, like programming assignments in my undergraduate theory course.

Now occasionally I catch students who admit to reading this blog. I mean all students, from whatever school, undergraduates and graduate students, not just students from my classes or Harvard students. I hope some of you are reading now. Because I'd like to ask you to enlighten me. (That means, for instance, I'll keep quiet on the comments.) Please tell me, in your experience, did your education prepare you for your life after in the real world. (For current students, you can comment on how you feel your education is preparing you.)

While I'd expect you to comment anonymously, I'd ask that you provide salient information where possible. (Harvard student or not, current undergraduate or long-time real-world person, CS or EE or other major, etc.) I'd also greatly enjoy hearing specific comments and criticism regarding my own classes, from any ex-students out there.

And in advance of some annoying anonymous commenter who might feel the need to say how out of touch I must be that I need to find out how students are doing by asking on my blog, please rest assured I have other sources of information (both personal and data-driven) on the subject, but this is, hopefully, an interesting opportunity for me and others to gain more insight.

Graduate Students, Socialize!

The discussion that in my mind connected breadth requirements to social networks reminded me of my time as a graduate student at Berkeley, where there were lots of informal social opportunities for graduate students to meet and talk. The CS grad student association had a weekly bagel/donut hour that was always well attended (mmmm...donuts....); the theory students arranged a Friday afternoon seminar (I believe called TGIF) where theory students would present something (a practice talk, some ongoing research, a paper they liked), no faculty allowed; there was a regular Friday pre-weekend grad student get-together that would be at a semi-randomly chosen local bar (usually upwards of a dozen or so people would show, with a high percentage of theorists, who didn't have to spend the weekend coding or running jobs); a grad student poker game broke out once a month or so (again, with a high percentage of theorists, who'd add complexity to the games).

Besides helping create a more pleasant graduate student atmosphere and experience, these activities let graduate students get to know more about each other and what they were doing. And I believe expanding your own work-related social network pays dividends in the long run.

I don't know what the current state of graduate student life is like these days, but if you don't think there's enough of this sort of stuff where you are, I encourage you, take action! (Don't wait for the department to do it; you'll do it better anyhow.) Try to get a grad student poker game going. Or a biweekly pub night. Or start an informal seminar. Or an open problems session. Or whatever it is you want to do, where graduate students can just hang out together, without faculty, with it being about fun, instead of or combined with work. Besides having more fun, you'll open up more opportunities for the serendipitous events in your work-life that lead to exciting projects.

Breadth Requirements

In our department we're looking at the class requirements for Ph.D. students, and in particular breadth requirements.

I'll state clearly that my opinion is that breadth requirements are a good thing. Breadth requirements for Ph.D. students are like vegetables for kids -- they don't always like them, but they're good for them. When I was at Berkeley the breadth requirements were reasonably onerous and I think they were very positive for me (even if, as contemporaries will suggest, it seemed like I slept through most of them). I especially think it's good for theoretical people to have a background in many areas of computer science outside theory, and classes are arguably the best way to get that background. And certainly I would argue that people in systems need some theory in their background.

I'd enjoy hearing arguments from the other side. You can argue that breadth requirements in general are a bad idea, or specifically that theory people shouldn't have to take classes in other CS areas (they should be allowed to just do all theory!), or that systems people shouldn't have to take a theory class. Any EE readers or readers from other areas should chime in with arguments based on their experiences as well!

Academic jobs this season?

I’ve already mentioned Harvard is doing a junior faculty search – although not specifically for a theorist. Any other faculty hiring announcements, either broad-based or theory specific? Or any new postdoc announcements worth repeating here?

The Importance of Recommendation Letters

If there is one piece of career-gamesmanship advice I would give to anyone, especially undergraduates eventually looking to get into graduate school or beginning PhDs who will be eventually looking for jobs, it would be to think carefully well in advance about where you plan to get letters of recommendation from.

For graduate school, your letters are probably the most important deciding factor for whether you'll get accepted or not. For job searches, good letters won't really get you the job, but you'll need great letters to even get your foot in the door for an interview.

Yes, great work will trump everything (if you do really great work, you'll get the great letters). But I've seen numerous students do less well than they should have because they didn't think well enough in advance about this part of the game.

For undergraduates thinking about graduate school, have you formed a close working relationship with one or more faculty members? (This can be done by doing research with them, writing a thesis with them as an advisor, being a teaching assistant for them, etc.) Lots of students will have exceptional grades and test scores; we want to know about you as an individual, and your capacity for research. Letters are the best way for us to get this information. Particularly if you go to a smaller school or a school with a smaller CS department, you may want to try to find a way to do a summer internship with a "bigger name" person -- a letter from such a person will likely make the difference between getting in and not for many places.

For graduate students thinking about jobs, who besides your advisor is going to write you a letter? We expect your advisor to say that you're wonderful; we want to hear from less biased sources. (Many students fall into the trap of working almost exclusively with their advisor -- good in the short-term, not in the long-term.) What other faculty have you worked at your institution? Have you worked with anyone from another institution? Have you thought about doing a summer internship -- which can be worthwhile just to get a good letter! It's important to work with multiple people, not just your advisor, so we can see multiple letters explaining and confirming why you and your work are so outstanding.

I thought about this after a discussion on the complexity blog about graduate school detoured slightly into the subject of letters for jobs (in particular, check Paul Beame's insightful comment #41).

By the time you get to tenure, letters are still important, but ostensibly you have less control about where the letters come from. The same general advice seems to apply, though -- great work trumps all, but working with or having some shared experience with many colleagues, including more senior ones, can be key to career advancement.

How Much Does a Graduate Student Cost When Teaching?

Continuing my last question, what other support for graduate students (on the Ph.D. track) do you have? The main two I can think of are the following:

1. Does the department provide funding for incoming graduate students for some period? For example, do all first years get funded by the department automatically? Are there requirements for this funding (such as they have to teach one semester)?
   
2. What department support to students get if they take on a Teaching Assistant role during the semester? Does it cover tuition/stipend for the semester? If not, what fraction?
   

And there's still time to answer the previous question -- what's the annual cost of a graduate student (tuition+stipend+overhead).

How Much Does a Graduate Student Cost?

What's a graduate student cost these days? That is, as a line item on an NSF grant, for a 12-month graduate student, tuition+stipend+overhead, what's a graduate student cost? (Please feel free to answer anonymously, as I'm sure this is the sort of information people are interested in but don't want to reveal by institution. And use whatever additional qualifiers are necessary. For consistency, let's say a 3rd year student.)

This question was motivated by a change made this last week in Harvard's policy regarding how graduate students were charged to grants. Previously, Harvard would pay the student the stipend and tuition money directly, and then pull tuition back out of the paycheck. With this setup, Harvard charged overhead on tuition, since it was treated the same as the student stipend. Apparently, a new federal guideline just came out prohibiting this sort of thing; tuition will now be pulled out of the grant directly, free of overhead.

I was quite pleased to hear this. I had been complaining about this practice for a number of years; as far as I know, overhead on tuition is not standard for most schools. It made Harvard graduate students non-trivially more expensive. This change makes graduate students funded by NSF grants much cheaper for me. Moreover, it also just seems to me to be the right way to do it.

Now that the change is happening, though, I'm somewhat concerned. All of a sudden the School of Engineering and Applied Sciences is probably out millions in overhead that it had already budgeted. Somewhere down the line, I'm sure I'll be paying for that out of my grants somehow.

Research labs vs. academia

A discussion over at Muthu's blog led to the following great question:

You have a talented graduate who has a faculty job offer and a research lab job offer. Modulo the specifics of the univ and the lab, where should they go?

I think it's a great question, in part because it points out fantastic biases in the system. Of course almost all professors will almost always favor the university position; after all, they chose academia, so there's an inherent bias toward that direction. In my experience, students also are biased toward academia. Almost all students who work for a Ph.D. go in from the beginning with the mindset that they're going to be a professor, and that can be hard to let go of.

But very few people in computer science (both in general, and theory in particular) go on to become professors. There just aren't that many professor jobs. Perhaps one of the first conversations advisors ought to have with students would start, "I'm sure you want to be a professor when you're done here. But just so we're clear, what would be your backup plan?"

Of course, research labs shouldn't be just a backup plan. They're different from academic positions in ways that can be very appealing to many people : no need to continually find funding, no teaching, no tenure pressure, and generally more emphasis on accomplishing things as a group rather than individually. There's no single right answer to the question of whether to go to the lab or the university; it should depend on the personality, life goals, and needs of the student.

And a final thought -- life goals can change, and one can change one's mind later. Many people switch from labs to academia or academia to labs. Some people -- as Muthu himself knows -- can make multiple such switches throughout their career.