It’s grad school application season1, which means that prospective students have been emailing potential faculty advisors. In my field, computer science, this isn’t something that you necessarily have to do in order to find an advisor, but it can really help if you do it right. Unfortunately, it can also hurt if you do it wrong. I get my share of these emails — some better than others — and I want to give some advice on what makes an effective email from a prospective student.
Some things to leave out of your email
I can’t speak for anyone else, but here are some things that don’t impress me, at least, when I see them in emails from prospective students:
- Your standardized test scores, grades, lists of awards you’ve won, or any of that. I don’t care!
- A long list of places you’ve worked and projects you’ve done. Feel free to include your CV as an attachment, or, better yet, link to your CV on your personal website, but don’t regurgitate all that information in your email. I really only care about these kinds of things if they’re especially relevant to what you want to do in grad school.
- Requests for me to estimate your chances of acceptance at my institution. I honestly have no idea! The important question is whether you can get at least one specific faculty member who happens to be taking students that year to champion your application. Feel free to ask whether I happen to be looking for students this year; I can’t answer on behalf of my colleagues. (You could also ask “Do you think I might be a good fit for your group?”, but it’s probably not necessary to ask that directly; if I do think you might be a good fit for my group, then you’ll be able to tell from my enthusiastic response to your email.)
When customization goes wrong
One piece of standard advice given to prospective students is that they should customize their letter to each prospective advisor, rather than sending the same one-size-fits-all message to everyone.
This is good advice! I get a lot of emails from prospective students that are pretty bad because they’re not customized at all. These emails often say something like “I believe I would be an excellent fit for your research group” and then go on to discuss the applicant’s extensive background in computational biology, signal processing, circuit design, and a plethora of other topics, none of which are what my research group and I do (not that I have anything against those research areas, of course). These emails don’t make a good impression on me, but they don’t make a bad impression on me, either. They pretty much just bounce off.
To make an impression on a prospective advisor, you need a customized message. However, a poorly customized message can backfire and leave a bad impression. As an example of customization gone wrong, here’s an example of an email I got from a prospective student a few weeks ago:
Dear Dr. Kuper
Greetings! I am $NAME, a prospective PhD student for Fall ‘21. I have completed my B.Sc. in Computer Science and Engineering from the CSE department of $UNIVERSITY in $YEAR.
I am highly interested in Software Engineering, Big Data Analysis & Distributed Systems. Some of your research gave me valuable insights about the aforementioned topics. Among your research, Toward Domain-Specific Solvers for Distributed Consistency caught my eye instantly. In this research, you’ve stated that domain-specific SMT-based tools that exploit the mathematical foundations of distributed consistency would enable both more efficient verification and improved ease of use for domain experts. Also you’ve tried to democratize the development of domain specific solvers by creating a framework for domain-specific solver development that brings new theory solver implementation within the reach of programmers who are not necessarily SMT solver internals experts.
Another one of your research Verifying Replicated Data Types with Typeclass Refinements in Liquid Haskell seemed pretty interesting to me. This research is an extension to Liquid Haskell that facilitates stating and semi-automatically proving properties of typeclasses. Your work allows refinement types, that is augmented by Liquid Haskel, to be attached to typeclass method declarations, and ensures that instance implementations respect these types. I liked both of them.
[unnecessary information about this student’s background, test scores, and so on]
The author of this email wants to show that they are interested in the specifics of my research, which is great! Unfortunately, they chose to do that by plagiarizing from my papers.
domain-specific SMT-based tools that exploit the mathematical foundations of distributed consistency would enable both more efficient verification and improved ease of use for domain experts
democratize the development of domain specific solvers by creating a framework for domain-specific solver development that brings new theory solver implementation within the reach of programmers who are not necessarily SMT solver internals experts
are both verbatim from the abstract of my SNAPL ‘19 paper with Peter Alvaro, “Toward Domain-Specific Solvers for Distributed Consistency”. The phrases
an extension to Liquid Haskell that facilitates stating and semi-automatically proving properties of typeclasses
to be attached to typeclass method declarations, and ensures that instance implementations respect these types
are both verbatim2 from the abstract of my OOPSLA ‘20 paper with Yiyun Liu, James Parker, Patrick Redmond, Mike Hicks, and Niki Vazou, “Verifying Liquid Data Types with Typeclass Refinements in Liquid Haskell”.
Adding insult to injury, the email mangled the phrase “Liquid Haskell augments Haskell with refinement types” from our abstract into “refinement types, that is augmented by Liquid Haskel”, which doesn’t make sense even if you ignore the misspelling.
This isn’t a good way to apply the “customize your message” advice. It’s great if you can mention some specific, recent papers that you’ve looked at, and it’s great if you can say something about what stood out to you about those papers, possibly by paraphrasing some part of them. However, it’s not appropriate to copy and paste large chunks of text from the abstracts of a prospective advisor’s papers to describe your own research interests. This is plagiarism, and it will come across as insulting to many prospective advisors, because it makes it look like you assume the person reading the email is not going to notice or recognize that you copied and pasted. And — although the above example happens to be a particularly egregious copy-and-paste job — taking someone else’s writing, moving some words around, and replacing a few words with (supposed3) synonyms is also plagiarism, and is also not okay.
In fact, I’d claim that any prospective advisor who does respond positively to such an email is not someone you’d actually want as an advisor! If a prospective advisor doesn’t notice the plagiarism, that seems to me like a sign that they’re not particularly engaged in the process of writing their own papers (perhaps offloading that work to colleagues or students). If I were a prospective student, I’d be wary of signing up to work with an advisor like that.
What to do instead
Looking at other emails I’ve gotten from prospective students, here’s one that I consider good:
Dear Professor Kuper,
Hi, my name’s $NAME, and I’m a prospective PhD student (see CV, attached, for more details). My main area of interest is programming languages, with a secondary interest in systems, and I am very interested in doing research with you.
I loved reading your paper “Toward domain-specific solvers for distributed consistency,“ and I’m really excited about the possibilities that solvers people can modify and fine-tune to their specific problems themselves — without needing to be SMT experts — would bring in terms of new programming languages and tools. If you have any time in the next few months, I would love to talk with you.
This prospective student is referencing one of the same papers as above, but instead of copying my words, they’re paraphrasing and summarizing, using their own words. Another good thing about this email is that it emphasizes the prospective student’s excitement about the topic. Excitement is more important than perfectly polished writing!
I responded to this email and had several long and productive conversations with the student, and we ended up making an offer to them. They ultimately decided to accept an offer from a different school, and I’m confident that they will thrive there.
Here’s another example of a good email from a different prospective student:
Dear Professor Kuper,
My name is $NAME. I came across your page on the UCSC site and was immediately interested in your work. I watched the posted talk you gave and read a little of your blog/publications. Much of what you discussed in your lecture echoed the reasons why I love computer systems, in particular your work with Parallel Accelerators and their applications to scientific computing. When I took a class in systems, I was blown away by the complexity and the elegance of the code, the solutions to problems, and the scope of its applications. Recently, I have been especially interested in programming languages and systems design for scientific endeavors that require high performance computing, data management solutions, and distributed work. I like that your group works within a systems paradigm with a programming languages lens, but also has a multi-faceted approach . I still want to explore the breadth of computer science topics more given that I have not taken too many electives, but I think I have narrowed in on a computer systems focus for graduate research.
Currently, I am finishing my final semester taking undergraduate and graduate courses at $UNIVERSITY. I am enrolled in Programming Languages and Distributed Systems this semester. In $YEAR I graduated with a bachelor’s degree in $OTHER_STEM_FIELD and now work in an academic research lab studying $TOPIC. Here I was introduced to programming by one of my PIs. We work with a high volume of $STEM_SUBFIELD data so it was originally just a tool for me, but my fascination for computer science grew deeper over time. I started taking CS classes part time while working full-time with the goal of one day applying to graduate school and obtaining a PhD.
I am applying to UCSC this fall. I wanted to reach out to you personally because I think your group would be an excellent fit for my interests. If you have time, I would appreciate the opportunity to ask you a little more about the department as a whole in addition to any systems and PL research and resources that you might recommend for someone aspiring to work within the field.
If you’d rather speak by skype or by phone, I would be happy to arrange a call whenever is convenient for you. I look forward to talking with you.
This one’s a bit longer, but not inappropriately long. It makes sense that it’s longer, because in this case the student is from a non-CS undergraduate background and is explaining how they got interested in CS and why they now want to switch to CS for their graduate degree.
I responded to this email and shared a few links to give this student a better sense of the flavor of research that interests me most these days, since the project that had caught their eye was a few years old and not something I’m actively working on. (I don’t want to mislead a prospective student into wanting to work with me if they’re mostly interested in stuff I’m no longer doing.) The student wrote back with an excellent follow-up question about my more recent work:
Regarding the internals of the SMT solvers…it’s my understanding that you hope to provide a way for programmers to build their own solvers specific to the problems they are working on without expertise in SMT solvers. Is there much similarity between the internals of varying solvers? Wikipedia lists maybe 30 or so that I guess would be a base to build upon and selecting one or the other might involve evaluating trade-offs. Do you think it would be possible to have a single general purpose solver to build more specific solvers on top of or will many different ones be necessary in achieving your goals?
This student’s writing is refreshingly straightforward, and they’re asking interesting questions that warrant a serious response. Here’s part of what I said in my reply:
There are definitely some key ideas and algorithms that get used in most, if not all, modern SMT solvers! I discuss some of them in the lecture notes from my class last fall, and I also recently gave a talk about the conflict-driven clause learning (CDCL) algorithm that SAT solvers use.
But one problem is that heavily-optimized modern solvers are (like some compilers) pretty hard to understand, modify, or predict the behavior of. I know people who run several versions of Z3 at the same time, just because they don’t know which versions will work faster for the problem they’re trying to solve!
In principle, an SMT solver has a modular design, where there are distinct theory solvers and an underlying SAT solver, and it should be possible for people to plug in their own theory solvers. But in practice, my impression is that plugging in your own theory solver is still very hard to do, to the point where most people don’t attempt it. That’s something that I would like to try to address in the long run. But in the short term, I’d like to develop fluency in those aforementioned higher-level solver-aided tools, and then try to figure out what the limitations of those tools are and where they reflect a limitation in the underlying solver that a custom theory solver might help with.
Replying to this student’s email gave me an opportunity to reflect on what research goals I consider worth pursuing in the short and long term, and to try to articulate those goals. I really had to think to answer these questions — which is good. At the same time, though, the student is asking specific questions (and not merely “What do you think the next step is for your research on $TOPIC”?), demonstrating a willingness to meet me halfway. Ideally, my students and I will work as a team, both investing effort in each other and making each other better in a virtuous cycle. I’m looking for students who are interested in that kind of mutually beneficial partnership.
Obligatory plug: if you’re applying to computer science graduate programs and you’re interested in studying programming languages, systems, databases, and the intersections of those areas, consider applying to UC Santa Cruz to join the Languages, Systems, and Data Lab! Deadline of January 11; GRE not required! ↩
Well, not quite verbatim: I correctly hyphenated “domain-specific solvers” in my own paper. ↩
A tell-tale sign of this kind of find-and-replace plagiarism is when a term of art in the original text has been replaced with a supposed synonym that actually destroys its meaning. ↩