Mid-Quarter Assessment Information

Written by Lisa Yan and Nick Troccoli, based on documents by Julie Zelenski, Nick Bowman and others

Assessment Window:

Wednesday May 5 at 1PM PT through Friday May 7 at 1PM PT

If you have academic accommodations, e.g. through OAE, and you have not already let us know, please let us know as soon as possible.

Post-Assessment: Solutions and Grades

View Solutions and Grading Info

(If you do not have permission to access this link, please email the course staff)

Overview

The mid-quarter assessment 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 assessment 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. 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!

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

Logistics

The assessment is open-book, open-note, and will be completed electronically via Gradescope, an online quiz-administration website. While you are able to access the myth machines during the assessment, the problems will be written with the intent that you not need to use the myth machines to complete them.

If you do not have access to the course on Gradescope (you should log in with your @stanford.edu email - if you don't have an account, try either logging in with Google or clicking "Forgot password" and entering your Stanford email), please email the course staff.

The "assessment window" is the 48-hour period that starts Wednesday May 5 at 1PM PT and ends Friday May 7 at 1PM PT. All students must complete the assessment during the window. We will target each assessment for a completion time of about 2 hours, but students will be allowed to work up to 3 hours if they so choose. This decision is to minimize time pressure on you when completing an assessment. You may choose any 3-hour time period that is entirely contained within an assessment window during which to take an assessment. You do not have to communicate your planned schedule to us. Gradescope automatically monitors the time you begin and when you submit. It also allows you to resubmit any time during the 3 hour allotted time. Late submissions cannot be accepted.

Unlike the assignments, the assessments are strictly individual work. Even course staff assistance will be limited to clarifying questions of the kind that might be allowed on a traditional, in-person exam.

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

If you have questions or issues during an assessment, please ask them as a private question (this feature will be temporarily enabled) via our discussion forum. You should not attend Helper Hours while you are taking the assessment, for any reason. Below is a list of times in PDT when the course staff will be actively monitoring the Ed discussion forum and can guarantee a response time of 15-20min. Outside of these times, we will do our best to monitor the forum but can't guarantee as quick responses. For that reason, we recommend you plan on taking the assessment during one of these times if you may need to ask any clarification questions.

Wed 1PM-12midnight
Thurs 8AM-12midnight
Fri 8AM-1PM

Once the assessment window starts, if you have not yet started the assessment, or if you have already finished the assessment, you may continue to take advantage of the discussion forum and helper hours as usual. We will be temporarily requiring staff approval before any public post becomes visible on the forum.

Gradescope allows just normal text input, and doesn't support syntax highlighting or other features that make writing code easier. For that reason, we recommend writing your code in an environment that provides syntax highlighting, and then copying your code into Gradescope when you're done. One easy option is CPlayground, a website that lets you write code in your browser. You can write your code there and copy it into Gradescope when you're done.

If you want to try out a Gradescope assessment, there is a "Practice Assessment" available on Gradescope you can take that is ungraded, just to give you a sense of what the interface and process is like.

Material Covered

The assessment is intended to assess your understanding of the content covered in the first half of the course. The coverage is through the topics relevant for lab4 and assign4 but not beyond (i.e., through generics, but the assessment will not cover assembly). However, because the generics assignment, assign4, is not due until after the assessment, the generics coverage on the assessment will be lighter and not as heavily emphasized as compared to the other topics which we have fully completed assignments for. The priority is on material that figured prominently in the assignments, labs, lecture, and reading (this list is in order of decreasing emphasis).

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 make the most of this opportunity to review what we've covered so far and rock the assessment – 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.

The Honor Code

The Honor Code policies are a critical part of the mid-quarter assessment (see the Honor Code and collaboration link on the main course homepage) and we expect you to uphold your obligations as for any other coursework. Here are the key principles:

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 Assessment 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, discussion forum 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, lab problems, practice materials, etc.), read previous conversations on our discussion forum, and review your own code on Myth
You may use the myth machines to run code, although we generally don't recommend spending your time doing this (see Assessment Strategies below)
You may search online to find resource material related to course content
You may make a private post on the discussion forum to ask a clarifying question about the assessment content

Not Permitted

You must not make a public post on the discussion forum discussing any assessment content
You must not post content from the assessment on any online site or seek help from a forum such as Stack Overflow
You must not discuss the assessment content with any person (other than the course staff) during the entire assessment window
You must not share your solution code with other students nor ask other students to share their solution code with you

Grading

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.

You are not required to write #include statements on the assessment. Please do not abbreviate any code on the assessment (such as writing "x2" next to code to copy it twice). Abbreviated code will not be graded.
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 assessment, 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!

Assessment Strategies

When the assessment is given in an online format, you are able to switch to myth and use it to compile and run your code, but 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 in the assessment and moving on. If you have leftover time at the end to double-check your work, consider using the compiler then. Unlike a compiler, our grading process can look beyond nit-picky details and evaluate the correctness of your problem-solving approach.

(Note: if you do want to write your own programs on myth for studying, testing, etc. one easy way to do so is to write your .c file, like myprogram.c, and then run make myprogram.c to compile it)

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 assessment

"Open resources" doesn't mean "Don't prep." The assessment is open-resource, and you can refer to lecture slides, the textbook, lab 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 assessment to learn material that you haven't already.

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 assessment 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 assessment. Swing by Helper Hours or post on the discussion forum; we’re happy to help!

During the assessment

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.

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

Downloads

Here is a reference sheet that may be helpful during review and during the assessment. You will not use every function listed and you may use standard library functions not listed (unless otherwise restricted in the exam requirements). Keep it handy!

Exam Reference Sheet:

Webpage | PDF

Practice Materials:

Note that the practice exams below were given out after assign4 was completed, meaning they emphasized generics slightly more heavily than the mid-quarter assessment will.

Practice 1: PDF | Solutions
This was the midterm from CS107 Winter 2018. It was written as a 120 minute closed-book BlueBook (electronic) exam.

Practice 2: PDF | Solutions
This was the midterm from CS107 Fall 2018. It was written as a 110 minute closed-note paper exam.

Practice 3: PDF | Solutions
This was the midterm from CS107 Fall 2017. It was written as an 80 minute closed-note paper exam.

Extra Practice Problems: PDF | Solutions
This is a compilation of additional practice problems from CS107 Fall 2017 for the various topics covered on our assessment.

Still More Practice Problems: PDF | Solutions
These are practice problems written in Winter 2021 by a former CS107 and CS107A CA, Andrew Benson.