The CS 106A Final Diagnostic is intended as a way for you to demonstrate that you are a proficient programmer in Python
at the end of the course.
The diagnostic is scheduled to take place on Wednesday, August 5th at
10:30am PDT, and will cover material up to and including the lecture on July 28th.
The diagnostic will be 90 minutes long and you can consult
any materials (although we'll discuss this more in th strategy section
of this handout), and will be administered digitally using BlueBook.
If you have conflicts with the diagnostic timing or OAE accommodations, please contact Wil
as soon as possible.
Please make sure to download and install BlueBook on your laptop before the diagnostic.
Download links--as well as a guide to using BlueBook--can be found
BlueBook was designed for closed-note exams, and so the splash screen asks you to not access the internet
or other applications. We are not enforcing this this quarter but you should check the box anyway.
Additionally, the honor code requires that the solutions you produce are your own. You're welcome
to use any external resources you want, but you should not be copying preexisting solutions on
the internet. BlueBook does not allow you to copy and paste into or out of the application
to ensure your solutions are your own.
A practice diagnostic that can be run on BlueBook can be downloaded below.
This practice will be run under timed conditions, and give you an idea of what
to expect for the actual diagnostic.
Should you run into any technical issues, shoot Chris an email at
Note: BlueBook runs on Windows, macOS and Linux computers. If you do not have
one of these computers (e.g. a Chromebook) instead, please let Chris or Wil know
as soon as possible.
Note: We unfortunately currently don't have a way for students to access their own submissions
from the BlueBook practice. If you'd like to compare your answers to the posted solutions, please
make sure to copy, save, or otherwise keep your answers before submitting. Apologies for some of the growing
pains as we develop all of the functionality of our new electronic system!
Assessments in the CS106 courses can be challenging. 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 timed diagnostic setting. The practice
diagnostic gives an idea of what to expect and this handout gives some sage advice gathered from our current and past staff
members. We hope you will find our tips useful! Remember: We are assessing your ability to think logically and use
appropriate problem-solving techniques. We expect you to express yourself in reasonably correct Python, but we will be
quite lenient with errors that are syntactic rather than conceptual.
Electronic assessments hold several advantages. For students, writing code on a computer (with syntax highlighting, undo, cut,
etc) is a much easier experience than writing solutions out by hand. The way in which you are assessed is much
closer to the way in which you program. On our end, it makes it a lot easier to make, distribute and grade
assessments. Instead of using the 16,000 pages of paper that CS106A typically consumes each year, we use 0. Finally, grading
hand written answers is hard and inaccurate. Hand written answers allow for bias in teachers grading and are inaccurate
because we can’t run your programs. Your diagnostic will still be assessed by a human, but they will be better equipped to
understand what you were trying to do.
Yes, but in a time-restricted situation, immediate feedback can sometimes be more of an impediment than an
advantage. Imagine this, you read the first problem, have a good idea how to solve it, write your solution, and trace
its operation and feel good. You compile and test it. Suppose it exhibits a bug—even though it may only be a minor issue,
you can see your answer is wrong—so you hunker down and rework and retest until perfect... even if it takes the whole time.
Bad deal – since you never got to the other problems! We want you to write your best answer and move on.
The diagnostic is open-book/open-notes and you can refer to
slides, the Karel reader, your notes from lecture, course handouts, and your assignments. We don’t
expect you to memorize minute details and the diagnostic will not focus on them. However, this doesn’t mean you shouldn’t
prepare. There certainly isn’t enough time during the diagnostic to learn the material. To do well, you must be experienced
at working problems efficiently and accurately without needing to repeatedly refer to your resources.
A good way to study for the programming problems is to take a problem
(lecture or section problem, sample diagnostic problem) and write out your solution under test-like conditions.
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 diagnostic when there is no provided solution
to guide you!
If there is a concept you’re a bit fuzzy on, or you’d like to check your
answer to a chapter exercise, or you wonder why a solution is written a particular way, get those questions answered
before the diagnostic. Swing by the LaIR, come to office hours, or post on Ed and we’re happy to help.
Quickly peruse all questions before starting on any one. This allows you to “multitask”—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.
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 to one leaving others untouched.
Unlike the assignments where we hold you to high standards in all areas, for a diagnostic, the correctness of the answers
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.
A problem statement may include detailed constraints and hints such as “Karel must end up facing East.”
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
We won’t trouble you about most small syntax errors (forgetting colons or spaces, for example) as long as your
intentions are clear. Having said that, beware 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, we may be confused.
Before handing in your exam, reserve a few minutes to go back over your work. Check for missing 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 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—regardless of how many points you get relative to the other students in the class.
© Stanford 2020 | CS106A has been developed over decades by many talented teachers. Website designed by