Final Exam Information

Written by Chris Gregg, Nick Troccoli, Jerry Cain and Lisa Yan, based on documents by Julie Zelenski and others

Date/Time:

Tuesday, March 15th, 8:30AM-11:30AM PST

Locations:

Last names beginning with A-L: Bishop Auditorium
Last names beginning with M-Z: 320-105

If you have academic accommodations, e.g. through OAE or athletics, or if you do not have a workable laptop for the exam, please let us know by Friday March 11th @5PM PST. Limited charging outlets will be available during the exam.

Overview

The final exam will be held during our registrar-scheduled exam time: Tuesday, March 15th, 8:30AM-11:30AM PST. For the final exam, there will be no alternate time, except for those with relevant official university athletics or Office of Accessible Education accommodations, so please make sure that you can attend the final exam at the specified time before enrolling in the class.

The exams are designed to assess your mastery of the course learning objectives, with a particular emphasis on material that was prominent in the lectures, assignments and labs.

The exam is closed-book. You may bring a double-sided US-Letter-sized (8.5"x11") page of your own prepared notes. The exam will include a reference sheet of essential details such as prototypes for standard library functions (e.g., strcpy, strlen, malloc), as well as an additional reference sheet with the common x86-64 assembly instructions.

You will take your exam electronically, using the same exam system we used for the midterm. You cannot access digital notes, run other applications (such as Terminal or other myth SSH tools), use other Internet websites, nor use any other electronic devices during the exam.

Please make sure to thoroughly read all information contained on this page to ensure you understand the midterm logistics, requirements and restrictions.

Logistics

Course staff will be proctors at the exam to answer clarification questions.

You will take your exam electronically, using the same online system we used for the midterm. You cannot access digital notes, run other applications (such as Terminal or other myth SSH tools), use other Internet websites, nor use any other electronic devices during the exam.

The exam is strictly individual work.

During the exam, you may use/reference:

a double-sided US-Letter-sized (8.5"x11") page of your own prepared notes.
a provided reference of essential details such as prototypes for standard library functions (e.g., strcpy, strlen, malloc) and common x86-64 assembly instructions. This is included in the exam.
provided blank scratch paper (we will provide this at the exam)

You are not permitted to use any other materials, such as printouts (notes, slides, code, practice exams, etc.), other textbooks, or electronic devices (iPads, Kindles, calculators, music players, etc.) other than using your computer to view the Gradescope website. You must not use any other program or function (such as a calculator) on your computer other than a web browser, and you must not use a web browser for any other task other than taking the exam via the Gradescope website. The web software we are using will be able to detect if you go to another web page or application on your computer.

The exam may be a mix of short answer, multiple choice, code reading, code writing, etc. questions.

Material Covered

The final is intended to assess your understanding of the content covered throughout the course. The priority is on material that figured prominently in the assignments, labs, lecture, and reading (this list is in order of decreasing emphasis). The topic coverage for the final exam will be comprehensive and span the entire quarter, but expect more emphasis on material covered after the midterm (i.e. >= lab4 and assign4, since assign4 was only lightly covered on the midterm). The ethics material introduced by Katie Creel, and the extra lecture on floats, will not be tested on the exam.

We highly recommend revisiting the labs and assignments. Each of them contain post-task self-check questions at the end that you can use to review. The K&R and B&O textbooks also contain many exercises if you want additional problems to work.

We'd love to see the discussion forum come alive in helping everyone do their best on the exam – this is a great place to ask and answer unresolved questions, discuss conceptual issues, share techniques and materials you are finding useful as preparation, and support and encourage each other.

Topics Summary

Check your rear-view mirror for the very impressive list of things you've learned in 107!

All about C and memory: C—strings, arrays, pointers, void*, pointer arithmetic, typecasts, function pointers, generics, stack and heap
Data representation: bits, bytes, ASCII, two's complement integers, pointers, aggregate types (arrays and structs)
x86-64 assembly: data access and addressing modes, arithmetic and logical ops, implementation of C control structures, call/return
Address space: layout and purpose of text/data/stack/heap segments, handling of different variable scopes/types
Runtime stack: caller/callee protocol, parameter passing, use of registers
Memory and heap: stack versus heap allocation, heap allocator strategies and tradeoffs
Performance: compiler optimizations, profiling

