The ethics of mobile data collection

The mobile computing and networking research communities need to start paying closer attention to the data collection practices of researchers in our field. Now that it's easy to write mobile apps that collect data from real users, I'm going to argue that computer science publication venues should start requiring authors to document whether they have IRB approval for studies involving human subjects, and how the study participants were consented. This documentation requirement is standard in the medical and social science communities, and it makes sense for computer science conferences and journals to do the same. Otherwise I fear we run the risk of accepting papers that have collected data unethically, hence rewarding researchers for not adequately protecting the privacy of the study participants.

I am often asked to review papers in which the authors have deployed a mobile phone app that collects data about the app's users. In some cases, these apps are overtly used for data collection and the users of the app are told how this data will be collected and used. But I have read a number of papers in which data collection has been embedded into apps that have some other purpose -- such as games or photo sharing. The goal, of course, is to get a lot of people to install the app, which is great for getting lots of "real world" data for a research paper. In some cases, I have downloaded the app in question and installed it, only to discover that the app never informs the user that it is collecting sensitive data in the background.

The problem is, such practices are unethical (and possibly illegal) according to federal requirements for protecting the privacy for human subjects in a research study. Even if there is some fine print in the app the use of data for a research study, it's not clear to me that in all cases the researchers have actually gone through the federally-mandated Institutional Review Board approval process to collect this data.

Unfortunately, not many computer scientists seem to be familiar with the IRB approval requirement for studies involving human subjects. Our field is pretty lax about this, but I think it's time we started taking human subjects approval more seriously.

It is now dead simple to develop mobile apps that collect all kinds of data about their users. On the Android platform, an app can collect data such as the device's GPS location; which other apps are running and how much network traffic they use; what type of wireless network the device is using; the device manufacturer, model, and OS version; which cellular carrier the device uses; the device's battery level; and the current cell tower ID. Similar provisions exist on iOS and other mobile operating systems. With rooted devices, it's possible to collect even more information, such as a complete network packet trace and complete information on which websites and apps have been used.

Put together, this data can yield a rich picture of the usage patterns, mobility, and network performance experienced by a mobile user. It is very tempting for researchers to exploit this capability, and it's easy to get thousands of people to install your app by releasing it on Google Play or the Apple App Store. However, I have very little confidence that most researchers are adhering to legal and ethical guidelines for collecting such data -- I bet the typical scenario is that the data ends up being logged to an unsecured computer under some grad student's desk.

So, what is an IRB? In the US and many other countries, any institution that receives federal funding must ensure that research studies involving human subjects protect the rights and privacy of the participants in such studies. This is accomplished through Institutional Review Board review which much occur prior to the study taking place. The purpose of the IRB is to ensure that the study meets certain guidelines for protecting the privacy of the study participants. The Stanford IRB Website has some good background about the purpose of IRB approval and what the process is like. The principles underpinning IRB review were set forth in the Declaration of Helsinki, which has been the basis for many countries' laws regarding protection of human subjects.

Failing to get IRB approval for a research study is serious business. In the medical and social science communities, failing to get IRB approval is tantamount to faking data or plagiarism. The Retraction Watch blog has a long list of cases in which published articles have been retracted due to lack of IRB approval. In those fields, this kind of forced retraction can destroy an academic's career.

Documenting IRB approval and informed consent for study participants is becoming standard practice in the medical and social science communities. For example, the submission guidelines to the Annals of Internal Medicine require an explicit statement from authors regarding IRB approval:

"The authors must confirm review of the study by the appropriate institutional review board or affirm that the protocol is consistent with the principles of the Declaration of Helsinki (see World Medical Association). If the authors did not obtain institutional review board approval before the start of the study, they should so state and explain the circumstances. If the study was exempt from review, the authors must state that such exemption complied with the policy of their local institutional review board. They should affirm that study participants gave their informed consent or state than an institutional review board approved conduct of the research without explicit consent from the participants. If patients are identifiable from illustrations, photographs, pedigrees, case reports, or other study data, the authors must submit the release form for each such individual (or copies of the figures with the appropriate release statement) giving permission for publication with the manuscript. Consult the Research section of the American College of Physicians Ethics Manual for further information."

But yet, in computer science, we tend not to take this process very seriously. I suspect most computer scientists have never heard of, or dealt with, their institution's IRB. I was surprised to see that CHI, the top conference in the area of human-computer interaction (in which user studies are commonplace), says nothing in its call for papers about requiring IRB approval disclosure for human subjects studies -- perhaps the practice of obtaining IRB approval is already widespread in that community, though I doubt it.

Why do I think we should require authors to document IRB approval? For two reasons. First, to raise awareness of this issue and ensure that authors are aware of their obligations before they submit a paper to such venues. Second, to prevent paper reviewers from having to make a judgment call when a paper is unclear on whether and how a study protects its participants. The whole point of an IRB is to front-load the approval process before the research study even begins, well before a paper gets submitted. The nature of a research project may well change depending on the IRB's requirements for protecting user privacy.

To give an example of how this can be done properly, colleagues of mine at University of Michigan and University of Washington are developing a mobile app for collecting network performance data, called MobiPerf. The PIs have IRB approval for this study and the app clearly informs the users that the data will be collected for a research study when the app first starts; clicking "No thanks" immediately exits the app. Furthermore, there is a fairly detailed privacy statement and EULA on the app's website, explaining exactly what data is collected. It's true that going through these steps required more effort on the part of the researchers, but it's not just a good idea -- it's the law.

This is my personal blog. The views expressed here are mine alone and not those of my employer.

How to get a faculty job, Part 3: Negotiating the offer

This is the third (actually fourth) part in this series on how to get a faculty job in Computer Science. Part 1 and Part 1b dealt with the application process, and Part 2 was about interviewing. In this post, I'll talk about what happens when you get a job offer and how to negotiate when you have multiple offers.

There is often a long and painful wait from the time you complete the interview until you hear back from the school about whether they will be making you an offer. This is generally because all (or most) of the candidates need to complete interviews before the final hiring decisions are made, and the actual offer needs to be approved by the department or school administration before the candidate can be given the good news. Depending on how early you interview, this wait can be on the order of a month or two. (Generally, candidates interview between February and April, and offers start getting made around April or May.) Sometimes a school won't contact you at all after the interview, and after a while you figure you're not getting an offer after all. Sometimes they contact you fairly quickly to deliver the coup de grâce, which is greatly appreciated since then you can at least stop holding out hope.

