Assessment 1. Mid-Quarter Diagnostic

Congrats on completing your midquarter diagnostic! Go to Gradescope to review your submission and see our grading feedback and the scoring rubric. Here are the diagnostic solutions.

Motivation

The CS106B mid-quarter diagnostic is intended to gauge your comfort and facility with the course material so far. Since the course topics build on each other, confirming you have a solid grasp of the foundational material now ensures you are equipped to tackle the later concepts to come in the course.

We provide the diagnostic as a tool to take stock of where you're at and see how much you've learned in the first half of the course, as well as what work you have left to do. After taking the diagnostic and receiving your grading feedback, you will have the opportunity to meet 1-on-1 with your section leader to review your results, celebrate your successes, identify areas for growth, and chart your path forward through the rest of the quarter. Although the primary goal of the diagnostic is to provide feedback to you, it also contributes a small but meaningful contribution to your course grade (15%), which we hope will inspire you to use this checkpoint opportunity wisely.

Logistics

  • The "Diagnostic Administration Window" is the 48-hour period that starts Wednesday, October 21 12:01am PDT and ends Thursday, October 22 11:59pm PDT. All students must download and complete the diagnostic during the window.
  • We will target the diagnostic for a completion time of 90-120 minutes, but students will be allowed to work up to 3 hours if they so choose. This decision is to eliminate time pressure on you when completing the diagnostic.
    • Students with OAE accommodations will receive extended time to complete the diagnostic pursuant to their specific arrangements. More details will be sent out via email to the students for whom this information is relevant.
  • You may choose any 3-hour time period that is entirely contained within the Diagnostic Window during which to take the diagnostic. You do not have to communicate your planned schedule to us. Our tools automatically monitor the time you download and when you submit. Your submission must be received no later than 3 hours after you have downloaded the diagnostic. Late submissions cannot be accepted.
  • The diagnostic will be distributed and administered using a digital exam tool called Bluebook. Read more about configuring and using Bluebook below.
  • The Stanford Honor Code applies to the diagnostic. It is open-note, open-book, and open-internet. You must not discuss or seek help from other human beings. Read below for further details on the Honor Code.

Honor Code

We expect you to uphold your obligations to the Stanford Honor Code whe completing the work, just as with all coursework.

  • You must not give or receive unpermitted aid of any form.
  • The work you submit must be your independent, original work; not jointly developed nor derived from the work of another.
  • You are not to discuss the content with any other person (except for private, individual communication with the course staff to ask for clarification). This restriction applies while completing your own work and afterwards up until the Diagnostic Window closes for all.
  • The prohibition against sharing or discussing with others applies to the content in any form (no verbal description, problem text, solution diagrams or code, and so on) and through any communication channel (no private conversation, group chat, email, Ed post, internet question/answer forum, etc.)

Here is a non-exhaustive list of what resources are permitted and not:

  • Permitted
    • You may access the textbook and other books in printed or digital form
    • You may look at any materials on the course website (lecture slides, section problems, practice materials, etc.), read previous conversations on our Ed forum, and review your own assignment code on Paperless
    • You may use Qt Creator or Ed to run code samples
    • You may search online to find resource material related to course content
    • You may make a private post on Ed to ask a clarifying question about the diagnostic content
  • Not Permitted
    • You must not make a public post on Ed discussing any diagnostic content
    • You must not post content from the diagnostic on any online site or seek help from a forum such as Stack Overflow
    • You must not discuss the diagnostic content with any person (other than the course staff) during the entire diagnostic window
    • You must not share your solution code with other students nor ask other students to share their solution code with you

Reflection and Check-in Meeting

The final part of the mid-quarter diagnostic process is an optional reflection and check-in with your section leader. We plan to grade the diagnostic during the weekend after the window closes and will release grades shortly thereafter. After you receive your grading feedback, you will be invited to sign up for a one-on-one meeting with your section leader to reflect on your experience taking the diagnostic and your personal learning goals for the rest of the course. These check-in meetings are optional, but strongly recommended. In order to encourage your engagement in this process, we offer the following incentive:

  • If you schedule a check-in with your SL and come prepared with sincere reflection on your situation and engage in thoughtful discussion of your future plans, we will bump up your diagnostic score to earn back a third of the points you lost. If your original score was 85%, your adjusted score is upped to 90%.
  • If you choose not to take part, your diagnostic score is unchanged. CS106B does not generally apply much, if any, of a curve to scores on the exams/assessments, but if we were to feel it necessary, any curve would be computed on the raw, unadjusted scores, meaning there is no penalty if you decline to participate.

Configuring and using Bluebook