What To Bring

The exam is on your computer. You should bring:

Your laptop and charger
The device you use for two-step authentication
your physical double-sided page of notes
A power strip/extension cord (optional, but recommended if you have access to one)

Honor Code

The exam is to be completed individually and without any assistance from a partner or other students. Follow the Stanford Honor Code (see link on main course homepage) during the exam: submit only your own work, do not use unpermitted aids on the exam, and say something to the instructors or students in question to prevent any inappropriate activity conducted by others surrounding the exam.

Grading

(Same as midterm exam) For coding questions, the majority of the points are typically focused on the correctness of the code. However, there may be deductions for code that is roundabout, awkward or inefficient when more appropriate alternatives exist. We will reward the simple, direct approach for its good design decisions and such code will likely have fewer correctness issues, so the choice of appropriate design can have a large impact. For example, we expect you to leverage appropriate features from the standard libraries; re-implementing that functionality wastes your valuable time and introduces opportunity for error.

Note that certain problems may have certain constraints (such as only using certain material, etc.) that you must follow to earn full credit. 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. We reserve the right to deduct points for extremely inelegant or inefficient code that dodges the spirit of the problem.

Pseudo-code (writing English sentences and phrases instead of code) will typically earn little to no points. For example, writing "In this part of the code, I want to open the file and read each line and print it" will not earn any points.
You should include your answer, as well as any scratchwork, in the text area for each problem. An answer to a problem not in the designated answer pages for that problem will not receive any credit.
Unless otherwise specified, it is fine to write helper functions to implement the required behavior.
Style and decomposition are secondary to correctness. Unlike the assignments where we hold you to high standards in all areas, for an exam, 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.
We are lenient on syntax. 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 (e.g. very unclear curly braces), we might not get the correct meaning. Additionally, there are subtleties that matter immensely, e.g., a int** is just one character different than int*, yet there is a world of difference between the two!
The majority of the points for a problem will be reserved for grading the critical core of the code. For example, if we ask you to write a function that processes a generic array, only a tiny fraction of the points will be allocated to tasks such as initializing the counter or iterating over the right bounds, while the bulk of the points will be gained or lost in the tricky details of whether you correctly handle the void*s. Being off-by-one in the loop is a tiny deduction, but being a level of indirection off or applying the wrong cast is a larger issue. Be sure to focus your attention accordingly!

Downloads

Exam Reference Sheets: Note: the reference sheets are included in the exam. You will be provided with hard copies as well during the exam.

C Reference Sheet Webpage | C Reference Sheet PDF
(This is the same reference sheet as on the midterm exam)

Assembly Reference Sheet (This is the same assembly reference sheet we have used in class and labs)

Practice Materials:

Note: some of the exams include questions covering floats, which is not included this quarter on our final exam topics.

Practice Exam 1: PDF | Solutions
This is based on the final exam from CS107 Winter 2018. It was written as a 180 minute BlueBook (electronic) exam (same length as this quarter).

Practice Exam 2: PDF | Solutions
This is based on the final exam from CS107 Fall 2017. It was written as a 180 minute paper exam (same length as this quarter, except not electronic).

Practice Exam 3: PDF | Solutions
This is based on the final exam from CS107 Fall 2018. It was written as a 180 minute paper exam (same length as this quarter, except not electronic).

Extra Practice Problems: PDF | Solutions

Exam Strategies

For the exams, answering the questions is typically going to require good comprehension of the foundational concepts and the ability to analyze and apply them in a given situation. We are evaluating that not only did you successfully complete the assignments and labs, but that you came away with a comprehension you can demonstrate. We generally do not ask details that can/should be looked up on demand ("How do you printf a number in hexadecimal number padded to 8 digits?"). Many questions will ask you to write short passages of C code. Other questions may ask you to analyze C code: to trace its behavior, to compare or contrast two versions, identify and fix flaws, or describe a memory layout. Others may ask you short questions about material or code. There may also be short-answer thought questions that ask you to reason about system behavior, coding tasks, numeric representation and limitations, performance tradeoffs, and the like.