As I pointed out in the previous post on interviewing, it is a very good idea to keep in touch with schools you are really interested in and let them know where you are in the process, and especially if you have offers from other schools. Usually this can be done via informal email to your host when you interviewed. The last thing a department wants is for their top candidate to take a job elsewhere before they have a chance to make an offer. So let people know what's happening and try to find out how your top choices are doing in terms of making offers.

There are three kinds of offers: (1) Straight-up offers; (2) "Offers for offers", and (3) Second-choice offers. I'll explain each below.

Straight-up offers

The best possible outcome is that you get a call from your host or the hiring committee chair who says, "I'm happy to let you know that we're going to be making you an offer." At this stage, you probably will not get into any of the details about salary, research funding, and the like -- that comes later.

Most of the time, departments will offer to fly you out for a second visit, sometimes with your spouse or significant other, so you can spend time getting to know the department, university, and town. This is much more relaxed than the interview, and is a great way to get to know your potential future colleagues under less stressful conditions. A second visit can be very important for deciding where to kick off your career as a faculty member: you will learn many things that you might not have had time to get into when you interviewed. In particular, you are going to care much more about things like housing, schools for your kids, quality of life, and other factors that you didn't get a chance to judge during the interview. Definitely do a second visit if you are serious about a school.

Offers for offers

The dilemma faced by many departments is that they have several really good candidates but only one (or maybe two) open positions. If a department blindly makes an offer to its top candidate, but that person is not that serious about taking the job there, then their second- or third-choice candidates (who might be just as good!) might end up taking offers elsewhere while the first candidate sits on the offer in the hopes of using it as a point of negotiation with another school. Also keep in mind that schools generally cannot have multiple outstanding offers for a single position.

So, sometimes a department won't make an outright job offer, but will instead feel you out to find out if you're really serious about taking a job there, a so-called "offer for an offer". The idea is that the department can (and will!) make a formal offer, but only after determining that you really want it.

From a purely selfish perspective, it might seem that your best strategy is to amass as many offers as you can so you have the most leverage when negotiating salary and other aspects of the compensation. But this also puts the department in a real bind if you end up sitting on the offer without any real intention of taking it. I don't think pissing a bunch of people off (even at a place where you don't take a job) is a good strategy for anyone trying to jumpstart an academic career.

Some schools do ridiculous things like exploding offers, which expire after a set time, to avoid the situation where someone sits on an offer for too long. Given that schools are rarely well-synchronized in their recruiting schedules, this can be disastrous: Say you get an offer that explodes after two weeks, but you haven't finished interviewing yet and still haven't heard from most of the schools. The last thing you want is to be forced into accepting a job at a school because the offer was going to time out. By no means should you be forced to make a decision on taking a faculty job before you have had a chance to evaluate all of your options. Personally, I think schools that do this are being idiotic and should think seriously about what kind of people they are going to be successful recruiting though such tactics.

I once heard a case of a hiring committee which couldn't make up its mind, so they called their top five candidates and said, "We have two offers available, the first two people who call us to claim the offer will get one, but it will explode in two weeks." I think this kind of strategy is a complete load of crap, and the hiring committee should be ashamed of itself for not being able to commit to their top one or two candidates and ride it through. But I digress.

Second-choice offers

It is often the case that you aren't the school's top choice, but you are their second (or third) choice for the position. Sometimes a school will tell you this outright: That they would love to make you an offer, assuming that their first-choice candidate declines them. This can sting, of course, and I question the wisdom of telling candidates this much information. Most people don't want to take a job somewhere where they feel as though they were the consolation prize. Sometimes, you find out through the grapevine that someone else already has an offer from that school, but later on you get a call with an offer of your own (and it just so happens that the other candidate recently accepted a job elsewhere). At some point you have to swallow your pride and appreciate that in a few months, nobody will remember (or care) that you weren't the first choice, and you got an awesome job at a good school, and that's all that matters. The point is that an offer's an offer, so don't worry too much if you weren't the department's original top choice.

From sitting on the faculty hiring committee at Harvard, I can vouch for how hard it can be for a school to narrow its choices to one or two people in a field of really good candidates. Often the choice of who to make the first offer to is arbitrary, based on some general vibe that you think the person might be more or less inclined to accept the job. A department might have two or three candidates who are all more or less equal but they have to make a first choice somehow.

What's in an offer?

In most cases, the initial job offer is verbal and you won't get a formal, written job offer until much later, based on extensive discussions with the dean or department chair about what you expect the offer letter to say. There are several components to most faculty job offers that should be (eventually) spelled out in writing:

• The salary (of course). Usually salary is paid for 9 months of the academic year, with the expectation that you will pay the other 3 months out of a research grant. So if the offer is $100k for 9 months, that's really a 12-month salary of $133k.
• Summer salary support. Since most junior faculty come in with no research grants, usually a department will offer to pay one or two summers' worth of your salary until you get grants of your own.
• Teaching relief. At many schools, incoming junior faculty are given a semester of teaching relief which they can take at some point in the first couple of years. This gives you a little more free time to kick start your research and lessens the load of transitioning into the new job. My strong recommendation is to wait until your second or third term before taking teaching relief: Teaching a course (especially a graduate seminar) your first term on the job is a great way of recruiting students to your research group, and you're so screwed anyway the first semester as a new faculty member that teaching relief is hardly beneficial until you get your research group up to speed.
• Graduate student support. Many schools will provide funding to support one or two grad students for a couple of years, to help seed your research group. Of course, you still have to identify and recruit the students (a topic for a future blog post). Keep in mind that grad students aren't cheap. In addition to their paltry salary, the student's tuition and fringe benefits need to be paid for. Typically a PhD student will cost around $75K year all in, so support for a couple of students is a lot of money.
• Research support. This can take many forms depending on the school, but generally this is money (in some form) to help you get your research going in lieu of any grants. The best form of this is an outright slush fund which you can use to pay for anything related to your research: computers, equipment, students, summer salary, travel, conference registrations, pizza parties for the team, you name it. At Harvard, my "startup package" was in the six figures, but this is unusual; I think that most schools do something in the $20K range, sometimes less. (If the school is offering to pay for students or summer salary separately, you have to factor this in as well.) In many cases, a department will separately offer you some amount of equipment (such as a fund to buy a computers and laptop) in addition to, or in lieu of, a general slush fund. It depends very much on how the school manages its finances and chooses to account for things. Some schools without deep pockets may only offer you a hand-me-down workstation and a few hundred bucks to offset the cost of a laptop. It varies a lot.
• Lab space. I don't know how common it is for a job offer to include an explicit provision for lab space (that is, not including your own office). In many departments, grad student space is a shared resource and there is not usually a need for dedicated labs for specific faculty. However, depending on the nature of your research, you might need specialized lab space -- for example, if you are developing a swarm of quad-copters you probably need some dedicated space for that.
• Other perks. It is common for the department to pay for (or offset) your moving expenses, especially if you are moving from far away. An offer also might include things like temporary housing when you first move. Again, this varies a lot.

