resources

Writing letters of recommendation is an important part of my job, and I am happy to do it. Writing a good recommendation takes time and effort, so it is in your best interest to help me do a good job. Here is some advice about requesting recommendations (which is largely based on Ravi Vakil's advice on the subject). This advice is tailored to my students, especially undergraduates, but I also frequently write letters for grad students, postdocs, and faculty outside my own institution.

The general philosophy is to make your request early, to include as much information as possible, and to let me know why you are requesting a letter from me specifically. Generally, you should give me at least one month's notice before your letter is due. If the due date is in less than a month, your recommendation may arrive late, be poorly thought-out, or I may decline altogether. If you would like to request a letter with less than a month's notice, please explain why in your email.

Similarly, you should explain why you are requesting a letter from me specifically. Did you do well in my class? Did we have interesting conversations in office hours? Have you been working as my research student, teaching assistant, or grader? You can even state that you just don't know anybody else you can ask for a recommendation, but please understand that the strength of my recommendation will depend on how well I know you. A great way to avoid the latter situation in the future is to take the time to go to your professors' office hours.

When sending me your request, please include any of the following items that pertain to your application:

• CV/resume.
• Transcript.
• Everything you will submit with your application (essays, research statements, proposals). Very good drafts are okay, but you should have these done early enough that you can send them with your request.
• If you have taken a course with me, tell me which class, which semester, and what your grade was.
• ArXiv links to any research papers you have written.
• Where you are applying, as well as any that deserve special mention for some reason.
• The deadline for the letter. Please send me a reminder one week before the deadline.
• Any other information that you think would be helpful for me.

A personal website is an indispensable tool for any aspiring academic. Opportunities for collaboration, speaking, refereeing, and employment all involve other people, and those people will look to your website for information about you. This is especially true once you have written your first paper, but I recommend creating a simple website as soon as you start graduate school.

There are a few things that your website should include:

• Your name, current affiliation, and contact information.
• The name of your advisor or research mentor.
• A photo of you that is recognizable and reasonably professional.
• An updated curriculum vitae.
• Your research interests and pdfs of any preprints or publications.

Aside from these, I would recommend keeping your website simple, organized, and easy to navigate. Being intentional about good visual design is a skill that will also improve the way you write papers and give talks.

The simplest way to create a personal website is to use Google Sites or a comparable service. If you have (or want to learn) some knowhow with html, you may prefer writing your own website. With this option, you will need a way to host your files. I recommend using GitHub Pages, which is simple and flexible.

You may also have the option to host your website on your department's server. However, you should remember that you will probably have to move institutions several times before finding a permanent position. If you use GitHub or another online service to host your webpage, you will not have to recreate your website or redirect visitors to the new address.

For creating your website, the usual advice is to copy the files from somebody else (with their permission). You are welcome to use my files if you like. If you prefer, I have also created a simple website template. Just download the html file and style sheet to your username.github.io repository, or the relevant public folder if you are using a different hosting option. You will want to edit the html file with your personal information.

For more information on creating an academic webpage, I found Zev Chonoles's guide useful when I was starting out. A fair amount of this material is irrelevant if you host your page through GitHub, since you won't need to access your math department's servers and won't be able to use php files, but the guide is informative and well-written.

Along with the papers you write, the talks that you give are one of the primary ways that you will communicate your ideas and results to others. Papers and talks are very different from each other, aside from two crucial similarities: papers and talks should be interesting, and papers and talks are often boring.

Let me share two extreme examples of bad talks that I have seen. These are both true stories.

• In the first example, the speaker used pages from their paper instead of slides. They read the pages essentially word-for-word, sometimes stopping to circle an equation or word. The audience was silent for an entire hour. When the moderator asked if there were questions, nobody responded.
• In the second example, the speaker was using slides completely full of text and math. The speaker took a very deep breath, paused, and then read the slide faster than an auctioneer selling equations. While this was happening, a woman (who appeared to be the speaker's mother) was walking around the room and filming the audience (without requesting permission). To this day, I am not sure if she understood that the many agape faces she documented were not expressing awe and admiration.

Of course, there are plenty of bad talks that are not so extreme. I've seen talks that are too technical, talks with not enough substance, ones with no compelling story, and ones with overly distracting theatrics. I've seen speakers ignore relevant questions or ignore their audience altogether.

A good talk tells a story. You want to convince the audience that what you've been working on is interesting, that your work might have some useful ideas to them, and that there is more exciting work to come. You want your audience to feel engaged, to ask questions, and to direct the flow of the talk. Here are some tips on giving a talk.

• Plan your story. Think about the content you would like to speak about. Who are the interesting characters? What is the conflict? What is the resolution? Come up with a few alternate endings, and allow your story to adjust to your audience.
• Limit the details. You have been thinking about your work for much longer than most, if not all, of your audience. It is easy to forget how long it takes before the details of a project are meaningful to you. When you begin a project, it is usually the big picture and a few motivating examples that guide your work. This is where your audience is — show them the big picture and a few examples. You can show the audience where the technical difficulties lie without burdening them with all of the notation and intricate proof details. If an audience member is asking for details beyond the threshold that is appropriate for the rest of the audience, discuss the details with them after the talk. Many collaborations begin with this sort of post-talk chat.
• Choose an appropriate medium. If you have more than 30 minutes to speak, I would recommend writing on the board over using slides. This gives you the flexibility to change the course of your talk (following one of your alternate endings) in response to questions from the audience. Slides are a better choice for short talks (15 minutes or less), or if you have nice images that cannot be reasonably drawn. I have also had success giving a board talk and showing slides for a few images. If you are using slides, you should prepare appropriately to avoid technical difficulties. Download your slides on your laptop, upload a copy to your website so that you can access them from someone else's computer, and bring any adapters you might need for HDMI, USB-C, etc.
  If you are using slides, you should use Beamer. Overleaf has a nice introduction to Beamer, and here is my personal Beamer template.
• Keep visual communication to a minimum. If you are writing on a board, do not write full paragraphs. Only use full sentences when absolutely necessary, such as when stating a theorem or a conjecture. If you choose slides, use as few slides as possible. Use as much white space as possible on each slide. What you say is far more memorable than what you write in a talk.
  To illustrate this point, let me remark that I have seen several talks where I could not hear the speaker at all. I do not remember anything else about these talks. On the other hand, I have heard several talks from a particular mathematician with shockingly bad handwriting. I have never been able to read more than a tenth of what he writes on the board, but he would have been fine with no board at all — all of his talks were outstanding. (Of course, you should still strive to write legibly.)
• Practice! After you have planned your talk, practice it on a board or with projected slides in an empty room. Speak slowly. Have a timer running. Avoid using your notes as much as possible. Take notes on where you get stuck, where things sound awkward, or where you think of a question that might stump you. Make the necessary adjustments, and practice again. Practice a third time with some friends in the room. As you give more talks, you will find a feel for how much or little practice you need. But until you develop that experience, it is better to err on the side of more practice than less.