Final Exam Logistics

Exam Timing and Format

The CS106B final exam is coming up soon. It’s a take-home coding exam. The exam will go out on Friday, March 11th at 10:30AM, and it will come due on Monday, March 11th at 10:30AM (Pacific time). The format is different than that of the midterm exam. You may start the exam at any point in time during the 72-hour window when it's released. However, once you begin the exam, you must complete it and submit your answers within six hours. Accordingly, you should find a six-hour window during which you're comfortable taking the exam.

We've chosen this format to strike a balance between giving you flexibility with when you take the exam and ensuring you don't spend too much time on it. In terms of flexibility, a six-hour clock gives you time to read over the problems, go for a walk or bike ride, get a meal, then sit down to work through things. At the same time, you'll also know once you start the exam that there's a definitive endpoint to the exam.

Like the midterm, we'll provide a set of starter files and you'll be able to use Qt Creator to run, test, and develop your code. However, unlike the midterm exam, you'll submit your exam on Gradescope rather than on Paperless. We're using Gradescope here because it has the tooling to enforce the time limit. We'll release more information about how to submit to Gradescope later on.

In terms of topic coverage, the final exam is a cumulative exam that covers all the course topics. However, it's primarily focused on

• Lecture 11 – Lecture 27 (big-O notation and onward, and
• Assignment 4 – Assignment 9.

You are responsible for the material from lectures and from the assignments, so you should be prepared to answer questions about topics that came up purely on the coding assignments (say, using the debugger, binary heaps, etc.). We will not test you on anything that appears purely in the section handouts or purely in the textbook, though those are excellent resources when studying.

Our Exam Philosophy

We want you to do well on this exam. To be very explicit about our exam philosophy:

• We're not trying to weed out weak students.
• We're not trying to enforce a curve where there isn't one.
• We’re not trying to measure “coding potential” or “innate programming ability.”

Rather, we want you to show what you've learned up so that you get a sense for where you stand and where you can improve. The exam format is basically the same as the coding assignments, with the exception that you’ll be doing everything individually, without help from the course staff or other students, and with a six-hour clock.

Honor Code Policies

You are required to abide by the Honor Code policies outlined in our Honor Code Policies. We’d like to call particular attention to the following rules.

This exam must be completed individually. It is a violation of the Stanford Honor Code to communicate with any other humans about the exam, to solicit solutions to this exam, or to share your solutions with others . This exam is open-book, so you are free to make use of all course materials on the course website and in the textbook. You are also permitted to search online for conceptual information (for example, by visiting Wikipedia). However, you are not permitted to communicate with other humans about the exam or to solicit help from others. For example, you must not communicate with other students in the course about the exam, and you must not ask questions on sites like Chegg or Stack Overflow. (You may ask questions to the course staff on Ed; if you do, you must post your questions privately. See below for details.)

All work done with the assistance of any material in any way (other than provided CS106B course materials) must include a detailed citation (e.g., “I visited the Wikipedia page for X on Problem 1 and made use of insights A, B, and C”). Copying solutions is never acceptable, even with a citation, and is always a violation of the Honor Code. If by chance you encounter solutions to a problem, navigate away from that page before you feel tempted to copy.

If you become aware of any Honor Code violations by any student in the class, your commitments under the Stanford Honor Code obligate you to inform course staff.

Getting Help

Because this is an exam, we will not be able to help out with coding or debugging questions the way that we normally do on the assignments. For example, we will not be able to help interpret compiler error messages, assist with C++ syntax, investigate crashes in your code, assist with debugging, etc. After all, part of the purpose of the exam is for you to demonstrate your ability to work through coding problems independently.

We can, however, answer a small set of questions about the exam problems, mostly clarifying questions about what the instructions mean or help getting the project files set up on your machine. To ask these sorts of questions, make a private post on EdStem. All questions about the exam must be posted privately, and you must not post any code on EdStem. We will periodically check EdStem between the hours of 9AM to 9PM Pacific time; questions asked outside that range might not be answered.

Preparing for the Exam

There are a number of ways that you can prepare for this upcoming exam. Here is our recommendation of what you should do to get into the best shape that you can.

1. Redo the assignments. When you’re first working on the assignments, you’re simultaneously trying to figure out what the assignment is asking you to do, solidifying your understanding of the content from lecture, tinkering around to see what happens, and figuring out the necessary problem-solving techniques. That’s fine, and that’s normal. What matters, though, is that, in that process, you internalized the appropriate techniques and developed your coding and problem-solving skills.

   If you have the time to do so, pick one or two of the most challenging programming questions we asked you to solve, download a fresh copy of the starter files, and solve the same problem again without referencing your overall solution. If you’re able to do so with a little trial and error, great! It means that you’ve gotten out of that assignment what we expected you to get out of that assignment. On the other hand, if you’re struggling on the assignment a second time, there’s a good chance that some key skill or technique hasn’t yet clicked for you, and it’s worth talking to your SL or stopping by the LaIR to talk through the ideas.

   If you worked with a partner, it’s doubly valuable to attempt the problems a second time on your own, just to make sure that you personally are comfortable taking on the questions and that you weren’t leaning too much on your partner for insights.

2. Work through practice problems. We’ve posted a collection of practice problems on the course website. It’s a compilation of old exam problems, which might give you a better sense of what sorts of questions we might ask.

   When you’re working through those problems, don’t just hand-write things and call it a day. Make sure that you actually got things working. So download a blank set of starter files from the course website, type up your solution, and try running it on some sample test cases. If things work, great! If not, try debugging your code and see if you can fix it. If you’re still stuck, no worries! That’s a great indicator that you should ping your SL or drop by the LaIR to get some help.

3. Work through the section problems. The problems we give out in the section handouts each week are a great way to practice specific skills. Want to sharpen your recursion skills? Look at Section Handout 3 or Section Handout 4. Want to shore up your C++ fundamentals? Look at Section Handout 1 and Section Handout 2.

4. Review IG feedback and make sure you understand it completely and unambiguously. We hold interactive grading sessions on the assignments for a good reason – it’s a chance for someone with more coding experience than you (your section leader) to offer their advice and insights about how you can do a better job in the future. If you haven’t yet done so, take some time to review the feedback you received. If there are suggestions of the form “try doing it this way next time,” take a few minutes and actually go do it the other way. If there are stylistic points that they’ve pointed out to you, great! Go patch up your code to meet those style guidelines.

   And hey, what should you do if you find something that you don’t understand? Ping your SL and ask for clarification!

5. Keep the SLs in the loop. As you're studying, please take the initiative to ask us questions when you have them. If you're not sure about how or why a certain piece of code works, or why a certain piece of code doesn't work, or why a certain concept works a certain way, etc., go on EdStem or stop by the LaIR and ask us a question. If you worked through any practice problems (section handouts or practice exams), ask your section leader to review your answers and offer polite but honest feedback on how you did and what you need to work on. You can also visit office hours if you’d like!

How We Grade

We’ll be grading the exam similarly to how we grade programming assignments. We’ll run your code on a variety of test cases (many of which we’ll have shared with you in the starter files) to determine what aspects of the code are working properly and which aspects need work, and we’ll review how you’ve structured your code to assign a style grade.

We do not assign points by counting how many tests you pass. Instead, we review your code, identify what works and what doesn’t, and assign a score based on your overall correctness and strategy. This means that if your code is mostly on the wrong track but coincidentally happens to pass most of the tests, we may assign a lower score than if your code is basically correct but has a tiny error that causes it to fail most of the tests. In other words, it’s always best to try to get the code working according to the best of your ability, rather than submitting something that you know is mostly incorrect but happens to pass a lot of the tests.

We will be grading for style along the lines of what we do on the assignments. After all, we hope that you’re internalizing our style recommendations and starting to write well-commented, clearly-decomposed code the first time around. In particular:

• Use descriptive variable and function names. Single-letter variable names (or worse, single-letter function names) make it significantly harder to understand your code.

• Properly indent your code. Remember that Qt Creator can auto-indent your code for you; highlight the code to indent and press Command+I or Ctrl+I (depending on your OS).

• Comment difficult parts of your code. More generally, comment your code the way you'd comment an assignment.

We want to be transparent about our grading philosophy for exams and our exam policies. Here's a quick rundown of some of the frequently asked questions about CS106B exams.

• Do you give partial credit? Yes, absolutely! Because the exam is open-resource, we generally do not award partial credit for answers that just consist of a lot of code copied from lecture, section handouts, etc. The best way to earn partial credit on the problem is to make a good effort to solve it, and to do so in a way that shows you understand the underlying methodology.

• Can I write more than one answer to a problem? No, please do not do this. If you put down multiple answers to a question, we will grade whichever answer gives you the fewest number of points. This policy is in place to prevent “shotgunning” down multiple answers with the hope that one of them will work.

• Is pseudocode okay? We generally discourage people from writing pseudocode on an exam. It is better to just write real C++ code, or to at least outline in C++ what you would be doing. You should not expect to receive much, if any, partial credit for writing pseudocode.

You can do this. Best of luck on the exam!