How to negotiate

Okay, so let's assume you're lucky enough to have a couple of faculty job offers in hand. What do you need to keep in mind?

First things first. Only negotiate with schools you are really serious about. It is a waste of everyone's time (and patience) if you feign excitement about a school just to get them to bump up your offer and use that as leverage against another school. People will know if you are bullshitting them. And keep in mind that even if you don't take a job somewhere, those people you run the risk of pissing off will continue to be important academic colleagues. One day they might be called upon to write tenure review letters for you. The point is you want to avoid making enemies.

Secondly, you can't compare industry and academic offers. At all. Compensation from industry is going to be much higher (especially over time) than any academic offer, when you factor in salary, bonuses, stock options, and the steeper increase year over year compared to a university job. So you can't expect to use an an industry offer as leverage to negotiate higher compensation at a university.

At many universities, the salary is non-negotiable as it is based on a standard scale that (in most cases) can't be changed. You might be able to negotiate a small salary increase if another school is offering much more, but this seems unlikely to me. Keep in mind that the range of starting salaries for junior faculty across different schools (at least among top-ranked research institutions) is pretty tight, so there's not much wiggle room there anyway. You can ask but don't be surprised if you're told that the salary is fixed.

If you can, try to get your startup package to be all or mostly cash. By "cash" I mean funding that can be used to pay for anything: students, equipment, travel, whatever. If your startup is segmented into X dollars for students, Y dollars for equipment, and so forth, that can constrain you down the line, if, for example, you end up wanting to hire more students than you expected or don't need as much travel funding. Fungibility is good.

It's a good idea to have a rough idea of how much you need to get started before you start talking hard numbers. When I did my faculty job search, I had in mind a research agenda involving building out an experimental workstation cluster as well as some other equipment needs, travel to several conferences in my first couple of years, and support for two students. I made up a quick and dirty spreadsheet to estimate how much all of this would cost and used that as the starting point for talking about the size of the startup package. If you have no idea how much you expect to spend -- and what you might spend it on -- you will have a hard time making a convincing case that you need more than what's being offered.

If you have a two-body problem (which is probably deserving of its own blog post), find out what, if anything, the university can do to help your partner land a job in the area. You may be surprised. When I was on the job market, my wife was finishing up medical school and we were going to make a decision about where to go in large part based on whether she would be able to get a good residency position. Although nobody could guarantee my wife a residency slot, the schools that were recruiting me helped set up meetings with a bunch of people to learn more about the programs in each area so we got a good sense of what her options were like. It is also not uncommon for universities to facilitate positions for spouses and partners of faculty they are trying to recruit -- many things are possible.

If you have kids, you should by all means try to negotiate for a spot in the university's day care center. The waiting lists for day care can be years long, but special exceptions can often be made when a school is trying to recruit a new faculty member. This is not always possible but it's worth asking about.

Finally, don't be greedy. This is not about maximizing your compensation and startup package and pissing everyone off in the process. Your goal in negotiating the offer is not to squeeze every penny you can out of them -- instead, it's to reach a point where you feel confident that the compensation and startup package will allow you to be happy and successful in your new job.

So which offer should you take?

Although I'm sure it happens, I would hope that nobody would take a faculty job just because it paid the most or had the largest startup package. If your only goal in life is to maximize your compensation, trust me: You do not want to be a professor. There are many, many other factors that are more important than the size of the offer: The culture and quality of the department, the students, the physical location, the quality of life ... the list goes on and on. In steady state, you're going to be a (relatively) poor academic, and struggling to get research grants just like everyone else. The initial salary and startup package can give you a boost, but it mostly comes out in the wash -- the absolute numbers won't matter much beyond the first year or so. So focus on finding the job that will make you happiest, not just that which pays the most.

How to get a faculty job, Part 2: The interview

This is the second (actually, third!) part of a several-part series on getting a faculty job in Computer Science. In Part 1, I talked about the application process. In Part 1b, I gave some details about how hiring committees decide whom to bring in for interviews. In this part I'll talk about what it takes to nail the interview itself.

Faculty job interviews are generally one or two (long) days. The main components are the all-important job talk; meeting with countless faculty, deans, and students; and usually some kind of fancy dinner. All of these components are essential to getting a job offer.

The process of interviewing is exhausting. Two full days of talking with people can really wear you out, especially since you need to be "on" all the time. As I'll explain below, any kind of dinner or social outing is not in fact a chance to take a break, since you're being evaluated during those times as well.

Planning travel: Usually, schools will pay for your travel and hotel expenses for the interview, though more often than not they expect you to pay the costs up front and they will reimburse you later. Get a credit card with great rewards since you'll be racking up the points over the course of several faculty interviews. Be prepared to lay out several thousand dollars for each interview trip as reimbursements can take a couple of months to process.

If you are interviewing at several schools, try to avoid doing more than two interviews back to back. Each of these trips takes a lot out of you and it's good to get home to recharge, even if just for a couple of days, in between trips. Also, don't plan on getting any real work done during the interview season. If your thesis committee is expecting a draft, try to get it off your plate before you start interviewing -- that way the pressure is off. By no means should you be trying to meet a paper deadline while interviewing. (Look at it this way: By the time you're interviewing, it's too late for any new publications on your resume to affect the outcome of the job search.)

What to bring and how to dress: You'll be giving a job talk everywhere which almost always means using a laptop to present. Get a lightweight laptop since you'll be lugging it everywhere, and will rarely have a chance to dump it somewhere as you are whisked from meeting to meeting during the interview. Always have your slides -- preferably in a universal format, like PDF -- on a USB stick as a backup in case you can't get your laptop to work with the projector. Also, under no circumstances should you assume that your laptop will have Internet access during the talk -- too many schools have their WiFi locked down and getting guest access can be difficult.

The dress code for job interviews is a topic of much discussion, and I know some people will disagree with me here: But dress formally. For guys, this means a suit and tie, with nice shoes and a nice belt. For women, this generally means a business suit as well, though there is a wider range of options for women who want to dress smart.

