How do I find out my score? The scores have been released on Gradescope, a website for grading course materials. Just sign up for an account on that website using your Stanford email. You do not need an access code.
How do I see my exam? A complete scan of your exam is available on Gradescope.
The statistics of the exam scores (out of 50) were as follows:
Standard Deviation: 9.44
Below is a practice exam as well as the midterm reference sheet. This will give you a chance to ensure BlueBook is working correctly. It will also provide you with a general idea of what to expect on the exam. We will release the practice midterm answers in a few days. We strongly recommend you attempt to complete the entire practice exam before checking the answers. NOTE: on the actual midterm, the reference sheet will be a part of the BlueBook exam. We wanted to give you the pdf separately in case you wanted to print it out.
The Honor Code: the exam is to be completed individually and without any assistance from a partner or other students. Follow the Stanford Honor Code (see the corresponding handout in the Handouts dropdown) during the exam: submit only your own work and do not use unpermitted aids on the exam (see below for permitted aids).
BlueBook: The exam will be done on a program called blueBook. Please review the BlueBook information here. This website will give you a link to download the program, you can then try the practice exam with the program to ensure it is working. In particular the key points from the website are mentioned here:
Permitted Materials: During the exam, you may use/reference:
One double-sided 8x11 inch sheet of notes
A syntax reference sheet, provided during the exam
You are not permitted to use any other materials, such as printouts (notes, slides, code, practice exams, etc.), other textbooks, or electronic devices (iPads, Kindles, calculators, music players, etc.).
Grading: Unless a question specifically mentions otherwise, the code you write will be graded purely on functionality (proper behavior and output) and not on style. For instance, redundancy, variable names, commenting and decomposition will not impact your score. However, we still encourage you to use good style in your code as oftentimes they are easier to write out and modify if needed, as well as being easier to grade.
Note that certain problems may have certain constraints (such as only using certain material, etc.) that you must follow to earn full credit. We reserve the right to deduct points for extremely inelegant or inefficient code that dodges the spirit of the problem.
You are not required to write
#include statements on the exam. Please do not abbreviate any code on the exam (such as writing "x2" next to code to copy it twice). Abbreviated code will not be graded.
Pseudo-code (writing English sentences and phrases instead of code) will typically earn little to no points. For example, writing "In this part of the code, I want to open the file and read each line and print it" will not earn any points.
The midterm will cover all material up through (and including) recursive backtracking. Note that the midterm may include questions about recursive backtracking, so it is highly encouraged that you complete (or do a large part of) assignment 4 prior to the midterm. This includes the following concepts listed below. Note that you may be asked to read code (look at a piece of existing code and answer questions about it, such as writing its output) and/or write code (write a piece of code such as a method or short program that solves a given problem).
C++: Console and File I/O, strings, and C++ syntax
Recursion: You should be able to read and write recursive code
Recursive Backtracking: You should be able to read and write recursive backtracking code
Algorithmic Analysis: You should be comfortable evaluating the big O of a snippet of code, similar to the examples done in lecture and section.
The following concepts will NOT be tested on the midterm:
Generalized linked list code
Arrays and/or structs
Throwing exceptions with the
Hopefully you have been keeping up in lecture and doing well on the assignments, but may be unsure of how to make sure your skills will translate well to the exam setting. We will distribute a practice midterm to give an idea of what to expect, but we also want to provide some general advice for how to prepare and approach the exam.
We recommend lots of practice! A cheat sheet will help you avoid memorizing minor details, but you should spend a lot of time practicing problems in the practice exams, section handouts, lecture examples, and CodeStepByStep.A good way to study for the programming problems is to take a problem (lecture or section example, chapter exercise, sample exam problem) and write out your solution under test-like conditions. Don't fall into the trap of just practicing your exam problems on the computer. The computer compiles your code and provides immediate feedback that you won't have on the real exam. You want to practice under real exam conditions to become comfortable writing code without the ability to immediately run and test it. This is much more valuable than simply reviewing the exam, looking at the answers, and making sure you understand why they are correct - a much different task than having to write the solutions yourself.
Get your questions answered. If there is a concept you’re a bit fuzzy on, or you’d like to check your answer to something, or you wonder why a solution is written a particular way, swing by the LaIR, come to office hours, find Tyler after any lecture, or email your Section Leader/grader; we are happy to help.
Scan the entire exam first. Quickly peruse all questions before starting on any one. This allows you to “multitask” — while working on one problem, 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. Speaking of which...
Spend your time wisely. There are only a handful of questions, and each is worth a significant amount. 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 on 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. You may want to reserve a little time for checking your work at the end as well.
Style and decomposition are secondary to correctness. Unlike the assignments where we hold you to high standards in all areas, for an exam, unless a question explicitly says otherwise, your responses will only be graded on functionality. 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 errors. Moreover, when a solution is incorrect, good stylistic practices such as commenting may help us determine what you were trying to do and award partial credit.
Pay attention to specific instructions. A problem statement may include detailed constraints and hints. You may want to underline or highlight these instructions to be sure you don’t overlook them. These constraints are not there to make things more 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 more difficult alternative.
Syntax is not that important if it is clear what you mean. We won't trouble you about most small syntax errors (forgetting semi-colons, misspellings, etc.) as long as your intentions are clear. Having said that, if your syntax errors cause ambiguity, we might not 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, but you forgot curly braces, 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.
Save a little time for checking your work. Before handing in your exam, reserve a few minutes to go back over your work. Check for missing initialization/return statements, correct parameters passed to functions, etc. We try not to deduct points for minor things if it is obvious what you meant, but sometimes it is difficult to decipher your true intention. You might save yourself a few lost points by tidying up the details at the end.
Always remember why you are at school. Learning and education tend to be a more fulfilling goal than just high grades. If you work hard, study lots and feel good about your understanding of computer science, that is an achievement to be proud of in itself — regardless of how many points you get relative to the other students in the class. Moreover, for most (if not all) of you, this is your first exam ever in computer science; taking an exam in a brand-new subject doesn't happen very often! Use this first and foremost as a "litmus test" of sorts to see how you are doing midway through the class, what you are understanding well, and what you can improve in future homework assignments and on the final exam. Remember that computer science is not an easy endeavor, even for experienced computer scientists.
Written by Nick Troccoli. Updated by Ashley Taylor