The comprehensive exams (often called the "comps") are the first significant step towards a Ph.D. degree. The comprehensive exams must be passed before a student can form a Ph.D. committee and work on a dissertation proposal. They test the student's breadth of knowledge in computer science and are in the areas of: systems, programming and theory. The comprehensive exams are given twice a year, at the beginning of the fall and spring semester.
It is important to take a positive view of the exams and studying for the exams. As a Ph.D. computer scientist you will be expected to have a solid foundation of knowledge in all the major areas of computer science. This knowledge also includes proficiency in the problem solving processes that have been developed in these fields. This knowledge is essential to do your job competently and everyone gets satisfaction from being competent at their work. We divide up the exams into three areas because it is convenient to administer the exams that way but computer science is not sharply defined into areas. The areas all overlap and knowledge from one area is often necessary in order to solve problems in another area.
The purpose of the exams is to make sure you have this necessary breadth of knowledge in computer science and a command of the problem solving processes used in these areas. The most important part of the exams is the studying for the exams. This is when you acquire a wide knowledge of computer science. We have the exams to insure that you do the studying. Once you start working on your dissertation and as a Ph.D. computer scientist you will not have time to acquire this knowledge. You will be too busy and too specialized. This is your only chance to gain this knowledge.
So think of these exams as your chance to become a real computer scientist.
Most students take the exams after a year or a year and a half of study in the graduate program, that is, during their second year in the program. When a student takes the exams depends on how much prerequisite material he or she has to make up.
Try to inform the graduate advisor when you plan to take the exams. That way we can plan ahead and maybe help the test takers form study groups.
In some sense, the exams test for a thorough understanding of undergraduate computer science. The three exams cover the following areas:
There are several things you can do to prepare for the exams.
See the Suggested Readings section for a list of reference books. Many of these are text books for CS courses. You can save money by sharing these books with other people studying for the exam or who have already taken the exam. Sometimes you can borrow them from one of the faculty.
The best place to find typical questions is to look at old exams. Another good source is the books you read in studying for the exams. Another is the exams and homework for the courses related to the exams.
Many students form study groups to get together and talk about the material and the answers to exam questions. You might try the following procedure. Everyone in the group tries to answer the question at home in a test-like situation (no help, limited time). You get together and discuss your answers. Then go to a faculty member in the area and go over your answer with them. You will get more out of this if you do all three steps.
Each exam is roughly based on a few key courses in the area. Taking these courses can be helpful in studying for the exams but do not make the mistake of relying exclusively on taking or sitting in on the relevant courses. This can be useful but it is not enough to pass the exams. We require from Ph.D. students a much deeper understanding of the material than we expect from the students in these courses.
Do not feel like you have missed something if you took the course several years ago (or at a different university) when somewhat different material was taught. Get the current books, read them, think about them and read them again. This will put you ahead of someone who simply took the class.
Talk to people who know about the exam. Talk to other students who have taken the exam already. Talk to professors who make up the questions and grade the answers.
Each exam is a one-day, closed-book exam from 9 AM to 5 PM (with breaks). The programming language exam is usually given on Monday; the operating systems and architecture exam is usually given on Wednesday; the theory exam is usually given on Friday. Previously, the theory exam was a take-home exam, hence the longer length of some of the sample exams.
The exams are always given the week before the start of classes in a semester (the registration week). Normally the programming languages exam, the operating systems exam, and the theory exam are closed-book exams that you take in one day. The closed-book exams will not concentrate on details and you will not be required to remember long lists of things. On the other hand, you will be expected to know the important concepts in the field. For example, in the systems exam you would be expected to know what virtual memory is and be able to give the general idea of at least two page replacement algorithms. We try to emphasize general understanding and integration of material in each exam.
Use normal test taking strategies. Look through the whole test and do the easier problems first. Do not make the mistake of spending too much time on a hard problem that you can't answer anyway and then not have enough time to answer the questions you can get right.
Generally 70% or better is always a passing grade so it is not necessary to answer every question.
Partial credit is given on most questions so you should answer the parts you can do even if you cannot answer the whole question.
It is not uncommon for some of the questions to be vague and/or ambiguous. Sometimes this is intentional and sometimes this is an error or just carelessness on the part of the people making up the exam. Feel free to ask any questions about the statement of the problems. If we cannot answer your question we will tell you so. There is no penalty for asking questions. If the ambiguity was not intentional then it can be cleared up.
Sometimes we will offer to answer a question with the understanding that you will not be able to review credit for that question (or that part of a question). This is is allow you to answer multi-part questions where you may have forgotten some particular term or concept.
On the other hand sometimes the ambiguity is intentional. One of the things we are testing is your command of the problem solving processes in the area. Part of this is the ability to interpret a vague question. If you have to make any assumptions in answering the question be sure to state them clearly. You might even answer the question several times, each with a different assumption. If you use an unstated assumption we may grade the answer down but if you state your assumptions we will be in a better position to understand your answer. The way you interpret the question reveals how much you know about the area and how well you understand its subtleties.
Read the questions carefully and answer the specific question rather than giving a general discussion of the area the question is about. For example, if we ask what page replacement algorithms are most commonly implemented in operating systems we are not asking for a listing of all page replacement algorithms.
Many questions have multiple parts. In some cases the first one or two parts will be material that is fairly elementary. We put these in as a ``warm-up'' to lead you into the parts of the questions we are really interested in. Usually these parts have a small point value. For material that can be looked up, we expect a clear and concise answer in your own words.
Answers that contain a lot of irrelevant material are generally marked down. Suppose there is a question about what factors would cause you to choose write-through in a caching system. This is not an invitation to tell us everything you know about caching systems. We are looking for the answer to a specific question. If the answer to the question appears in the middle of a long, irrelevant discussion it will not count as much as the answer would alone. You might not get any credit for it at all because we would feel that you did not really know what parts were the answer to the question. Part of the exam is knowing what is relevant to the question.
On the other hand, minimizing your discussion is also dangerous. Outside of standard definitions, which might be a sentence or two, take time to show your understanding, even for definitions. Examples are encouraged.
What we are saying is that a part of this exam is knowing how much to write, that is, knowing what is relevant and what is not and how much explanation is enough.
It is damaging to your answer to put down incorrect information. We want to be sure that you know what you know and what you do not know. If you are not sure of something, say you are unsure of it or do not put it down at all. It is not nearly as bad to make a bad guess as to firmly believe that something is true when it is not.
It is sometimes easy to write down an incorrect statement in the course of a long answer just because you are not being careful about how you say things. An error of this sort can make your whole answer look careless and alert the reader to look very carefully at the rest of it and the reader may end up being more critical than normal. Avoid this possibility by re-reading your answers and catching careless mistakes.
Clear presentation is also part of the exam so spend some time with your presentation. Use diagrams where appropriate. Diagrams are often useful but are not used in exam answers as much as they should be. Readers like diagrams and are more favorably disposed towards answers that have diagrams.
The same goes for tables and concise summaries.
A significant part of your studying will be reading reference books and studying topics in the areas of the exams.
Available in various formats
| When Given | Operating Systems | Programming Languages | Theory |
|---|---|---|---|
| Spring 2011 | |||
| Fall 2010 | |||
| Spring 2010 | |||
| Fall 2009 | |||
| Spring 2009 | |||
| Fall 2008 | |||
| Spring 2008 | |||
| Fall 2007 | |||
| Spring 2007 | |||
| Fall 2006 | |||
| Spring 2006 | Not available | ||
| Fall 2005 | Not available | ||
| Spring 2005 | PDF | PDF with Solutions | Postscript PDF | |
| Fall 2004 | Not available | Not available | |
| Spring 2004 | |||
| Spring 2003 | HTML | Postscript | Postscript |
| Fall 2003 | PDF | PDF with Solutions | ||
| Fall 2002 | Not available | Not available | Postscript |
| Fall 2001 | HTML | HTML | HTML Postscript |
| Spring 2001 | HTML PDF | HTML PDF | PDF Postscript |
| Fall 2000 | Postscript | ||
| Fall 1999 | N/A | Postscript | |
| Fall 1998 | HTML PDF Postscript | HTML PDF Postscript | Postscript |
| Fall 1997 | HTML Postscript | HTML Postscript | Postscript |
| Spring 1997 | HTML | HTML | Postscript |
News & Events | People | Academics | Research | Jobs | Companies | Visitors | Computer Facilities | Home
