Advice about exams

This advice was written by Julie Zelenski for her CS106B/CS107 students preparing for a traditional timed exam, but much of this advice applies to our form of assessment as well, so we thought we'd share.

Philosophy

First, a quote from Will Shortz, the crossword puzzle editor of the New York Times:

A crossword puzzle is a battle between the puzzle maker and editor on one side and the solver on the other. But unlike most battles, both sides here have the same goal – for the solver to win. A perfect puzzle may put up lots of resistance. It may, in fact, seem impossible at first. Ideally, though, in the end the solver should triumph and think, Oh, how clever I am! – Will Shortz, How to solve

I love the spirit of this quote as it applies to exams. We absolutely want you to come out on top! The lectures, sections, and assignments work together to guide you toward mastery of the course learning goals and the exams serve as an assessment of your progress. The absolute best outcome everyone has a great grasp on the material to nail the exam. Read on for more advice on how to make that happen for you!

The rationale against IDE exams

Students often ask why exams are not done like assignments: using a compiler, having code completion and searchable documentation, being able to run, test, and debug, etc. We have tried this in the past and it didn't work they way we'd hoped. What we learned was that the immediate feedback from the IDE more of an impediment than an advantage in these situations.

Imagine this scenario: you read the first problem and have a good idea how to solve it. It takes you 20 minutes to draft a solution. You trace its operation and feel good about it. Let's say your answer is most correct, has minor syntax issue and a small bug that causes a few inputs to be improperly handled. Overall it would earn 8/10.

But if you can compile it, you certainly will. You have to fiddle with resolving syntax issues (that were likely not even scored). Next you spend time testing it. Although testing confirms it works correctly for most inputs, you now see that it has a bug. So you hunker down and rework and retest until perfect. Having spent an additional 20 minutes fixing these issues earns you a perfect 10/10, but the extra effort for the final 2 points was a tiny payoff and you have less time for the remaining problems

The even more devastating outcome were students who just plain got stuck on a bug and never advanced past the first or second problem. No matter how much we advised students to draft a good answer and keep moving, if confronted with direct evidence that the answer was not fully correct it was near impossible to move on.

We know there are limitations to working without the benefit of a compiler and debugger, and we account for that in how we design and grade the exam. We are assessing your ability to think logically and use appropriate problem-solving techniques. We expect you to express yourself in reasonably correct C++, but we will be quite lenient with errors that are syntactic rather than conceptual.

What to expect

Our exams are designed to evaluate your mastery of the course learning goals. We will focus on material from the assignments, section, lecture, and reading (this list is in order of decreasing emphasis). Having spent two solid weeks on recursion in all its glory, you can count on the exam asking you to demonstrate recursive problem solving. On the other hand, we would never test you on an obscure fact that only had the briefest of mentions buried in the textbook.

Answering the exam questions is typically going to require good comprehension of the foundational concepts and the ability to analyze and apply them in a given situation. We are evaluating that not only did you successfully complete the assignments and sections, but that you came away with a comprehension you can demonstrate. We will not ask superficial questions about terminology (e.g. "Define hashing") or details that can/should be looked up on demand ("Which header file has this prototype?").

Many questions will ask you to write C++ code. Other questions may ask you to analyze C++ code: to trace its behavior, to analyze its Big O runtime, to identify and fix flaws, or draw a picture of the memory layout. There may also be short-answer thought questions about various algorithmic techniques (searching, sorting, hashing), tradeoffs in data structure design, and the like.

When scoring answers, we will not be picky about minor syntax and oversights (missing braces around a block of clearly indented code, we don't ask for #include's etc.). The lion's share of the points are reserved for demonstrating a correct conceptual understanding and a valid approach to solving the problem, with somewhat fewer points for the minute details of executing on your plan. In our view, a solid first-pass approximation that shows the correct conceptual understanding of the key issues deserves to be strongly distinguished from code that exhibits significant conceptual issues and would require much trial-and-error with compiler/debugger to turn into working code.

Before the exam: prep for success