All students should download the BlueBook software and do a trial run on the sample well in advance of the actual diagnostic to confirm all will go smoothly when needed. Reach out to the course staff to resolve technical issues without delay!

  • Here are the instructions on installation and use of Bluebook.
    • BlueBook runs on Windows, macOS, and Linux computers. If you do not have one of these computers (e.g. a Chromebook), please let the course staff know as soon as possible.
  • The Bluebook application is used in conjunction with a data file provided by your course. Below we have the sample diagnostic problems supplied in the form of a Bluebook data file. The password to open the sample is practice
  • For the actual diagnostic, you will receive the Bluebook data file from a distribution portal linked on the course website. After you authenticate, the portal provides the Bluebook file to download and the password to unlock it.
  • BlueBook was designed for closed-note exams and the splash screen asks you to submit to the closed-resource requirements, including not accessing the internet or other applications. We will not be restricting access to those resources, but you must check those boxes anyway.
  • All answers and code are typed directly in the Bluebook application. The Bluebook software monitors the time remaining as you work. At the end of the time period (or when you are satisfied with your answers), use the submit feature in Bluebook to submit your work for grading.
  • To submit, you will need internet access and your 2-factor authentication device. Do not close Bluebook until you get a confirmation code saying that your work has been successfully uploaded. If the upload fails, please reach out to a member of the course staff (Chris, Julie, Chase or Nick). All of your work is stored on your computer, and we can access it manually if necessary.

Problem content and practice materials

  • Coverage. The diagnostic content covers the first four weeks of the course. The last included lecture is Friday, October 9 (Recursive Backtracking Part 2) and all material from Sections 1 to 3 and Assignments 1 to 4 is fair game.
  • Format. Most questions will ask you to write a function or short passage of code that accomplishes a particular task. Other questions may ask you to read a provided passage of code and analyze or reason about its behavior. There may also be short answer questions to answer in prose. The practice problems (below) contain example problems of various formats.
  • Practice problems. This set of practice problems was gathered from previous quarters as a model for the scope and content of problems that might appear on the diagnostic.
    • Here are the same practice problems packaged for a trial run in Bluebook. Download the Bluebook sample practice file.
      • If this link takes you to a page full of jibberish but does not download the file, just right-click somewhere on the page and select the "Save As…" option to save the contents of the page as a file on your computer.
      • The password to unlock the Bluebook practice file is practice.
    • We recommend working through the practice problems in an approximation of the real thing (set aside a block of time, gather the resources you plan to have on hand, and do a trial run entering your answers into BlueBook).
      • Note: If you have entered your answers into Bluebook and want to compare them to the practice solution, be sure to do this comparison before before closing Bluebook. Once you close Bluebook, your answers are considered locked and you will not be able to access them again.
  • Further practice.
    • Revisit our section materials. We pack the section handouts with way more problems that fit in a 50-minute section, so there is lots of good stuff for further practice. Section problems are similar size and scope to those on exams, in fact, many section problems originally appeared as exam problems.
    • The exercises in the textbook are another great source of practice problems.

Strategies

Assessments in a programming course can seem intimidating. How can you be sure the skills you are building on assignments will translate well to this new setting? We offer some sage advice based on our past experience.

Approaching an online exam

The exams in our coding courses have traditionally been administered on paper or closed-to-Bluebook. We have found this to be the best format to assess your ability to think logically and use appropriate problem-solving techniques without getting tangled in the requirements to please an actual compiler. Unlike a compiler, our grading process can look beyond nit-picky details and evaluate the correctness of your problem-solving approach. For this reason, Bluebook does not compile or execute your code to avoid these issues becoming a distraction.

When the exam is given in an online format, you are able to switch to Qt and use it to compile and run your code, we generally do not recommend it. It is easy to lose time fussing with details of syntax or rathole into an exploration to fix an edge case that was totally minor in the bigger picture. We think you are best served by writing a solid answer on paper and moving on. If you have leftover time at the end to double-check your work, consider using the compiler then.

Before the diagnostic

"Open resources" doesn't mean "Don't prep." The diagnostic is open-resource, and you can refer to lecture slides, the textbook, section problems, your assignment code, and so on. We don’t expect you to memorize minute details, and grading will not focus on them. However, this doesn’t mean you shouldn’t prepare. There won't be time during the diagnostic to learn material that you haven't already. To do well, you must be experienced at working through problems without needing to repeatedly refer to your resources.

Practice in simulated conditions. A good way to study for the programming problems is to take a problem (from lecture, section, textbook) and write out your solution under test-like conditions. This is much more valuable than a passive review of the problem and its solution, when it becomes 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 answered. 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.

During the diagnostic

Scan all the problems first. 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 one answer while 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 may require less code, which takes less time and provides 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 when we attempt to give partial credit.

Pay attention to specific instructions. A problem statement may include detailed constraints and hints. These constraints are not intended to make things difficult; typically, we are trying to guide you in the direction of a more straightforward 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 semicolons 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 loop followed by two lines with no curly braces, where both lines are vaguely indented or a third line has been added in after the fact, we may be confused about what code is really inside your for loop.

Save a little time for checking your work. Before submitting your diagnostic, reserve a few minutes to go back over your work. Check for matching parameter names passed into 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.

Miscellaneous Resources

Final Thoughts

Always remember why you are here! Your efforts to build practice skills and real understanding will take you a lot further than a pristine transcript. If you work hard toward mastery 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 course.