Diagnostic Date: Oct 7th, 2020
The CS 106A Diagnostic is intended as a way for us to identify early how comfortable you feel with course material thus far. Since the course material builds on itself, checking that you have a solid grasp of the early material is critical for making sure that you have the right scaffolding to assimilate other concepts that are learned later in the class.
The primary goal of each diagnostic is to provide feedback to you, but we want you to prepare for them and take them seriously, which is why each diagnostic is worth 10% of your grade. As we said in the general information handout, to pass the class you are required to make a real effort on and submit all the assignments, take the two diagnostic assessments, and attend/participate in section. We hope you'll take each diagnostic as an opportunity to see how much you've learned in the past few weeks, as well as what work you have left to do.
The first diagnostic is scheduled to take place on Wednesday, October 7th at 1:00pm PDT, and will cover material up to and including the lecture on October 2nd. The diagnostic will be 60 minutes long and you can consult any materials (although we'll discuss this more in th strategy section of this handout). The diagnostic will be administered digitally on a tool called BlueBook.
If you have conflicts with the diagnostic timing or OAE accommodations, please contact Juliette 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 here. BlueBook was designed for closed-internet 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 Juliette an email at jwoodrow@stanford.edu .
Note: BlueBook runs on Windows, macOS and Linux computers. If you do not have one of these computers (e.g. a Chromebook), please let Juliette 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.
Great, it's on a computer! Can I run my program?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.
Practice, practice, practiceA 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!
Get your questions answeredIf 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.
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 to one leaving others untouched.
Style and decomposition are secondary to correctness.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.
Pay attention to specific instructionsA 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 convoluted alternative.
Syntax is not that important if it is clear what you mean.
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.