Caution: This is unofficial advice from fellow grad students, and not department policy. See the Ph.D. Degree Requirements page for the final word on these topics.

The RPE is required of Ph.D. students before the end of the third year in the program. The UTCS Ph.D. program does not have the conventional doctoral “prelims”, “comps”, or “quals” examinations; instead, we have required classwork and the RPE. It's procedurally like a “micro-thesis”, with a small supervisory committee and a presentation. There are several important differences, though.

From the department Web site: “The Research Preparation Exam requires students to learn and demonstrate specific skills necessary to do research early in their careers.” Hopelessly vague, right? That's deliberate. The faculty say they want to have flexibility in the content of an RPE, to suit the circumstances of each RPE.

There are two criteria to the RPE. You need to demonstrate to your committee that you meet both:

Criterion 1. Capable of conducting original research.

Criterion 2. Capable of communicating technical content effectively to a “general CS” audience.

The department Web page says you need to “conduct research on a topic”, but this is very broadly interpreted.

One compelling way to convince your committee that you are capable of conducting original research is to present your original research that has been accepted to a good venue (conference or journal). Many RPEs in certain areas are presentations of results of accepted papers, but this isn't true for all areas or all students. A strong research proposal-type presentation, or partial results, are acceptable, too. Hypothetically, you could even present someone else's research, but you would somehow need to demonstrate your research capability based on that. No matter what you choose, make sure you agree with your committee in advance what this should be.

The amount of motivation, context/background, literature review, methods description, etc., expected in an RPE is different from a class report, conference talk, or a Ph.D. proposal. Remember, you are presenting to an audience that is not in your area. So, for example, the motivation/context/background material is more extensive than any conference talk would have. Again, a good approach here is to level-set with your committee in advance on these questions.

From the department Web site: the target audience is “a general-CS audience”. Presumably, that means CS researchers, but not in your area, or even a related area. You presentation will need to have a mini-lesson on the relevant concepts of your area, but not a lesson on core CS topics.

For example, if you're in theory, perhaps target a grad student in A.I., or vice versa.

Note that having a “general CS audience” does not mean you should produce a shallow and broad talk. No matter what their background may be, a technical audience expects your talk to be substantive and precise.

Your talk should definitely be rehearsed a few times with a practice audience. Ideally, this audience includes people from your area and outside your area. You need to be comfortable with the material you are presenting, and present it smoothly. You should give the impression of being competent and organized. “Winging it” has led to unpleasant outcomes in the past.

Be prepared with a well-rehearsed talk, but expect lots of questions and conversation. An RPE is a smaller setting and less structured than, say, a conference talk. Also, faculty will ask you questions for the purposes of determining your research capability and testing your presentation skills. This is an exam, not just a talk. Be ready for this.

Officially, the duration is “whatever it takes”. In practice, the public part of many RPEs run about an hour, including questions and answers. However, you might have such a succinct and powerful presentation that it's done in 20 minutes, or your presentation could generate so much discussion that it runs an hour and a half.

You should attend several (guideline: at least 3) RPEs before you give your own. This is good because:

1. You learn about open research problems. This may spark your own ideas!
2. You see what to do (or what not to do), and get a feel for expectations.