Final Exam

Regrade Policy:

The system for final exam regrades is the same as on the midterm. If you disagree with the grading of a programming problem, such as if you think your solution actually does work, or that your solution is more nearly correct than it was given credit for, you must download our Eclipse code project, which will contain runnable testers for the exam problems. Type your code into the relevant project .java file(s), fixing any trivial syntax problems. Run it for yourself and see how nearly correct your solution is.

If after running the code files you still think your grade is incorrect, submit your exam to the instructor for a regrade. (Slide it under his office door.) You must include a cover page with a brief written explanation of what specifically you think was misgraded and why. You must also email your .java file(s) for the relevant problem(s) to the instructor so that we can compile and run your code to verify your claim. As part of your cover page, include copy/pasted output from the the test case results, so that we can to verify its correctness.

We will not accept any exam for a regrade unless it includes this cover page, and we will not re-evaluate grading of the correctess of any programming questions without a typed copy of your solution from the .ZIP / .java file being shown to us first.

Also note: When you submit an exam for a regrade, we will regrade your entire exam. If we notice anywhere that you were mistakenly given too many points, we will also correct this. So it is possible that a regrade request will result in you receiving a lower mark than what you started with.

All final exam regrade requests (other than simple score addition errors) must be submitted to the instructor within 7 days of the start of the following quarter (in this case, Autumn 2014).

Time/Place:

  • Date: Friday, June 6, 2014
  • Time: 8:30 - 11:30am (3 hours)
  • Place: Cemex Auditorium

Rules and Information:

Same as on the midterm exam (see rules below).

Practice Exams:

  • icon practice final #1 | key
  • More practice problems can be found from the links to past quarters below, and in your section handouts, and in the textbook.
  • Sample final exam(s) posted here are intended to be similar to the actual final. The number of problems and type of problems on the actual exam will be relatively similar to what is seen on these practice exams, though we do not promise that it will be exactly the same in length or in difficulty.

Practice Exams from Past Quarters:

If you want more practice problems, here are links to some past exams given in 106A by other instructors. They don't exactly match the current exam format, so they may be of limited use. Some of the problems on these tests don't match the topics, difficulty level, and/or type of questions we currently plan to ask. Also note that some of these quarters do not match our exam policies such as whether the test is open or closed-book/notes, etc., so any notes about such policies on these exams do not apply this quarter. These links are provided merely as a convenience to help you study.

Topics to Study:

The actual final exam will have roughly 8-9 total problems. Those problems will be selected from the following categories. For each category, you may be asked to read code (look at a piece of existing code and answer questions about it, such as writing its output), and/or write code (write a piece of code such as a method, class, or short program that solves a problem about that topic).

  • value and reference semantics: demonstrate your understanding of objects vs. primitive values by tracing code that passes several objects, primitives, or arrays as parameters
  • objects and classes: write a class and/or add behavior to an existing class
  • inheritance and polymorphism: look at a confusing piece of code involving inheritance and interpret its output; and/or, write a class that uses inheritance to extend some existing base class
  • arrays
  • multi-dimensional arrays (possibly from the pixels of a graphical image, possibly not)
  • collections: interpret the output of an existing piece of code that uses the collections ArrayList and/or HashMap, and/or write code that uses these collections to solve a problem
  • graphical user interfaces (GUIs): write a complete graphical program that uses GUI components and events to produce a given behavior
  • Note: Though the final focuses on material taught since the time of the midterm, programming is inherently cumulative in that new topics build upon old ones. So you may be asked to solve problems that involve, though not necessarily focus primarily upon, past topics such as strings, int, double, boolean, random numbers, loops, if/else, parameters, return, expressions, variables, constants, file input with Scanner,
  • The following topics are guaranteed NOT to be required to solve any problem on the final exam:
    • Karel the Robot
    • interfaces (taught in week 9 lecture)
    • Javadoc (taught in week 9 lecture)
    • JAR archives; creating a library (taught in week 9 lecture)
    • "real" Java transition (taught in Week 10 lecture)
    • designing your own data structure (seen in some of the practice final problems from past quarters)
    • searching and sorting algorithms (taught in some past quarters)
    • Java layout managers as mentioned in the end of the GUI-3 slide deck (FlowLayout, GridLayout, BorderLayout, etc.)
    • graphical shapes not used in lecture/homework, such as GArc, GPolygon
    • converting numbers to/from other bases, such as binary (base-2) or hexadecimal (base-16)
    • do/while loops and the break or continue statements (regular while loops may be needed, though)
    • the switch statement
    • any Stanford libraries not explicitly taught in class/homework
    • anything else not explicitly covered in lecture / section / homework

