Selection Tips: Informal Advice to assist with Project Selection
Stephen Kell (Part II graduate in 2005) provided an advice sheet for the Part II students he now supervises. The following is a slightly-edited version of his original (that can easily be found using a search engine).
Some thoughts and tips about Part II Projects
Part II projects are a decidedly tricky part of the Tripos course, and it's easy to unwittingly make mistakes early on which really compromise your chances later. As someone who, despite being fairly conscientious and (I like to think) fairly competent, ended up with a decidedly average project mark when I took Part II in 2005, I've written up a few pieces of hard-learnt advice. Please don't take them as gospel: if you follow them and subsequently aren't as successful as you hoped to be, I won't be held responsible for your perceived failure. Nevertheless, I hope they're useful.
The project idea is important. Get thinking early; don't leave it until the last minute.
Pick something achievable. You might think that, as your dissertation is judged on its "computer science content", as long as you can talk about what went wrong and what you would have done given lots more time, failing might not be such a disaster. In practice, the marks come far more easily if you're writing about something that was a success.
Pick something quantitatively evaluable. The "quantitative" part is important! (A few people do opt for more qualitative evaluation methods, such as user studies, and sometimes do a good job. But this is much harder, and takes a long time. Save yourself the headaches if at all possible.)
Have an application. Even if you're writing something low-level and systems-oriented, rather than an application itself, having a neat demo really will count for something. (When doing any systems work you should really expect to be asked what it's useful for, and how well it works in practice.)
Do something fairly advanced. It might seem paradoxical, given that you've barely started Part II when you write your project proposal, but showing understanding of technical content from Part II courses (or comparably advanced material) in your dissertation will gain you a lot more marks than the material you're already familiar with. There's no easy solution to this: reading ahead will help you a little, but there's no avoiding a certain leap of faith and the corresponding risks.
Projects need to be challenging and to be executed competently, which typically means using advanced algorithms or data structures or libraries thereof. Their presence is a sure-fire way of impressing the examiners, and their absence is certain to be remarked upon. However, writing your own quicksort when a sorting function is already available in a library is simply bad.
If you have research ambitions, don't feel that this is the place to start. As someone who wanted to go on to do a PhD after my Part II, I thought that my project was the place to start working on my ideas and showing them to people. It wasn't. That's not to say that you can't do a research-oriented project, but I'd seriously only do so if your idea meets all the other criteria. A good project in some slightly-displaced area will do you more favours than a compromised research-oriented project, even if the latter has some neat ideas behind it.
Pick something with "core" and "extension" elements. Aim to complete a basic working version of the "core" in the middle of the Lent Term. The "extension" should ideally also be something that you're able to do!
When looking for a supervisor, don't use e-mail. Or rather, if you do, pester like mad. Finding a project supervisor can be a crazy free-for-all. You should of course try e-mail first, and may well get a prompt response. If you don't, and it's coming up to proposal-writing time, try the other strategies. Most importantly, don't sit back, and don't be timid!] (One of my friends was led on a wild goose chase by this e-mail process. By the time he found an interested supervisor, he was turned away for being "too late" -- the supervisor had already taken on sufficient students. The best way to get results is to meet in person, or telephone. Try calling your target from Student Admin and arranging a time to meet. If you can't get hold of them, try contacting one of your (current or former) course supervisors from the same group: they might have some idea of your target's whereabouts, or be able to suggest alternative supervisors. If that fails, try a lecturer. Ultimately it is your DoS's responsibility that your project is supervised, so feel free to apply pressure to him or her.
Your supervisor is important. Don't underestimate the potential benefits of getting advice from someone more experienced. Some supervisors are proactive and interested in the projects they supervise, while others could hardly care less. Pester your supervisor. Try to arrange fairly regular meetings, though don't feel the need to make them more frequent than you're comfortable with. If your supervisor really doesn't seem to care, talk to your overseers. You might also get some useful informal advice from one of your course supervisors.
Disclaimer: the above tip sheet is a personal view and may differ from official Computer Laboratory policy.