Why should you dress formally for an interview? Well, duh, it's a job interview. You want to be seen by your future colleagues as a professor, not just another slacker grad student. You also want to show your potential employer that you are taking the process seriously. At many schools you may have the occasion to meet with a dean or other such muckety-muck who might be the person to sign off on a job offer to you. You want them to see you as a mature professional. I see absolutely no disadvantages to dressing up well for a job interview, and many potential pitfalls for under-dressing.

Yes, you will feel silly at first, since (with rare exception) you will be the only person wearing a suit that you will meet during the interview. People will crack jokes, like "wow! you're really dressed up!" -- my typical response to that was "er, but I always dress this way" which would get a laugh.

It is best to bring two suits and alternate them. You never know when you might spill something on one of your suits, so you need a backup. This also gives you a chance to drop one of the suits off with the hotel to get it dry-cleaned while you're interviewing. Also, always bring your luggage with you on the plane: never check it. You cannot risk your luggage getting lost and being forced to interview in a t-shirt and jeans. I used a nice tri-fold suit bag which was compact enough to hold both suits and fit in the overhead bin on any plane.

The job talk: This is by far the most important part of the interview. If you give a bad talk there is no chance you will recover and end up with an offer, whereas a few botched one-on-one interviews might not sink you. The job talk serves the dual purpose of presenting your research contributions to the department, as well as showcasing your teaching ability. The talk needs to be extremely well-rehearsed, technically solid, clear, entertaining, engaging, and instructive. It is a tall order. If you can't do this well, then you probably don't want to be a professor, since giving talks and lectures is a huge part of the job.

You need to practice your talk, and preferably with an unfamiliar audience -- i.e., not just with people from your research group who already know your work well. Giving a "pre-job-talk" talk at another school is ideal, but be careful: if you blow it there you won't get invited for an interview. Doing a dry run at a school where you don't plan to interview would be a good idea.

It's important to remember that the job talk is not a talk to people in your area. The people in your area (say, systems or AI) already know your work -- which is why you're interviewing there in the first place. The talk needs to appeal broadly to the rest of the department -- to explain why your work is important, what the key contributions are, and to give them intuition for how to solve hard problems in an area other than their own. Don't worry if the job talk feels a little "lighter" than a typical talk you'd give at a conference: You will have plenty of time to get into the hairy details during the one-on-ones.

Margo Seltzer once suggested breaking the job talk into "thirds": The first third lays out the problem space and why it's important; the second third gets into the technical details of your solution (and it's OK to lose some people here, but try not to lose everyone); and the final third lifts back up a level to explain the implications of the work and chart out possible future directions.

As an example, my job talk slides from 2002 are here. I don't want to suggest that it's the best job talk ever, but I think it's pretty good, and got me a few job offers. I always try to have a joke or funny point sometime early in the talk, which helps break the ice with the audience -- for example, around slide 3 of my talk slides I had a funny story about the poor sysadmin of the USGS website not being able to fix his web server for three hours following an earthquake.

Sometimes an interview talk can result in unintended hilarity. When interviewing at MIT, I was asked by Alex Snoeren what impact my system design would have on the "email experience" of a typical user. I responded, "I've never had a mail experience before..."and then suddenly realized the double entendre of what I just said. It took me a few minutes to regain my composure although half the room was cracking up as well.

The one on ones: The bulk of the interview consists of a series of one-on-one meetings with faculty, deans, and sometimes students. These range from half an hour to an hour in length each. You rarely get a break during the day, so if you need to use the bathroom or grab a cup of coffee, just ask (everyone is happy to accomodate). Many of the people on your "loop" will be on the faculty hiring committee, and everyone (regardless of role) will be asked to provide feedback to the committee on whether they think you should be given an offer. So you have to impress everyone. Yes, this is hard to do.

The one on one can take many forms. Usually, you will be asked a bunch of questions about your research, your teaching plans, and future research ideas. You need to spend some time thinking about what you would work on and what kind of research agenda you might pursue as a new faculty member, so you can have a pithy response to these questions. Nobody is going to hold you to it, of course, but you should have at least some half-baked ideas about what would constitute a good research direction when you start the job.

Some interviewers will be trying to assess whether you will be able to get tenure at their institution in a few years. Of course it's way too early to make that judgment during a job interview, but if you can't come up with any kind of coherent research plan or agenda that sounds like it will bear fruit, you're going to be in trouble. When I interviewed, I was doing a lot of thinking about how to apply control theory to the management of complex computer systems, which led in all kinds of interesting directions (few of which I ended up actually working on when I got to Harvard). But at least I had plenty to talk about in terms of possible research directions.

You should also take the opportunity to learn as much as you can about the interviewer. After all, this is not a one-sided process: you should be evaluating the quality of the department and its faculty as well. When prompted, most professors can easily launch into a twenty-minute lecture on their research, so if you find you don't have a lot to talk about with someone, try to get them to do this. You will learn a lot this way and may realize amazing opportunities for collaboration. For example, while interviewing at Harvard, I was really excited by David Parkes' research on multi-agent systems -- and he and I ended up collaborating on a couple of projects once I started there.

The easiest of these meetings are with faculty in your area, since generally you have some common ground. The hardest are with people in completely different research areas. It is a very good idea to cyberstalk your interviewers before the interview, by Googling their names and learning as much as you can about their research beforehand. You might discover that there is some mutual interest or acquaintance this way, which will give you something to talk about. If you don't know who will be on your loop, ask your host and they can usually send you the schedule in advance. It's impressive when a candidate comes in having done their homework, knowing a bit about the interviewer's research and background. This is not creepy (although if you get into how cute their kids' pictures are on Facebook, you've probably crossed a line).

You will invariably meet with someone who was unable to make your job talk, so be prepared to give a 5-to-10 minute rundown on your research, a "mini job talk", if you will. You need to have a punchy, clear way to answer the question, "So, what do you work on?" My opening line was something like, "I work on making web servers really fast, and able to stand up to massive overloads." This was enough to get a conversation going on the topic and was a problem statement that pretty much everyone could relate to. If instead I had launched into, "I work on a hybrid event-driven-threaded server architecture combining rate-limited queues and feedback-controlled thread pools", I would have immediately put about half of my would-be interviewers to sleep.