Midterm Exam

Scores, Curve, and Other Information:

You can now check your midterm score online using the instructions in an email that you have already been sent. You will get your midterm paper back in section. If you have questions about exactly what points you missed and why, please get your exam from your SL and look it over, compare it with our answer key, then contact the head TA and instructor if you still have any questions.

Curve: +7 points. Since the scores are a bit lower than our targets, we will add +7 points to everyone's midterm score. Scores are capped at a max of 120/120; for example, if you received a raw score of 115/120, your score curves up to 120/120, not 122/120.

Stats: Here are the raw stats before and after applying the curve:

raw curved
MEDIAN 88.5 95.5
MEAN 85.1 92.0
STDEV 19.9 19.7
% range count (curved) % of class
90-100% 66 23.3%
80-89% 69 26.7%
70-79% 57 22.1%
60-69% 26 11.6%
0-59% 40 16.3%

Low Grades: Another topic some students ask about is: If their score was lower than they hoped, how much effect will that have on their grade, or what are their options, etc.? Most of the information to answer this can be found on this web site. The course info sheet lists the relative grading weight of homework vs. midterm vs. final exam, so you can use that to compute the rough effect on your grade of a particular midterm score. Also look at our FAQ page for info about pass/fail grading options, drop dates, and other information.

Regrade Policy:

We work hard to grade consistently and correctly, but sometimes we make mistakes in grading. If you disagree with the grading of your exam, such as if you think your solution actually does work, or that your solution is more nearly correct than it was given credit for, the procedure for regrades is the following:

If your complaint is about the correctness of your solution to a programming question, you must download our Eclipse code project, which will contain runnable testers for the midterm problems. Type your code into the project .cpp file, fixing any trivial syntax problems. Run it for yourself and see how nearly correct your solution is.

If after running the code files you still think your grade is incorrect, submit your exam to the instructor for a regrade. (Either give it to us in lecture, go to our office hours, or slide it under our office doors.) You must include a cover page with a brief written explanation of what specifically you think was misgraded and why. You must also email your Midterm14sp.java file and any other necessary files to the instructor so that we can compile and run your code to verify your claim. As part of your cover page, include copy/pasted output from the the test case results, so that we can to verify its correctness.

We will not accept any exam for a regrade unless it includes this cover page, and we will not re-evaluate grading of the correctess of any programming questions without a typed copy of your solution from the .ZIP / .java file being shown to us first.

Also note: When you submit an exam for a regrade, we will regrade your entire exam. If we notice anywhere that you were mistakenly given too many points, we will also correct this. So it is possible that a regrade request will result in you receiving a lower mark than what you started with.

All midterm regrade requests (other than simple score addition errors) must be submitted to the instructor within 7 days of receiving your exam back in section.

Time/Place:

  • Date: Tuesday, May 13, 2014
  • Time: 7:00 - 9:00pm (2 hours)
  • Place: Cemex Auditorium
  • icon syntax reference sheet (will be given out attached to your exam as a reference; bring your textbook to reference any other Java syntax/libraries)

Practice Exams:

Additional Sample Problems:

If you want more practice problems, here are links to some past exams given in 106A by other instructors. They don't exactly match the current exam format, so they may be of limited use. Some of the problems on these tests don't match the topics, difficulty level, and/or type of questions we currently plan to ask. These links are provided merely as a convenience to help you study.

