Assessment 1. Midterm Exam

Exam Download files

Please click here to access the exam file download page

Motivation

The CS106B midterm exam 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 exam 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 (10%), which we hope will inspire you to use this checkpoint opportunity wisely.

Logistics

  • The midterm exam will be on Thursday, April 28th from 7-9PM. Here are the room assignments:
    • If your last name falls between Adeyinka-Levine, inclusive, you'll take the exam in Hewlett 200
    • If your last name falls between Lewis-Zou, inclusive, you'll take the exam in Cemex Auditorium
    • 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.
    • Students who have requested an alternate exam time will receive information on the details of that via email in the coming days.
  • The diagnostic will be taken using Bluebook.
    • On Bluebook, you can write code but you won't be able to compile your programs. It's like a hand-written exam, but for coding questions.
  • The exam is closed internet, closed note. You can bring a two-page cheat sheet with notes. Note that this is 2 individual pieces of paper, 4 total sides of notes allowed.

Review session

Some of our wonderful section leaders will be hosting a midterm review session on Saturday, April 23rd from 2-3:30PM in Hewlett 200. This will be a great time to review content and ask questions. See this Ed post for more information!

Topic coverage and practice materials

  • Coverage. The midterm covers content up to, and including, lecture 10 Procedural Recursion which was on April 18th. All material from sections 1 to 3 and assignments 1 to 3 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. We have provided three examples to look at and to study from. The first example is a BlueBook exam, which you should test out on your computer so you are certain that you have BlueBook working correctly. When you click on the "Bluebook practice exam #1" link below, you will download a .json file, which you need to open up in BlueBook, with the password practice.
  • 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.

Before the diagnostic

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. Since you can't compile code on Bluebook, 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

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. If you attend your check-in and come prepared with genuine reflections on the first half of the course, you will earn a small number of bonus points on the midterm.

Final Thoughts

✨We want you to do well on this exam.✨

See this as an opportunity to show what you've learned and display your great efforts in the class so far. 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.