There are, of course, some tactical questions you should try to get answered while you interview. The standard questions that candidates ask revolve around the teaching load, size and growth trajectory of the faculty, what new areas or initiatives the department might be starting up, what class sizes are like, whether there is a big Master's program, what the department's relationship is with the rest of the school, and of course what the tenure process is like. The interview is not the time to ask questions about compensation or benefits: Save that for once you have an offer (which will be the subject of the next part in this series).

You also want to learn as much as you can about living and working in whatever city the school is in. If you're thinking about buying a house or having kids, you need to understand about the real estate market, schools, good neighborhoods, commute, and so forth. If you care about eating and drinking out, you need to learn about the nightlife. If you ask no questions about the city or area, your interviewers will pick up on this and assume you're not that serious about moving there. You can also save these questions for a second visit after you have a job offer in hand, but it's probably a good idea to start learning about your potential new home.

The dinner: Most departments will take faculty candidates out to a fancy dinner somewhere. This might sound like a real perk, but believe me, after 8+ hours of interviewing, it's usually the last thing you really want to do. A nice glass of wine (or three) might sound like the perfect antidote, but it's probably a bad idea to drink -- you are still being evaluated over dinner, and if you're like me, you can get really uninhibited with the combination of interview exhaustion and alcohol. Of course, for the faculty dining with you, they are planning on expensing the dinner and wine, so by all means encourage them to order whatever they like (and maybe indulge yourself half a glass to help take the edge off).

The best interview dinners I had were with folks that I was friendly with and worked in my area. Dan Wallach at Rice recognized that I was probably getting sick of fancy restaurants and took me out to eat crawdads with my hands (and a big old plastic bib to protect my suit). The worst interview dinners I had were when several senior faculty used the time to gossip amongst themselves and completely ignored me. On that topic, don't gossip about other schools while you are interviewing. It's bad form, and an easy trap to fall into -- and keep in mind that everybody talks to everybody, so what you say at UCSB will get back to those folks at Duke, somehow (not that I would ever do such a thing).

After the interview: When you get home, or back to your hotel, be sure to send a nice thank-you note to your host, expressing your interest and enthusiasm for the school and department (assuming, of course, that you are enthusiastic and interested). Don't assume the school knows you really had a good time and would love to work there. Hiring committees are always trying to read subtle signals from the candidates about how seriously they would entertain an offer from their department, so if you're not explicit, the hiring committee might mistakenly assume you wouldn't be that keen on a position there. If you're not that interested, well, don't go out of your way to say that you are, but you probably don't want to let the school know right away. Having several offers -- even from schools you're not serious about -- can be a good bargaining chip when it comes time to negotiate the offer with the school you do want to join.

Finally, I strongly recommend taking detailed notes on your interviews, when you get back to the hotel each day. I found my notes to be invaluable when considering the several job offers I had, since my memories of a place started to fade after ten or so interviews. Writing out my observations and gut feelings about a school also helped crystallize the many tradeoffs in my mind.

After this it's mostly a waiting game to see if you'll get an offer. This can take a matter of weeks, depending on when during the interview cycle your visit happens to fall, so be patient! If you do end up with a time-limited offer from another school, it's perfectly acceptable to contact other schools you have not heard back from yet to let them know you are still very interested but are operating under time pressure. Stay tuned for the next part of this series where I'll talk about the process of negotiating offers.

How to get a faculty job, part 1b: How to get an interview

Back in Part 1 of this series on how to get a faculty job, I said there would be three parts in total. Well, I lied. I realized it would also be helpful to shed light on the process as seen by a faculty hiring committee, so in this post I'll augment Part 1 with a little behind-the-scenes of how hiring committees read and rank applications, and how interviews are granted. The "real" Part 2 will be about the interview itself, and Part 3 about negotiating the offer.

I served on the hiring committee at Harvard back in 2008 when we hired three great new Computer Science faculty: Krzysztof Gajos, Steve Chong, and Yiling Chen. It was an exhausting, months-long search with a dozen or so interviews for multiple openings (it had been a few years since we had any faculty openings and we really opened up the floodgates). So I have a little sense of how the sausage is made.

