Assessment 1. Midterm Diagnostic

Motivation

The midterm diagnostic is intended to gauge your comfort and facility with the content from the first half of the course. Since the course topics build on each other, confirming you have a good grasp of the foundations and/or identifying which gaps to shore up now puts you on a solid path to be ready for what comes next.

After receiving your grading feedback, you are invited to request a one-on-one meeting 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.

Logistics

• The Testing Window is the 24-hour period starting Tuesday, October 26 5pm PT and ending Wednesday October 27 5pm PT.
  • All students must complete the diagnostic within the Testing Window without exception.
• We design the diagnostic for a completion time of roughly 90 minutes, but you may work up to 3 hours if you so choose.
  • We made this decision to lessen the effect of time pressure. We know that exams are stressful enough already!
  • Students registered with OAE will receive extended time pursuant to their accommodations. Students for whom this information is relevant will receive an email from us with more details.
• You may choose to take the diagnostic in any 3-hour block that is entirely contained within the Testing Window.
  • You do not have to communicate your planned schedule to us.
  • Gradescope will automatically monitor the time you start and when you submit.
  • Your submission must be received no later than 3 hours after your start.
  • Late submissions will not be accepted.
• The diagnostic will be completed online using the Gradescope website.
  • We have posted the sample version of the diagnostic on Gradescope .
  • Use this sample as a "dry run" to become familiar with the delivery format and confirm you can successfully follow the process end to end.
  • You will need a stable and reliable internet connection for the duration of the period you plan to take the diagnostic.
  • If you run into any snags with using Gradescope, please reach out to us for help. Please do this as soon as possible, preferably well in advance of the opening of the Testing Window, so there is sufficient time to resolve any issues.
• The diagnostic is open-book/note and closed-human.
  • Open-book/note means it is permitted to consult inanimate resources.
  • Closed-human means it is not permitted to communicate with any other humans (other than private communication to course staff to request clarification).
• All students are bound to uphold their obligations to the Stanford Honor Code.

Honor Code

The Honor Code as it applies to the diagnostic:

• You must not give nor receive unpermitted aid of any form.
• All of the answers you submit must be your independent, original work; not jointly developed nor derived from the work of another.
• You are not permitted to discuss, share, or solicit any information whatsoever about the diagnostic in any public or private communication channel.
  • The prohibition applies during the entirety of the Testing Window.
  • The prohibition applies to communication in any form (no verbal description, no problem text, no diagrams, no code, and so on) and in any communication channel (no verbal/text conversation, no group chat, no email, no Ed post, no internet question/answer forum, etc.)

Here is a non-exhaustive list of what is permitted and what is 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 posts on the course Ed forum, and review your own assignment code on Paperless
• You may look at reference materials available on the web (C++ language, documentation for standard and Stanford libraries, etc.)
• You may use Qt Creator or Ed to run code samples
• You may make a private post on Ed to ask the staff a clarifying question about the diagnostic content

Not Permitted
Some example behaviors that would constitute a violation of the Honor Code

• exchanging or collaborating on answers with others (unpermitted aid)
• copying solutions you did not write yourself, such as answers from other students or answers found online, and submitting as your own work (plagiarism)
• soliciting or sharing information about the diagnostic at any point during the Testing Window (unpermitted communication)
• any attempt to gain unfair advantage or circumvent security protocols, e.g. manipulating/hacking the Gradescope site (Fundamental Standard violation)

Coverage, sample/practice materials

• Coverage. The diagnostic will cover material from the start of the quarter through recursive backtracking. This means all content up through and including Lecture 13 (Mon 10/18), Section 4, and Assignment 4.
• 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 sample shows examples of various problem formats.
• Sample. We have prepared a sample diagnostic on Gradescope. This sample should be fairly representative in scope, content, and difficulty to what you can expect on the actual diagnostic.
  • We strongly recommend that you practice on the sample as if it were the real thing (set aside a block of time, gather the resources you plan to have on hand, and do a trial run using Gradescope).
• Further practice exercises
  • Revisit our section materials. We pack each weekly section handout with many more exercises that fit in the section meeting, so there are plenty of good options there. Section exercises are similar size and scope to those we use for exams (in fact, many section exercises originally appeared on exams in previous quarters).
  • The exercises in the textbook are another great source for practice.
  • The online coding practice site Code Step By Step has been recommended by past students as a useful tool. It offers many practice problems and autogrades your answers to give immediate feedback.
  • Our fabulous Head TA Neel will lead a review session on Sunday afternoon 10/14. See this Ed post for more info.

Strategies

Assessments in a programming course can seem intimidating. The assignments we receive from you have demonstrated that you are doing great in the live environment and have the testing and debugging chops to see through programs to working completion. Your prep for the assessment is to practice how you can show those same problem-solving skills in "on paper" short-form question-and-answer format. Here is some sage advice gathered from the collective wisdom of our section leaders about how to prep, practice, and triumph in this format!

Why not to build/run the code

The intent of our assessments is to assess your ability to think logically and apply problem-solving skills to reading and writing code. If you were facing an actual compiler, there would also be a multitude of tiny syntax nits, typos and mundane build issues you would have to overcome to turn the code into reality. In your assignments, you have already shown us many times over that you can work through these issues, and we do not wish to further assess these skills.

Bear in mind that the diagnostic will be scored by our very capable human section leaders, not inflexible compilers! We look beyond the nit-picky details to evaluate the heart of your problem-solving approach and its correctness. Although you could put your code into Qt Creator and try to compile and run it, we do not recommend this. We have seen many a student write a great first draft with code that is right on track for answering the question, yet when trying that code with a compiler, it hits a build issue or running it surfaces a mishandled fringe case. The actual problem is minor, perhaps even entirely unscored, yet the student falls into a rathole trying to fix the issue out of misguided sense of its importance. This timesink causes them to lose time to work on other problems. Running your code is is no way necessary to be successful on the diagnostic, and in fact, we think it can be a detriment.

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 in advance. 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, the correctness of the answers dominates the grading for exams. 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 your job difficult; typically, we are trying to guide you in the direction of the most 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 which lines are really inside the loop.

Save a little time for checking your work. Before submitting, 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

• Syntax Reference Sheet
• Advice from Keith Schwarz about coding without an IDE
• Advice from Julie Zelenski about coding exams

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 you can be proud of!