Wednesday, April 22, 2009

Hints for PhD Proposal Defenses

PhD proposal defenses in Computer Science allow student audience; this is a good opportunity to find out what works and doesn't from your more senior colleagues.
Proposal defenses consist of four parts: first, the candidate introduces themselves, then presents a summary of their work, interrupted and followed by questions from the committee. Finally, the committee meets in private to discuss the presentation and the plan.

While most of the committee will have read most of your proposal, you cannot assume that everyone has read every page in detail.

Avoid high-level talks: "... they usually fail to convey the intellectual substance, creativity, ingenuity of the speakers' accomplishments - what takes the work out of the routine. Naturally, these comments apply to all of our speakers who want to impress people with their ability as opposed to the breadth of their knowledge or the size of their project." (Ed Coffman)

When presenting experimental work, be prepared to defend your methodology. What was your sample size? Confidence intervals?

Standard presentation guidelines apply:
Talk to your audience, not to your slides.
Project; speaking softly conveys the impression that you are unsure of what you are saying.

Make sure that all your graphs are readable. Check this in the actual presentation environment (using a video projector), not just on your laptop screen. A common problem is that the lines are too thin.

Avoid flashy or cheesy animations, such as animated GIFs, or PowerPoint word art. This is not a sales talk and these gimmicks distract from the message and make you look unprofessional.

Keep to the allotted time of no more than 45 minutes.
Your presentation needs to address the following:
What is the problem you are studying?
Why is it important?
What results have you achieved so far and why to they matter?
How is this substantially different from prior work?
What do you need to do to complete your work?

Your workplan should be sufficiently detailed so that the committee can judge whether it is realistic or not. You don't have to account for every day between the proposal and your thesis defense, but a roughly monthly or quarterly granularity is to be expected, depending on how far away your anticipated graduation date is. Specify the experiments you need to run, the software you need to write and the algorithms you want to try out. This should not just be one page that says "I will do miraculous things".

The committee should be handed a copy of your slides.
No more than 25 slides, plus "back up" slides with additional material in case of questions. The committee will get anxious once the presentation lasts longer than 35-40 minutes.

List your contributions early and explicitly. You don't want to create the impression that related work is yours, and vice versa.

One of the most important concerns during the proposal is to convince the audience that you are aware of all related work. Since some of your work may date back a few years, it is not sufficient to just copy the reference list from your first paper. Check common recent conferences to see whether any recent work applies to your thesis. If applicable, point out your work predates work presented by somebody else done more recently. (Given the duration of most theses, it is not uncommon that others pursue a direction after you have stopped working on it.)

When presenting your contributions, be sure to use "I" and not "we" so that the committee will know what aspects of the work where yours, and which were group projects.

You must convey a clear plan how you are going to evaluate your work systematically - by measurement, simulation, user experiments. This is a core part what makes computer science science and not just software-building.

Be prepared to back up any comparative statement with facts, in particular statements like "works better", "faster", "scalable" or "optimal". If you are presenting a protocol, how do you know that it works correctly? If your algorithm is optimal, can you prove that it is? (If not, avoid the term.)

No comments:

 
hit counter
unique hit counter