It's a complex process and utterly opaque for the poor applicant, who will usually not hear anything for many months after submitting the application. Most of the time, the response is a polite email from the hiring committee chair that because of the large number of highly qualified applicants for the position, they are very sorry that they will be unable to interview you. That is, if they ever contact you at all. Most schools don't bother even declining your application explicitly. You just never hear anything. (As for me, I'm still holding out hope that Stanford wants to interview me. It's only been 10 years since I sent my application, I guess it's still under consideration.)

Sometimes, though, you get lucky and are actually granted an interview. The most direct approach is an email saying that they are very interested in your application and would like to see if there are some dates you would be able to come for an interview. However, in some cases, a school doesn't want to "blow" one of its precious interview slots (more on that below) on an applicant who is not serious about their school. This will happen for a rock star candidate who is going to get interviews at MIT and Berkeley and only applied to your school to be polite, or as a backup. It would be a waste of time to interview such a candidate unless the department really feels it has a shot at landing this person. So, rather than directly offering an interview, the hiring committee might use side channels to find out if the applicant is serious about interviewing first -- for example, by getting in touch with the student's advisor and finding out more about what they're looking for in a school.

It's important to keep in mind is that whenever there is a faculty opening at any halfway-decent academic department, they will usually get inundated with hundreds or even thousands of applications from all corners of the globe. I am not exaggerating. The vast majority of these applicants are from schools you've never heard of in random countries where English is not the official language, and these people will rarely if ever get interviews (at least at good schools in the US).

The other thing is that most departments have only so much "interview bandwidth." Interviewing more than, say, a dozen applicants for a single position is very difficult. An interview typically lasts one or two days, you only have so many slots during the week in which to schedule job talks, and the committee has to spend a lot of time processing and discussing each interview. If a school has multiple openings in a year, they might still only interview a dozen or so candidates in total.

So, how do hiring committees decide who gets interviewed? There are about a million variables involved, but here are some of the most important:

Qualifications. Obviously this is important, but who counts as "qualified?" Your publication record is probably the strongest indicator of your success. Publishing at least one major conference paper a year -- after your first year or so in grad school -- is par for the course. Two or three papers would be a good year for most applicants. These have to be in good venues: Top-ranked, highly-competitive conferences. Workshops don't count (OK, maybe a little, but a lot less than real conferences). Journals don't count either. (This varies by field. In Computer Science, journals don't matter very much. But an article in Science or Nature will get you interviewed just about anywhere.)

Also, being first author on these papers is really important. Second author says, OK, maybe this student wasn't the most senior one on this piece of work, but they probably still contributed a lot. Third author on down conveys that you were not that involved and therefore get fewer points for the publication.

So you should expect to have something like five or six major conference publications -- ideally as first author -- on your CV, at minimum, to be taken seriously by most departments. Best paper awards are a big plus too, so list them on your CV whenever you get one. It is not uncommon these days to see applicants with ten or more top papers. I think this is a little insane. If you do a postdoc, though, you're expected to publish a good chunk of papers during that time, at minimum two a year -- the bar is higher for postdocs.

Your academic credentials matter a lot too. Your undergrad institution is not that much of a factor. I know plenty of famous faculty at top-10 schools who went to seemingly random undergrad institutions: Greg Morrisett, for example, apparently graduated from some place called the University of Richmond, which I'm sure is a very good school but is hardly a household name. What matters much more is where you went to grad school and (if you are doing a postdoc) where you postdoc. There is a reason that so many of the faculty at top-20 CS departments graduated from the likes of MIT, Berkeley, CMU, and Stanford -- graduates of these schools are highly sought after by CS departments and they tend to churn out enough graduates to fill the ranks of the top departments. So if you're coming from anything other than a top-20 school yourself, your chances of landing an interview at a higher-ranked institution are slim to none. (I know a bunch of people will argue with me here, and point out exceptions to the rule, but let's be honest. There is a strong preference for graduates of top-ranked departments when trying to pick 10 or so candidates to interview out of a pool of hundreds.)

The same goes if you're doing a postdoc. Actually, a postdoc can be a great way to increase your station in life if you didn't graduate from a name-brand department but still want a decent faculty job. Postdocing at MIT is almost (but not quite) as good as graduating from there.

The good news is that none of this shit matters if you do get an interview: No sane hiring committee is going to go back to your résumé and say, "Well, I really loved her interview, but she graduated from a lower ranked school than the other guy, so let's hire him instead." All of this is just about getting the interview. After that you're on your own.

Being a woman or a minority helps too. Hiring committees spend a lot of time trying to find anyone other than white men to interview, and most departments would love for their next hire to help increase the diversity of their faculty. This is a good thing, and is becoming more important as the diversity of the student population grows as well. If you happen to be one of these "underrepresented" candidates, more power to you -- given how competitive the academic job market is, you need every advantage you can get. (But see above about how this doesn't matter once you get the interview. That applies here too.)

Research area fit. This is a really complicated, multivariate function, in which the department attempts to discern, based on your CV, research statement, teaching statement, and letters, how well you would "mesh" into the department, whether you do the "kind of research" they are looking for, whether you can teach the classes that require coverage, and if you are likely to find collaborators in the department. It sounds like a lot to worry about, but the answer for you, as an applicant, is simple: It's too late for you to do anything about this. If you're a sixth-year PhD student applying for faculty jobs, it's too late to "rebrand" yourself to try to optimize for some complex, black-box process that is going on within each of the departments you're applying to. The time to figure out what research problems are going to look sexy on a job application is when you're a first or second year grad student, but, by the time you graduate those problems are just as likely not to be sexy anymore -- so instead, just do the research you love and hope you find a department that is looking for someone like you.

Sometimes you don't get an interview due to factors totally beyond your control. For example, I didn't get interviewed by a couple of departments because they had just recently (in the last year or so) hired graduates of my same research group at Berkeley. That poisoned the well for me -- there was no way I could pretend to not be doing research in the same area under the same set of professors. (There are still times I shake my fist at the night sky and scream "Armandooooooooooooo!")

Finally, your recommendation letters are key. I could write an entire blog post about what a good faculty recommendation letter should say, but you as a job applicant have little control over what your letters will look like. The letters touch on many things: Your technical and intellectual capacity, your research taste, your teaching style, your personality, your chances at getting tenure down the road. As an applicant, what you can do is make sure you talk to your letter writers before they write the letter. This is for several reasons. First, you want to address any questions or concerns they have about you up front. For example, there might be some lingering questions about how much you contributed to some project a few years back, and talking about it openly with your references gives you a chance to clear up any confusion. Also, your reference needs to understand what you're looking for in a faculty job. Say you are applying to a mix of top-ranked research universities and a few smaller teaching schools. This can lead to confusion: What kind of job are you after? Do you want to mostly teach? Or are the teaching schools a safety net? You need to give your references a chance to ask these questions directly rather than infer the wrong thing and write a blind letter.

What's the process like for the hiring committee? Usually, the committee will meet several times, go through the applicants, rank them in various ways, and try to reach consensus on whom to invite for interviews. This can take a month or more. At first, a couple of interviews might be given out to the clear front-runner candidates that they really want to snag early (since good candidates' interview schedules fill up too). Then a few more weeks of deliberation happens while the rest of the interviews are sorted out. Keep this in mind: If you haven't heard from a school, but know they have started scheduling interviews (say, by looking at their online events calendar where it's usually pretty obvious who's giving a job talk), that may not mean that all of the interviews have been decided yet: it's usually a rolling process. Generally the first interviews start to get scheduled around February, but March and April is when things really get going.

In the next part I'll talk about how to nail the interview.

How to get a faculty job, Part 1: The application

This is going to be the first in a series of three blog posts on getting a faculty job in Computer Science. Part one is about applying for the job. Part two will be about doing interviews. And part three will be about negotiating the offer and making a decision.

I did my faculty job search back in 2002 after finishing my PhD at UC Berkeley. Back then, academic Computer Science departments were hiring like crazy and the number of job openings far outstripped the number of highly-qualified applicants. I ended up with something like a dozen interviews, and also interviewed at IBM Research (both coasts), HP Labs, and a little search engine startup called Google. (I regret not having interviewed at Microsoft Research, but at the time I was dead-set on an academic position and had a hard time seeing myself working at MSR.) I got offers at all of the industry places and several of the universities; and ended up taking a faculty job at Harvard.

The process of getting an academic job is tremendously painful and takes months of effort. Faculty job applications are usually due in December or January, interviews happen around March and April, and job offers made in April and May. Before summer break most job applicants will have their position sorted out and know where they will be heading in the fall.

The job application itself usually consists of five components: Your CV, a cover letter, a research statement, a teaching statement, and letters of recommendation. I'll go through these in detail below.

In case you're curious, I posted my original (2002) faculty job application materials online here.

These days, most departments accept the job application online, either via a web form or email. When I applied, only about half of the departments accepted email and I had to send physical copies of my application to the other places.

The first critical component of the job application is your personal web page. I am always amazed at how many faculty applicants fail to maintain an up-to-date web page with their publications, research interests, source code releases, and so forth. Never assume that hiring committees will have your "official" application materials at hand: These days it's much easier to Google someone's name and look at their projects and papers online. For that matter, always post your job application materials prominently on your web page. In case someone is reviewing a set of candidates and can't find your research statement, everything should be linked to your web page so people can find it easily.

The curriculum vitae is probably the easiest part to get right. This should be a detailed summary of your research interests, publications, talks, service work, teaching credentials, and any other factoids that might be of interest to the hiring committee. Under no circumstances should it be a one-page "resume". My 2002-era CV is here as an example. Note how it provides a one-page summary of my research interests and a detailed breakdown of my job experience. The "invited talks" section is provided to give a sense of my experience giving keynotes and lectures at various conferences and universities.

The cover letter is a point of great confusion. First off, it's not always obvious that it's needed, and even when you have a cover letter, not everyone knows what it should say. These days, the cover letter might take the form of the body of the email that you send when submitting your materials. In my experience, the cover letter is a "school specific" statement of why you are applying to this school in particular. It should call specific attention to any potential collaborators at the school you are applying to.

For example, a good cover letter might say something like,

Dear Prof. Zuckerberg,

I am writing to apply for the position of Assistant Professor of Computer Science in your department. My research interests are in the area of computer systems and programming languages, and my thesis topic is "Rooter: A Methodology for the Typical Unification of Access Points and Redundancy." My thesis advisor is Prof. David Culler.

I am excited by the opportunity to teach and do research at University of East Nunavut. My research interests are highly complementary to Profs. Jobs and Ballmer in your department, and I would be particularly interested in collaborating with the Center for Computational Phrenology.

Please find attached my CV, research and teaching statements, and list of references. I look forward to hearing from you. 

You get the idea. It need not be long but it's a good way to customize your application for the specific school, while keeping the rest of your application materials generic.

The research statement is one of the hardest parts of the application to get right. It is intended to serve two purposes: To provide a narrative summary of your research contributions (and especially how they all tie together), and what areas you intend to work on in the future. It's usually about 3-4 pages long and needs to nail what your specific research "angle" is, why the area is important, what your track record is, and what your research vision is going forward. It is not a personal essay like you might have written applying to college or grad school -- If the expression "when I was a child, computers always fascinated me" appears anywhere in your research statement, you're doing it very wrong.

Nobody is going to hold you to working on the specific things you say you want to do for future research directions, but you should articulate a clear vision of what kind of direction you would take when starting a faculty job. This is important. Hiring committees are not hiring you based only on your track record -- they are hiring you based on your potential to be a (potentially) life-long colleague. They want to see that you have an independent and compelling vision for at least the first few years of your faculty job. If the best you can come up with is a couple of papers' worth of extensions to your thesis, you're in trouble. Try to think of a three-to-five year agenda that would get people excited to have you part of the faculty.

The teaching statement is like the research statement, but focuses on teaching. Most grad students have precious little teaching experience beyond a couple of semesters of TA work, so it's kind of hard to say much. Still, do your best. Keep in mind that teaching is a huge part of a faculty job and one of the most important criteria for extending an offer is whether you can teach well. If you have advised any undergraduate researchers or mentored junior grad students, include this in your teaching statement, as mentorship is important too. Finally, be clear on what kinds of courses you would be willing and able to teach. It's not always obvious based on your research background if you could take on, say, the OS or databases course -- make it explicit.

As for letters of recommendation, you usually need three or four. Resist the urge to have more than four rec letters: More is not always better, in case anyone writes anything to give the hiring committee pause. In general it is best if all of your recommendation letters are from well-known professors. Obviously one should be from your thesis advisor. A letter from a top-flight researcher in an industry lab is fine, too, but you should have no more than one of these: It's commonly held that industry folks write fluffy letters and hiring committees care more about the opinion of dyed-in-the-wool academics. One piece of advise I got when applying for faculty jobs was to have one letter from someone not at your home institution, who could comment more broadly (and objectively) on the impact of your research. I was fortunate to get a letter from the great Geoffrey Fox, whom I had met a couple of times and my advisor suggested would be a good "external" letter writer for me. It was kind of strange asking  a near-stranger for a letter like this, but he agreed and I guess it did the trick, since I got interviews pretty much everywhere I applied.

Keep in mind that the job application only gets you an interview, it does not get you the job. The interview is far, far more important than the application materials. It's also important to understand that hiring committees at top schools get many, many hundreds of applications, from all over the world, for a single faculty job opening. So, make sure your packet stands out. A strong publication record is the main thing. Strong letters are second. The research and teaching statement matter much less, so don't stress over them too much. You can't make up for a weak publication record with a brilliant research statement.

Finally, a note on where to apply for jobs. I often see students make the mistake of only applying to the top five or so universities, with the idea that they could only be happy at a place like MIT or Berkeley. This is a huge mistake. First of all, the probability that you're going to get a job at your "top" school is vanishingly small, considering the number of qualified applicants and scarcity of jobs. Second, you might find out (as I did) that schools that look great from a distance don't seem so hot when you're up close and interviewing there. This can cause you to seriously rethink your preferences for both what kind of school you want to be at, where you want to live, and where you see yourself building an academic career.

The converse is also true: You might fall in love with a place you would have never considered seriously before. For example, I knew next to nothing about Harvard before I interviewed there, and never imagined I would end up there -- until I visited, and found that I loved the place and the people. So try to keep an open mind about where you might go. There are lots of great departments out there, lots of great places to live, and many, many factors that count towards your overall happiness and ability to be successful. Apply broadly, include a few "safety schools" in your application list, and then cull the list later if you end up with too many invitations to interview. Most people don't have this problem, so don't be too picky.

Check out Part 1b: How To Get an Interview.

Startup vs. Big Company: What's "Freedom"?

I was talking with a talented young PhD student today about his career ambitions, and the conversation turned to whether it would be better to do a startup after finishing school rather than joining a big company, like Google, to get some "real world" experience first. I asked him what was so appealing about doing a startup, and he said that it would mean having tremendous freedom to choose what to work on and how you pursue problems. That is true, in a sense, but I question how much "freedom" you really have when starting a new company. Doing a startup is also highly constraining, there are real advantages to being at a larger company where you have more resources and a broader set of problems you can work on.

(Caveat emptor: Note that the last time I tried to talk someone out of doing a startup, it was Mark Zuckerberg, and we all know how that turned out -- so perhaps this post should be taken with a grain of salt.)

It seems to me that many startups these days are working on low-hanging-fruit problems: Things that a few guys in a garage can put together with EC2, Ruby on Rails, and XCode. Yes, you can build amazing products this way, but you're not necessarily doing rocket science. There are limits to what one can build with a small team and limited resources, and this means that most startups are constrained in the set of problems they can reasonably tackle.

Also, startups tend to focus on problems that one can build a standalone business around, something that can be monetized or build value in some direct way, in order to make investors happy. For example, it would be difficult to do a startup around a new programming language, since it's not clear how you sell it, although it might form a component of a larger product.

My point is that not all interesting problems are good startup fodder. This is where larger companies come in. One of the reasons I personally like working at Google is because I can work on problems at a scale that most startups would never achieve. Running jobs on terabytes of data on many thousands of cores is routine. For me, this is where the really interesting problems lie: Not in designing another sepia-tone photo filter app, but in solving fundamental problems of computer science that only emerge at the scale and complexity that I can work on here.

Being at a larger company means I am "free" to work on unsexy problems -- problems a venture capitalist wouldn't touch with a ten foot pole. Network protocol optimization, performance measurement, and infrastructure building may not be everyone's idea of fun, but I really enjoy doing this kind of core systems work that can have huge impact over the long run.

This is not to say that all problems at Google are unsexy. I just tend to gravitate towards infrastructure and networking since that's my background. And damned if I can program JavaScript.

The other side of being at a large company is that you have the freedom to fail. Money is not about to run out in a few weeks, and you don't have to make deals you wish you hadn't in order to keep the cash flowing. You can take your time to try different things, get it wrong, and make big bets that don't pan out. It's unlikely you'll lose your job for doing so, and there are always more cool problems to tackle just around the corner.

On the flip side, doing a startup while you are young and untethered might be exactly the right career move. In some ways I wish I had not sat out the dot-com boom doing a PhD, but taken a risk to join PurpleYogi or one of the other dozen or so startups (including Google) that tried to recruit me back when I was 22, unmarried, childless, and already used to living in a small apartment and eating ramen noodles for dinner. Who knows, maybe I would have learned JavaScript after all.

NCSSM and how it saved my life

I just got back from my 20th high school reunion and was reflecting on how much impact my high school had on my life and my career. You see, I was lucky enough to go to the North Carolina School of Science and Math, also known as NCSSM, or as we lovingly called it back then, "S&M". NCSSM is a public high school in Durham -- not far from Duke -- for juniors and seniors. Around 680 students live on campus, in dorms -- a lot like college, but with curfews, and students aren't allowed to have cars. To get in, you take the SAT and some other tests in 10th grade, and if you're accepted, it's completely free of charge -- no tuition, no housing fees, even the food is paid for. (The food was not, by the way, one of the highlights of the place.)

NCSSM is an utterly amazing place. Everyone I know who has been there has had their lives deeply touched by the experience. Although it has a well-deserved reputation as a school for, well, nerds, it is also full of some of the most interesting and creative people I have ever met. Twenty years later, it is amazing to see what my classmates are doing today: Doing high-end CGI for Hollywood movies; numerous professors and research scientists in areas as diverse as political science, planetology, integrated science and technology, and sociology; working for the Department of Health and Human Services while doing regular club and radio DJ gigs; even serving as an Episcopalian minister. Many of my classmates are not doing "science" or "math" in the conventional sense.

Prior to NCSSM, I lived in a small town called Wilson, about an hour east of Raleigh. (If you're from North Carolina, the correct pronunciation is "WILT-sun".) It would be understatement to say that I did not fit in in Wilson, which is surrounded by a rural tobacco-growing community. There were not a lot of people there like me, and my horizons were severely limited. The main pastime of high-school kids in Wilson those days was driving in circles around the mall parking lot. There were a few great teachers in the schools, but I really needed more than Wilson had to offer.

Coming to NCSSM I found a community of people like me -- a school full of outcasts, geeks, free spirits, lost souls. Not everyone was socially maladjusted, of course, but there were plenty of people there all pushing the boundaries of their humble (often rural and low-middle income) backgrounds. The faculty at NCSSM were (and still are) stellar. I could take Russian, quantum physics, photography, t'ai chi. It was like opening a vista on vast opportunities that I had scant awareness of when I was in Wilson, and I mean it seriously when I say that NCSSM saved my life: there's no way I'd be where I am today without that experience.

For one thing, my exposure to computing was greatly expanded at NCSSM. Along with some other students, I ran the school's VAX minicomputer which powered the school's "intranet" (although it was really a bunch of VT-100 terminals scattered around campus, tied to the single computer). The students and faculty all had primitive email and chat accounts on the VAX -- this was the days before the Internet was widespread. We also had an IBM RT, a high end (at the time) UNIX workstation with 3D (!!) graphics support. A few of us managed to get this machine on the Internet, over a slow ISDN connection, so we could use FTP and email, and the IBM RT was my first UNIX "root" account. At one point, I dusted off an old, unused Data General mainframe sitting in the corner, figured out how to boot it from tape, and set up a series of terminals in the adjacent computer lab, giving any student who asked for it an account, with the provisio that they have no password -- a tribute to RMS' similar practice at the MIT AI Lab. I got to do an internship at nearby Data General, and a volunteer from NC State taught a C programming class after hours. It was incredible.

Outside of conventional academics, NCSSM has tremendous resources for exploring music and the arts. It has the most unbelievable art studio, where we would spend countless hours: in the darkroom, screen printing, making stained glass, paintings, sculptures, ceramics. My major creative outlet there was the electronic music studio. Back then it was a somewhat modest affair: A couple of synthesizers, a drum machine, 8-track reel-to-reel, effects units, MIDI sequencer -- more than enough for me to produce and record two full-length albums (and no, I will not be posting MP3s). I spent hours in that studio every weekend, all thanks to the dear late Ray Church, the music teacher who let me and others run roughshod over "his" gear. The best aspect of this was that the studios were open all the time, and the students were trusted, and encouraged, to make it their own space and use the resources to explore their own projects.

It's important to keep in mind that NCSSM is a public school. It's paid for by the taxpayers of North Carolina, and can only exist because of a state legislature, and state university system, that recognizes the importance of having a high school like this. I can't imagine what my life would be like had I not had the opportunity to go there, and I know a lot of my classmates agree.