1 Attendance

We will be taking roll in lab each week! Please come to your assigned lab to be counted present!

Each lab TAs are empowered to select their own method of taking roll. Please follow your lab TA’s instructions.
They may dock points if you are excessively late or leave unusually early.

2 Prepping for the Exam

For various reasons, CS 1110 exams are given on paper and involve writing code by hand. The goal of this lab is to prepare you for that: both the on-paper coding and the idea of being tested.


We use a system called TPEGS to scan, grade, and return your paper exams. For this to work, you need to fill in a bubble sheet on the first page of your exam. The bubble region looks like this:

Blank TPEGS footer
Blank TPEGS footer

You fill in your computing ID, skipping rows if you have less than 6 characters in your id, like this:

Example filled-in TPEGS footers
Example filled-in TPEGS footers

The footers are read optically, so please fill in the bubbles darkly (either with ink or dark pencil).

2.2 Lab mechanics

This lab will run as follows:

  1. The TAs will review what you’ve learned this week
  2. Paper coding questions will be distributed; you’ll have some time to work on them
  3. The TAs will show the reference solution and the grading rubric; you’ll grade your own papers
  4. Conversation about lessons learned and tips for successful testing maybe shared, time allowing

The problems we prepared for the TAs to review are here

The versions the TAs had, with solutions and rubrics, are here

2.3 Grading rubrics

Every piece of code looks a little different and we don’t expect perfection on paper, but here are some thing we do look for:

  1. Neatness. It should be easy to read what you wrote.

    • Handwriting shouldn’t require a huge effort to understand
    • Indentation should line up pretty well – it needn’t be perfectly straight, but there should be no ambiguity what’s indented how much
    • We expect you to get colons, key-words, and parentheses right (e.g., def baz(x, y): not define baz[x, y])
  2. Correctness. The algorithm you write should solve the problem given.

    • Partial credit for solving some cases but not all (but no credit for hard coding)
    • Partial credit for comments outlining a good approach without supporting code
    • Partial credit for a few missing bits
  3. Constraints. Follow the directions…

    • If we say Write a function named xyxxy, don’t name yours quux instead
    • If we say Write a function give us a function, not a program
    • Don’t confuse input for arguments, nor return for print

We’ll show you an actual point break-down after you code—we make custom rubrics for each question, often giving away part of the answer, so you won’t get to see the rubric before you code.

3 What else is on the exam?

In addition to coding-on-paper, we typically include

  • We might ask you what example code does, such as

    What does the following print?

    def f(g):
        global h
        g = g + g
        h = g
    g = "3"
    h = 4
  • We might ask you for the type, value, or both of an expression; for example, we might expect you to identify that 2 * 3 / 2 is value 3.0, type float.

  • We might ask open-ended questions, like What is one advantage of writing functions in your code?

    We don’t ask very many of these kinds of questions because it is hard to find questions where all instructors agree on the right grading policy, but we like to ask at least a few.

  • We might ask questions about Python syntax and semantics, such as

    Which of the following is an error?

    1. 2 * 3
    2. '2' * 3
    3. 2 * '3'
    4. '2' * '3'

We try to design the exam so that the median student completes it before the 50 minutes are up. Hitting this goal is not easy, but we try…

4 Past Exams

Spring 2017 Exam 1 is available, as is its key and gradign rubric. Some minor edits were made to the rubric during grading, which are not reflected here.

5 Things we expect you to know

Built-in functions in Python
  • print
  • input – and related terminology like prompt
  • int – what it does given a string or a float and when it creates an error
  • str – what it does given an integer or a float
  • float – what it does given a string or an integer
  • len – to find length of strings
  • type – to find the type of a value
Python operators
  • -, +, *, /, %, //, **
  • How operators and types interact (e.g., that type(4/2) is <class 'float'> not <class 'int'>; that + works on strings but - does not; that * can work with a string and an integer but not with two strings; etc).
  • The update-assignment versions of each operator (e.g., +=)
  • The logical operators and and or
  • The comparison operators <, <=, ==, !=, >=, and >
Variables and assignment
  • Correct syntax for assignment operator =
  • Local vs global scope
  • That a variable names a (value, type) pair
  • the global keyword
  • Integer literals like 1111
  • Floating-point literals like 11.11
  • Boolean literals True and False
  • String literals in all their forms: 'single', "double", '''triple-single''', """triple-double""", and 'with \'escape sequences\' for internal quotes'
  • Definition with def name(argument, list):
  • return: what it does, including that it ends the function
  • invocation with name(argument, values)
  • Creation and conclusion of local scope
  • Why we like functions
  • Definition with if, elif, and else
  • Putting conditionals inside functions or other conditionals