Before the exam

The long view. The mastery we are looking to assess with the exams isn't created by a night of cramming, it is built up throughout the quarter. Make it a priority to monitor your own progress and use our post-task self-checks listed at the end of each lab/assignment to identify holes or confusion to be shored up before moving on. In the ideal situation, you have established solid understanding of the material and the only exam preparation needed is practice applying your skills under exam-like conditions.

Make your notes sheet as part of exam prep. Reviewing topics and determining what information is worth including on your reference page(s) will remind you of where we've been and help you take stock of your comfort level with the course topics. Use this opportunity to identify any areas on which you feel weak and resolve dangling issues before heading into the exam.

Practice in simulated conditions. A good way to study for the programming problems is to take a problem (from lecture, lab, 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 exam 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 exam. Swing by Helper Hours or post on the discussion forum; we’re happy to help!

During the exam

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. Don't get stuck on any particular problem. You'll earn more points from reasonable efforts across all problems than by perfecting one answer at the cost of leaving others blank. Take into account the point value assigned to each question when budgeting your time. Be conscious of which details are worth slowing down to get it right (e.g. allocating memory, getting the right typecast, correct pointer math, and so on) and which tasks can do with just a quick first draft (e.g. an off-by-one loop index or forgetting to initialize a counter).

Ask a question rather than answer the wrong one. If you are uncertain about what a question is asking or find some part of the question ambiguous, it's worth your time to ask the course staff for a clarification so you can be sure you are solving the right problem before you start working on it.

Pay attention to specific instructions. A problem statement may include detailed constraints and hints such as "use only bitwise operators" or "ignore the case when the string is empty" or "must run in constant time". You may want to highlight these instructions to be sure you don't overlook them. 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.

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.

The kind of systems coding we do in CS107 leaves much room for error, spanning the gamut from oversights such as forgetting to return the function result to more serious omissions such as failing to allocate memory for a pointer. Nearly everyone loses a few points that could have been avoided with more time and a chance to execute/test the code. However, a solid first-pass approximation that shows the correct conceptual understanding of the key issues will earn the bulk of the points and, in our analysis, deserves to be strongly distinguished from code that exhibits significant conceptual issues and would require much trial-and-error with compiler/debugger/Valgrind to turn into working code.

More broadly, the ability to analyze and reason about code in isolation is a valuable skill for any computer scientist. It forces you to think before you code, rather than leaning too much on the tools. At every step, you want to ensure that you understand the code you are writing, what it does, and how it works

After the exam

For most students, the assignment and exam performance are fairly well correlated but sometimes they do diverge a bit. It's pretty rare to rock the exam if your assignments didn't go well, but there are students who go into the exam with solid assignment scores and yet emerge with a disappointing outcome. What might explain this and what can you do about it?

Make sure you are mastering the material while completing the assignments. You should not complete assignments using trial or error techniques, make a change if you don't understand its implications, or only make modifications that the course staff tells you to. Even though you may get through the assignments, you won't be able to reproduce these results in an exam setting. The goal of an assignment is not to get the program to work, one way or another, it is about developing an understanding of how and why it works, and being able to take that understanding and write similar code in any environment, including one that doesn't have the luxury of a compiler/debugger/Valgrind/CA/sanitycheck to tell your whether the code is correct or not.

Gauge your comfort with the material. Did you feel like you spent a lot of time looking through your materials and clarifying concepts during the exam? Did you feel that the mistakes you made on the exam were just small oversights, or more conceptual? Use the exam results to answer these questions about your understanding of the material and use them to prepare even better for next time.

Ensure comfort in the testing environment. If you feel that one of the reasons behind how you did on the exam was lack of comfort in the testing environment (no tools, time limits, etc.), make sure to practice more in test-like conditions. Review your exam, introspect on what happened, brainstorm tactics for next time, and do some practice.