Written by Nick Troccoli, based on documents by Julie Zelenski, Nick Bowman, Marty Stepp and others
Wednesday October 21 at 11AM PDT through Friday October 23 at 11AM PDT.
Assessment Blank Answers
Assessment Grading Information
You can find code for testing your answers by making a personal copy of
/afs/ir/class/cs107/samples/assessment (available Fri. 11/6).
Scores and Graded Assessments
How do I find out my score? The scores have been released on Gradescope, a website for grading course materials. If you did not receive an invitation to join Gradescope (please check your spam folder!) please contact the course staff. Log in to Gradescope to see your exam score.
If you have questions about exactly what points you missed and why, please look over the grade and markings made by the grader, compare it with our answer key and test project, and then stop by helper hours or send the course staff an email if you still have any questions.
The statistics of the exam scores (rounded to the nearest whole number, out of 110) were as follows:
1st Quartile: 87
Median (2nd Quartile): 97
3rd Quartile: 103
We work hard to grade consistently and correctly, but sometimes we make mistakes in grading. If you believe part of your exam was incorrectly graded, please first copy the solution project in
afs/ir/class/cs107/samples/assessment and run your answer. This is the easiest way to test your code. If, after running your code, you still believe your grade is incorrect, submit a regrade request online via Gradescope (first view the question in your exam, and submit a regrade for that question on that page). Regrade requests need to point out the aspect of the problem that was misgraded. We use a detailed rubric to grade exams which is documented in the Assessment Grading Information document linked above, so you must clearly articulate how the specified rubric was misapplied when grading your answer. You must also submit test program output for the given problem (if applicable), and a copy of your code (if needed, with any minor syntax errors corrected), and any other necessary code/content so that we can run and evaluate your code.
Regrade requests will be accepted starting on Fri. 11/6 at 2PM PST. The testing code will be up shortly before then.
You must provide all the required information listed above and in the regrade request form in order for us to review your regrade request. Also, we reserve the right to re-grade the whole exam to make sure there are no other grading issues present.
All regrade requests must be submitted within 7 days of the date when regrade requests were opened - by 11:59PM on Friday, November 13, 2020.
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.
The assessment is open-book, though it will include a reference sheet of essential details such as prototypes for standard library functions (e.g.,
You will take the assessment electronically, using our custom BlueBook exam software, which you can run on your computer.
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.
The "assessment window" is the 48-hour period that starts Wednesday, October 21 11AM PDT and ends Friday October 23 11AM PDT. All students must download and complete the assessment during the window. We will target the assessment for a completion time of about 1hr 50min, 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 the assessment. You may choose any 3-hour time period that is entirely contained within the assessment window during which to take the assessment. You do not have to communicate your planned schedule to us. Our tools automatically monitor the time you download and when you submit. Your submission must be received no later than 3 hours after you have downloaded the assessment. Late submissions cannot be accepted.
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:
- 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 further 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
- 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
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!
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 Bluebook 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. For this reason, Bluebook does not compile or execute your code to avoid these issues becoming a distraction.
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 draw a picture of the 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. 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, 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.
IMPORTANT: Once you have downloaded the installer file, install BlueBook wherever you wish on your computer. If you're using a Mac and you get an error saying that the Disk Image is from an unidentified developer, open up the installer file in your finder, and right click it and select "Open." The same window will pop up, but this time you'll have a chance to open it anyway. If you get any popups asking for keystroke or other permissions, please make sure to grant them in order for the exam to administer properly. On Windows, if you get a message that says, "Windows protected your PC," you can click on "More info" and then "Run anyway."
Exam Reference Sheet:
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: BlueBook | PDF | Solutions
This was the midterm from CS107 Winter 2018. It was written as a 120 minute closed-book BlueBook exam.
Note: the practice BlueBook exam is configured with an infinite time limit. You cannot close BlueBook and come back to work on the exam later - you must complete it in one sitting. You cannot submit practice exams - if you'd like to check your answers, leave BlueBook open while you do so. Note that for security reasons, BlueBook disables copy/pasting into or out of BlueBook. You can copy/paste within BlueBook, however.
Based on a handout by Brahm Capoor
BlueBook is a program that can administer electronic assessments distributed in a special file format. BlueBook itself does not come with any assessments but is rather just an application used to take assessments. Your assessments, including practice assessments, will be distributed as special BlueBook files uploaded to the course website. These files are encrypted and cannot be opened without a password, which will be provided to you at the start of the assessment, or along with the practice materials. Download these files and keep them wherever you wish on your computer.
Once you have BlueBook installed and an assessment downloaded, begin by opening BlueBook. On a Mac, if you get a message saying that you were blocked from opening the app for security reasons, browse to the app in the Finder, right click it and select "Open." The same window will pop up, but this time you'll have a chance to open it anyway. The app should go full screen and allow you to choose the assessment file you downloaded earlier. Click the folder icon on the right of the screen and navigate to the assessment file and click ‘ok’, followed by ‘Load Exam’. At this point, you’ll be brought to the Start Screen. Fill out your details on this screen, fill in the password and click ‘Start Exam’.
You’ll then be brought to the main Exam View, which allows you to go back and forth between all the questions for the duration of the assessment. You can navigate between questions using the toolbar at the top of the window. The text editor provided to you will have syntax highlighting, bracket completion and automatic indenting, but isn't a compiler and can't run your code. The assessment will end automatically after the specified duration ends.
When you are done with your assessment – or time has run out – you can begin the submission process for the assessment. Do so by clicking the blue ‘Submit’ button in the toolbar. Once time runs out, this process automatically starts. Beginning submission is an irreversible decision, so make sure that you’re confident you’re ready to turn your answers in. Once you confirm that you want to submit, the BlueBook window will shrink and allow you to submit the exam. Importantly, we verify your identity while submitting, so please make sure to have your two-step authentication device, SUNET ID and password handy. Once your submission is successful, you will see a message with a green check mark and a confirmation code of your assessment submission, which you should keep for your records in case any issues arise later. At this point, feel free to close BlueBook. Congratulations! You’re done with the assessment!
Some final notes about BlueBook:
- BlueBook was designed for closed-note exams and the splash screen asks you to submit to the closed-resource requirements, including not accessing the internet or other applications. We will not be restricting access to those resources, but you must check those boxes anyway.
- Please make sure that your laptop has at least a few gigabytes of free space before the exam begins. While BlueBook exams certainly don’t take up that much space, we do back up your answers in case your computer crashes and we want to make sure your computer has enough space for these backups.
- Should your laptop crash during the exam, please communicate with us as soon as possible so we can restore your answers and you can continue working. Do not attempt to restart the exam from scratch as this might overwrite your previous answers.