The common theme of these is to make it very easy for reviewers to notice the strengths of your application. My selfish motivation for writing this list is that this makes it easier to review applications, but it will also make your application better.
See end of the quick take for caveats.
Assume that readers will initially only spend a few minutes on your application, so make it very skimmable.
If there’s something you really want to highlight, don’t be afraid to put it in multiple places (e.g. your CV as well as some free-form response)
You can use bold font for highlights in your CV (just don’t bold so much that bolding loses its impact)
The longer your responses, the more reviewers will skim them. This isn’t super bad because reviewers probably have a lot of practice skimming applications. But if you want to have control over what reviewers actually see, either optimize for density or structure your long responses very clearly (topic sentences, maybe even bolded headings).
Make it clear what the full range of topics is you’d be excited to work on.
For example, if you discuss a specific interest of yours, also make clear whether you’re mainly looking for projects in that area or are also open to very different ones!
Giving a concrete example of what you’d be excited to work on can ba a great way to demonstrate that you know the area! I’m not saying not to do that, just to also make clear how broad your interests are beyond that.
If you’ve done ML or coding projects that could support the application, make that clear!
Putting projects in a Github is a good idea! It can be hard to judge whether a project is actually impressive just based on a 1-paragraph description in a CV. By default, I’ll often assume that CV descriptions give an overly rosy view of the project. If there’s code to look at, that can be much more legibly impressive.
Link the Github in your application!
Skimmability applies here too: it’s useful if the README makes it clear what the project is about and why it’s impressive. E.g. if you have an ML project, put your main plot in the README, this makes it easy to tell that you actually ran experiments
Blog posts or project web pages are also great (personally, I think just writing a nice README is a good 80⁄20, but I’m not sure how much attention other reviewers pay to Github).
Generally go for quality over quantity. One very clearly impressive project can already have a lot of weight. If you list 7 different projects, I’ll probably just pick one or two to really look at anyway. So you might as well spend more space one your most impressive projects and then list the rest more briefly; that way I can focus on the most important ones instead of a random one.
If you have code or papers that you want reviewers to see but that aren’t public yet, don’t say “available on request.” Attach a link instead (which can be to a drive file etc.)
Personally, I’m pretty unlikely to send a request unless I’m seriously thinking about making an offer.
You can totally ask in the application that reviewers don’t share the paper (though that should be the default expectation anyway).
Caveats:
These are mainly based on my experience reviewing applications to MATS or CHAI internships. (I expect many generalize beyond that to e.g. full-time positions but don’t have experience reviewing for those.)
Obviously I can’t speak for other mentors and I’m sure some of them value other things in applications and would actively disagree with a parts of this list.
More important than the tips above is having the right skills and legible evidence of those in the first place. The list above is just about comparatively easy-to-do things during the actual application process
Tips for writing (MATS) applications.
The common theme of these is to make it very easy for reviewers to notice the strengths of your application. My selfish motivation for writing this list is that this makes it easier to review applications, but it will also make your application better.
See end of the quick take for caveats.
Assume that readers will initially only spend a few minutes on your application, so make it very skimmable.
If there’s something you really want to highlight, don’t be afraid to put it in multiple places (e.g. your CV as well as some free-form response)
You can use bold font for highlights in your CV (just don’t bold so much that bolding loses its impact)
The longer your responses, the more reviewers will skim them. This isn’t super bad because reviewers probably have a lot of practice skimming applications. But if you want to have control over what reviewers actually see, either optimize for density or structure your long responses very clearly (topic sentences, maybe even bolded headings).
Make it clear what the full range of topics is you’d be excited to work on.
For example, if you discuss a specific interest of yours, also make clear whether you’re mainly looking for projects in that area or are also open to very different ones!
Giving a concrete example of what you’d be excited to work on can ba a great way to demonstrate that you know the area! I’m not saying not to do that, just to also make clear how broad your interests are beyond that.
If you’ve done ML or coding projects that could support the application, make that clear!
Putting projects in a Github is a good idea! It can be hard to judge whether a project is actually impressive just based on a 1-paragraph description in a CV. By default, I’ll often assume that CV descriptions give an overly rosy view of the project. If there’s code to look at, that can be much more legibly impressive.
Link the Github in your application!
Skimmability applies here too: it’s useful if the README makes it clear what the project is about and why it’s impressive. E.g. if you have an ML project, put your main plot in the README, this makes it easy to tell that you actually ran experiments
Blog posts or project web pages are also great (personally, I think just writing a nice README is a good 80⁄20, but I’m not sure how much attention other reviewers pay to Github).
Generally go for quality over quantity. One very clearly impressive project can already have a lot of weight. If you list 7 different projects, I’ll probably just pick one or two to really look at anyway. So you might as well spend more space one your most impressive projects and then list the rest more briefly; that way I can focus on the most important ones instead of a random one.
If you have code or papers that you want reviewers to see but that aren’t public yet, don’t say “available on request.” Attach a link instead (which can be to a drive file etc.)
Personally, I’m pretty unlikely to send a request unless I’m seriously thinking about making an offer.
You can totally ask in the application that reviewers don’t share the paper (though that should be the default expectation anyway).
Caveats:
These are mainly based on my experience reviewing applications to MATS or CHAI internships. (I expect many generalize beyond that to e.g. full-time positions but don’t have experience reviewing for those.)
Obviously I can’t speak for other mentors and I’m sure some of them value other things in applications and would actively disagree with a parts of this list.
More important than the tips above is having the right skills and legible evidence of those in the first place. The list above is just about comparatively easy-to-do things during the actual application process