Self-Assessment Info

Based on documents by Lisa Yan, Nick Troccoli, Chris Gregg, Jerry Cain, Julie Zelenski, Nick Bowman, Marty Stepp and others

The assessments are 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 assessments as a tool to take stock of where you’re at and see how much you’ve learned, as well as what work you have left to do. Each assessment also contributes a small but meaningful contribution to your course grade, which we hope will inspire you to use these checkpoint opportunities wisely!

Assessment 1

Assessment 1 will be available from Friday 7/9 12PM PT - Monday 7/12 12PM PT, covering lectures 1-5 and assignment 2. Material from assignment 1, such as C++ lambdas, will not be covered.

You can find a collection of practice problems from previous CS 110 midterm exams here. We highly recommend revisiting the section and assignment material as you prepare. The textbooks may also contain exercises if you want additional problems to work. For this assessment, We will not ask questions where you must write code (though you may be asked code reading/understanding questions), but we included coding practice in case it’s helpful.

Assessment 2

Assessment 2 will be available from Friday 7/30 12PM PT - Monday 8/2 10PM PT, covering lectures 5-10 and assignments 3-4. Multithreading will not be covered.

You can find a collection of practice problems from previous CS 110 midterm exams here. Note that some of these problems cover multithreading, but this assessment will not cover multithreading. We highly recommend revisiting the section and assignment material as you prepare. The textbooks may also contain exercises if you want additional problems to work. For this assessment, we may ask questions where you must write code. See the practice problems as well as the general section below on coding questions.

Assessment 3

Assessment 3 will be available from Friday 8/20 12PM PT - Monday 8/23 11PM PT, covering lectures 10-18 and assignments 5-6. We may ask a short question or two about MapReduce (lecture 17) and non-blocking I/O (lecture 18), but this will not be the focus of the assessment.

You can find a collection of practice problems from previous CS 110 final exams here. We will not cover multiprocessing, so please focus on the multithreading and networking questions. We highly recommend revisiting the section and assignment material as you prepare. The textbooks may also contain exercises if you want additional problems to work. For this assessment, we may ask questions where you must write code. See the practice problems as well as the general section below on coding questions.

Logistics

All assessments are 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.

Each assessment will have a 72-hour “assessment window” during which all students must complete the assessment. We will target each assessment for a completion time of about 1-1.5 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. Our tools automatically monitor the time you begin and when you submit. Your submission must be received no later than 3 hours after you have started an assessment. 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 during an assessment, please ask them as a private question via our discussion forum.

If you encounter an issue during an assessment period that prevents you from completing the assessment, please email the instructors immediately so that we can work with you to resolve the issue.

The Honor Code

The Honor Code policies are a critical part of the assessments (see the general information handout on the main course homepage) and we expect you to uphold your obligations as for any other coursework. Here are the key principles:

Here is a non-exhaustive list of what resources are permitted and not:

Permitted

Not Permitted

Submitting

The assessments will be administered on Gradescope, an online quiz administration and grading website. Gradescope has the ability to administer quizzes where you type your answers directly into Gradescope and submit them. At the start time of an assessment window, we will post instructions for how to access the assessment on Gradescope.

Grading

From the Course Info handout (courtesy of Jerry Cain):

Scores will be initially interpreted as a percentage out of 100%, but when computing final grades, we’ll take the square root of that percentage and multiply it by 10 to arrive at a different “percentage”. That means a 100% stays a 100%, 81% becomes 90%, and 64% becomes 80%, etc. We’re adopting this grading scheme so self-assessments can be as challenging and thought-provoking as on-campus exams generally are without the added pressure to get every single point. (It also means you’re not competing against each other and fighting to sit in the better half of the bell curve.)

Assessment Strategies

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.

Before the assessment

“Open resources” doesn’t mean “Don’t prep." The assessments are open-resource, and you can refer to lecture slides, the textbooks, 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 an assessment to learn material that you haven’t already.

Practice in simulated conditions. A good way to study for the 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 Office Hours or post on the discussion forum; we’re happy to help!

During an 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.

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 and which tasks can do with just a quick first draft.

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 time for checking your work. Before submitting your assessment, reserve time to go back over your work one last time. 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.

Coding Questions

Some assessments (indicated above) may ask questions where you write code. 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.

Unless otherwise specified, it is fine to write helper functions to implement the required behavior.

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.

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!

You can do it!