Rules and Information:

  • The exam is open-book for the Art & Science of Java and Karel the Robot Learns Java textbooks, or any other relevant textbooks you want to bring. You can bring the current edition of the book, or the previous ring-bound "course reader" edition, but not a digital copy and not a printout of the book on loose paper.
  • The exam is closed-notes and closed for all other resources. You may not bring or use any printed materials such as handouts, slides, or practice exams. (A "syntax reference sheet" of necessary syntax will be given to you at the exam.) You may not use any computing devices of any kind including calculators, cell phones, music players, iPad/Kindles, or other electronic devices. Please do not have any of these devices out nor use any of them during the exam.
  • Unless a question specifically mentions otherwise, your code you write will be graded purely on functionality (proper behavior and output) and not on style. So, for example, redundancy, bad variable names, bad indentation, or lack of comments will not reduce your score.
  • You don't need to write any import statements in your exam code.
  • Please do not abbreviate any code on the exam. Abbreviated code will be ignored during grading.
  • Please be quiet during the exam. If you have a question or need, please quietly exit the room and a nearby SL or TA will assist you.
  • Any corrections or clarifications to the exam will be written at the front of the room.
  • Please follow the Stanford Honor Code during the exam. Work on the exam alone and submit only your own work. Please also take action to prevent any inappropriate activity conducted by others, such as speaking to the person and asking them to stop, or reporting the activity to the instructor.
  • When you have finished the exam, please leave the room quietly and bring your exam to the instructor and SLs.

Topics to Study:

The actual midterm exam will have roughly 7-9 total problems. Those problems will test you on the following concepts. For each category, you may be asked to read code (look at a piece of existing code and answer questions about it, such as writing its output), and/or write code (write a piece of code such as a function or short program that solves a problem about that topic).

  • Expressions and variables: given some Java expressions with numbers, strings, logic, etc., evaluate them and write the results; and/or, write Java code that uses expressions and operators to solve a problem.
  • Java control statements: given a piece of Java code using Java statements like for loops, while loops, if/else, etc., evaluate it and write its output/results; and/or, write Java code that uses Java control statements to solve a problem.
  • Karel programming: given a piece of Java code that gives instructions to Karel the robot, evaluate it and write/draw the resulting state of the Karel world; and/or, write a complete Karel program to accomplish a given result in Karel's world.
  • Console programs: write Java code to perform console input/output using Stanford's libraries.
  • Graphics programs: write Java code to implement a graphics program with certain behavior using Stanford's libraries; this may include drawing shapes such as GRect, GOval, etc., animation, and/or handling mouse events.
  • Methods, parameters, returns: given a piece of Java code with several methods and parameters/returns, evaluate it and write its output/results; and/or, write a method of Java code that accepts various parameters and/or returns certain values.
  • Randomness: write Java code to generate random behavior using the RandomGenerator class.
  • String and char: given a piece of Java code that interacts with text data, evaluate it and write its output/results; and/or, write Java code that processes strings and characters to produce a given result.
  • File processing: write Java code that uses a Scanner to read data from a file in a given format and produce a particular result.
  • ArrayList: given a piece of Java code that manipulates an ArrayList, evaluate it and write its output/results; and/or, write Java code that manipulates an the elements of an ArrayList.
  • Arrays: given a piece of Java code that manipulates an array, evaluate it and write its output/results; and/or, write Java code that manipulates an the elements of an array.
  • Classes and objects: write a small Java class and/or add behavior/data to an existing C++ class; understanding public vs. private, methods, and constructors.
  • The following topics are guaranteed NOT to be required to solve any problem on the midterm:
    • graphical shapes not used in lecture/homework, such as GArc, GPolygon
    • any Stanford libraries not explicitly taught in class/homework
    • converting numbers to/from other bases, such as binary (base-2) or hexadecimal (base-16)
    • do/while loops and the break or continue statements (regular while loops may be needed, though)
    • the switch statement
    • throwing exceptions with the throw statement
    • multidimensional arrays
    • anything else not explicitly covered in lecture or homework
    • any material covered past the end of week 6 of the course (material from weeks 1-6 inclusive will be tested on the exam)

Here is a handout created by a past CS 106A instructor with advice about how to study for, and take, a CS 106A exam.

This document and its content are copyright © Marty Stepp, 2014. All rights reserved. Any redistribution, reproduction, transmission, or storage of part or all of the contents in any form is prohibited without the author's expressed written permission.