The long view. The mastery for the exams isn't created by a night of cramming, it is built up throughout the quarter. Make it a priority to monitor your own progress and identify holes or confusion to be shored up before moving on. The only exam-specific preparation is practice under exam-like conditions (i.e. without IDE).
Make reference/summary page as part of exam prep. The resources available to you in an exam setting may be limited a page of your own prepared notes (printed and/or hand-written). We are not expecting you to memorize minutiae and the exam will not focus on those details. Reviewing the topics and determining what information is worth including on your reference page will remind you of where we've been and help you take stock of your comfort level with the course topics. Use this opportunity to identify any areas on which you feel weak and resolve dangling issues before heading into the exam.
Recreate the environment. It is not a given that your real-world skills will translate to the exam setting without first becoming familiar with how the experience is different. The best practice is to solve problems without aid of compiler/debugger, in longhand using pencil and paper under a time limit, just as you will have to during the exam.
Practice makes perfect. Take problems (lecture or section example, textbook exercise, sample exam problem) and write out a solution under exam-like conditions. Review it to see how you did. This is much more valuable than a passive review of the problem and its solution where it is too easy to conclude "ah yes, I would have done that" only to find yourself adrift during the real exam when there is no provided solution to guide you!
Get your questions answered. If there is a concept you're a bit fuzzy on, or you'd like to check your answer to an exercise, or you wonder why a solution is written a particular way, get those questions answered before the exam. Swing by the lair, come to office hours, or post on the forum and we're happy to help.

During the exam: in the heat of battle

Scan the entire exam first. Quickly peruse all questions before starting on any one. This allows you to "multi-task"— as you are writing the more mundane parts of one answer, your mind can be brainstorming strategies or ideas for another problem in the background. You can also sketch out how to allocate your time between questions in the first pass.
Spend your time wisely. Don't get stuck on any particular problem. There is much opportunity for partial credit, so it's better to make good efforts on all problems than to perfect an answer to one leaving others untouched.
Consider the point value of each question. Divide the total minutes by the total number of points to figure the time per point and use that as guide when allocating your time across the problems.
Pay attention to specific instructions. A problem statement may include detailed constraints and hints such as "you must solve this recursively" or "you should not destructively modify the input list" or "you do not have to handle the case when the string is empty" or "this operation must run in constant time". You may want to underline or highlight these instructions to be sure you don't overlook them. These constraints are not intended to make things difficult, typically we are trying to guide you in the direction of a straightforward and simple solution. If you disregard these instructions, you are likely to lose points, either for not meeting the problem specification and/or for errors introduced when attempting a convoluted alternative.
Ask a question rather than answer the wrong one. If you are uncertain about what a question is asking or find some part of the question ambiguous, it's worth your time to ask the course staff for a clarification so you can be sure you are solving the right problem before you start working on it.
Syntax is not that important if it is clear what you mean. We won't trouble you about most syntax as long as your intentions are clear. But if there is ambiguity in your attempt, correct syntax can help us get the correct meaning. For example, if we see a for statement followed by two lines, where both lines are vaguely indented or a third line has been added in after the fact, we may be confused. If there are braces around all the lines, it will be clear you intended both to be a part of the loop body, but without the braces, we can't be sure and it may make your answer incorrect.
Style and decomposition are secondary to correctness. Unlike the assignments where we hold you to high standards in all areas, for an exam, the correctness of the answers that dominates the grading. Decomposition and style are thus somewhat de-emphasized. However, good design may make it easier for you to get the functionality correct and require less code, which takes less time and has fewer opportunities for error. Comments are never required unless specifically indicated by a problem. When a solution is incorrect, commenting may help us determine what you were trying to do and award partial credit.
Answer in pseudocode only if you must. If the syntax of C++ is blocking you from writing a solution, you can answer in pseudocode for possible partial credit. We discourage this approach as pseudocode is often lacking in detail or just restates the problem description ("I would recursively try all the subsequences to find the longest"). Such answers will earn little, if any, credit. Sufficiently detailed pseudocode (e.g. "scan the next token from input, if it the first char is a digit, then convert to an integer") would have been easier and more concise to write in C++ and will earn more points that way.