Policies

This document provides an overview of the policies for this course as taught at UC Berkeley.

General Background Information

Welcome to CS 61BL

The CS 61 series is an introduction to Computer Science, with particular emphasis on software and machines from a programmer’s point of view. CS 61A covered high-level approaches to problem-solving, providing you with a variety of ways to organize solutions to programming problems as compositions of functions, collections of objects, or sets of rules. In CS 61BL, we move to a somewhat more detailed (and to some extent, more basic) level of programming by focusing particularly on the efficiency of writing programs (design) and running programs (runtime).

Prerequisites

This class assumes you have taken CS 61A, CS 88, or E7, or have equivalent background to a student who has taken one of these courses. The course is largely built upon the assumption that you have taken CS 61A. CS 88 and E7 students may find the beginning of the course to be a bit scarier, particularly when it comes to object oriented programming. We assume you are coming in with zero Java experience, but we will move through basic Java syntax very quickly.

If you already have Java experience, great! We hope that you’ll help out your fellow students in recitation, lab, and on our class forum, particularly in the opening weeks when everyone is catching up on Java.

Hours and Workload

This is a summer course, which means it is run at twice the speed of a course during the normal semester. In addition, 61B naturally has more involved programming than 61A, and 61BL has even more, so expect there to be a lot of work. We strongly recommend not taking any other courses alongside 61BL.

While we can’t predict exactly how many hours you will spend on the course, here is a brief breakdown of what you will have to do in this course.

Two 1 hour live lectures per week on Monday and Wednesday.
Four 2 hour labs per week on Monday - Thursday, each with required prep work.
One 2 hour Friday Exam Prep session per week (most weeks).
One homework per week (total of 6).
Two exams (one midterm, one final) in the 8 weeks of the course.
Four projects in the 8 weeks of the course.

Remote Policy

This is, per university policy, an in-person course. We will not have remote Lectures, Labs, or Exam Prep Sessions this semester. However, attendance at Lecture, our regular Lab sections (Monday through Thursday), and our Friday Exam Prep sessions is not strictly required: as you can earn credit for assignments and Exam Prep sessions asynchronously. You must take the exams in person. Everything other than exams can be completed remotely.

Alternatives

This is a course about data structures and programming methods. It happens to also teach Java, since it is hard to teach programming without a language. However, it is not intended as an exhaustive course on Java, creating Android apps, user interfaces, graphics, or any of that fun stuff.

Some of you may have already taken a data structures course, and simply want to learn Java or C++. For you, self-study may be a better option.

Finally, the 1-unit self-paced course CS 47B is for students with “sufficient partial credit in 61B,” allowing them (with instructor’s permission) to complete the CS 61B course requirement without taking the full course. 47B is not offered during summer. For more info, see the Spring 2025 CS 47B guide.

Mental Health and Wellness

As a student you may experience a range of issues that can cause barriers to learning, such as strained relationships, increased anxiety, alcohol/drug problems, depression, difficulty concentrating and/or lack of motivation. These mental health concerns or stressful events may lead to diminished academic performance or reduce a student’s ability to participate in daily activities. UC offers services to assist you with addressing these and other concerns you may be experiencing. If you or someone you know are suffering from any of the aforementioned conditions, consider utilizing the confidential mental health services available on campus. We encourage you to reach out to the Counseling Center for support. An on campus counselor or after-hours clinician is available 24/7.

The National Suicide Prevention Lifeline is a 24-hour number any student or faculty/staff person can call to speak with someone about suicide: (800) 273-TALK (8255).

More resources can be found under our Resources tab.

Accommodation

UC Berkeley is committed to creating a learning environment that meets the needs of its diverse student body including students with disabilities. If you anticipate or experience any barriers to learning in this course, please feel welcome to discuss your concerns with the instructors.

If you have a disability, or think you may have a disability, you can work with the Disabled Students’ Program (DSP) to request an official accommodation. The Disabled Students’ Program (DSP) is the campus office responsible for authorizing disability-related academic accommodations, in cooperation with the students themselves and their instructors. You can find more information about DSP, including contact information and the application process here. If you have already been approved for accommodations through DSP or are working through the process, you can set up a meeting with us here to ask any questions or develop an implementation plan if needed.

Course Format

Lecture

Lecture will be held on Mondays and Wednesdays from 9–10am in Li Ka Shing 245. Recordings will be made available after each session.

In CS 61BL, Lecture is intended as a first introduction to topics: you will truly learn and dive deep into these concepts in Lab!

Office Hours

Sherdil will hold regular in-person office hours. Peyrin will hold regular office hours via Zoom. Please see the Calendar for both.

Your TAs will not hold explicit office hours: the four labs per week are intended to serve the role of these.

Labs

Note: There is required reading from the online textbook before each lab. You MUST do this to fill in material not covered in lecture (since, again, CS 61BL is a lab-centered course).

Lab sections meet Monday through Thursday. You may only attend the lab section which you signed up for. All labs will be held in person in a lab room in Soda Hall.

Labs emphasize hands-on experience with the course material, involving coding assignments that are submitted for credit. Labs do not require attendance, but are your main source of help from course staff, including on projects.

Note that some labs will be used to solve theoretical problems similar to what you would see on a midterm: on the schedule, these are called Recitations.

There are currently a total of 21 graded lab exercises (subject to change), each worth 2 points. Thus, while the total point value for labs is 42 points, lab grades are capped at 40 points. This means that you can miss up to 1 lab without penalty if you get a full score on every other lab. It also means that you can get full credit for labs in this class if you do not get a full score on every lab assignment. In other words, getting more than 40 points on lab is equivalent to getting 40 points for your lab score.

Friday Exam Prep Sessions

Friday sessions are Exam Prep sessions that involve working through a worksheet with your classmates and TA. Friday Exam Prep sessions will have a small attendance/participation credit (see grading breakdown below).

Please note that Friday Exam Prep sessions are distinct from labs and will be held in different rooms shown on the main calendar.

There will be 5 Friday Exam Prep sessions. You will need to receive credit for all 5 sessions in order to receive full credit (each session is worth 3 points, capped at 15 point). You can receive credit either by attending the session in person or working on the worksheet asynchronously (more details on how to submit worksheets for asynchronous credit will be announced on Ed).

We will also hold review sessions this semester before the exams. More details will be announced on Ed as the semester progresses: you can use these to replace Friday sessions you may have missed. We still encourage you to complete all Friday Exam Prep sessions, as they will help you better prepare for the exams.

Section Swapping

If you would like to swap to a lab section you are not officially assigned to, we will send out more information about that on Ed as well as update our policies here. Attending a lab that you are not officially enrolled in or have not received permission to attend may result in you being de-prioritized for help.

Homeworks

Homeworks are designed to reinforce your conceptual understanding of the material each week. They will include a mix of multiple-choice, short answer, and coding questions, and will be released on Gradescope every Wednesday, due the following Tuesday at 11:59 PM. Regardless of length, all homeworks will be worth 2.5 points. The maximum number of homework points you can get is 15.

No extensions will be granted for homework assignments for any reason, so please plan accordingly and start early.

Projects

In addition to the HWs and labs, there will be 4 programming projects. In these projects you will build an entire system. All projects except project 3 must be completed on your own. There will be some dedicated lab time to work on these projects, but they are largely meant to be completed outside of lab. This semester, we will not be having explicit TA office hours, so please come to lab to receive synchronous help on projects.

Project 0 and 1 will be relatively easier than projects 2 and 3, taking less time and with greater levels of scaffolding. Project 2 will be a larger scale design project with very little skeleton code. Project 3 will be a capstone project in which you will design a project from scratch. Depending on how ambitious you are, it might end up being much more work than Project 2.

Each project has a specific theme:

Project 0 (2048): Introduction to Java
Project 1 (Deques): Basic Design, Testing, and Code Review
Project 2 (Ngordnet): Design, Large Scale Implementation
Project 3 (Build Your Own World): Large Scale Design

Projects will have different autograder release schedule and restrictions on the number of allowed submissions per a time interval. Full autograder details will be provided on the release of each project.

Project 3

As Project 3 is a large-scale design project, it will be have some differences from the other three projects.

Project 3 will have a synchronous checkoff portion. We’ll release instructions about how to sign up for a checkoff in the last week of class.

For Project 3, all students will be required to work with a partner. You will either be able to choose a partner to work with or request to be paired up with another student who has similar working habits and goals as you.

One of the main goals of CS 61BL is to give you the tools to become a successful software engineer, one of which is the ability to work effectively with others. Barring extreme circumstances, we will not approve for students to officially work alone on Project 3. If you think you have a compelling reason for working alone on Project 3, we will release a form that you can fill out closer to the release of the project (keep an eye on Ed for this) - we will let you know if your request is approved shortly before the release of Project 3.

Full details on partnerships will be released closer to Project 3.

Exams

See the exam policies page.

Surveys

After most weeks, we will send out a weekly survey in the weekly announcements. We will have 6 weekly surveys. Completing each weekly survey will give half of an extra credit point! In addition to the weekly surveys, we will send out presemester, midsemester, and end-of-semester surveys. The presemester, midsemester, and end-of-semester surveys will earn 1 extra credit point each. Completing all three will give 3 points. So, if you complete every survey in this class, you can get a total of 6 extra credit points!

Grading

Your course grade is computed using a point system with a total of 300 points. In other words, there is no curving in this course, other than the clobbering policy above. Your grade will depend on how well you do relative to the bins, and not on how well everyone else does. Though we do not usually do this, we reserve the right to lower the the grading bins for 61BL if grades are too low. We will not raise the bins.

Category	Percentage	Points
Lab Assignments	13%	40
Friday Exam Prep Attendance	5%	15
Homeworks	5%	15
Project 0	5%	15
Project 1	8%	24
Project 2	13%	39
Project 3	13%	39
Midterm	18%	54
Final Exam	20%	59
Total	100%	300

A+	A	A-	B+	B	B-	C+	C	C-	D+	D	D-	F
295	280	265	245	225	205	195	185	175	170	165	160	0

These bins were designed to comply with departmental guidelines that the average GPA for a lower-division required course be in the range 2.8–3.3 (including students who drop or take the class for a P/NP grade).

We will round all grades up to the nearest integer (e.g. 200.01 rounds to 201). This is the only rounding we will do. Please do not contact us about further rounding or exceptions.

If you are taking the course P/NP, any grade of C- or better will automatically be converted to a P. (Source: Registrar’s office.)

We will grant grades of Incomplete only for dire medical or personal emergencies that cause you to miss the final, and only if your work up to that point has been satisfactory. Do not try to get an Incomplete simply as a way to have more time to study or do a project. That is contrary to University policy. Before requesting an Incomplete grade, please contact a college advisor or review your college’s Incomplete grade policies to understand if this is a right option for you. Per university policy, you will not be able to request for an incomplete on assignments that were involved in academic misconduct. For more information, please email the instructors.

Lateness Policy

See the lateness policy page.

Resources

Website

The course home page will provide one-stop shopping for course information. The course schedule as well as all handouts, homework, labs, FAQs, etc., will be posted there.

Discussion Forum

Our discussion forum this semester will be Edstem Discussions (Ed for short). For most questions about the course, Ed is the right place to ask them. The course staff reads it regularly, so you will get a quick answer. Furthermore, by posting online as opposed to emailing us directly, other students benefit by seeing the question and the answer. Don’t forget to check Ed before asking your question, just in case someone else has already posted it. If you have a question about something pertaining to your own code that shouldn’t be shared with the class, or if you have a question about a personal matter, you can make a private post on Ed, which will only be seen by the instructors and staff.

Please read our Ed Guide. We will only respond to questions that adhere to our policies of using Ed.

Official Staff Emails

The main staff email that you might interact with throughout the semester is cs61bl@berkeley.edu. Emailing to this address will send a message to the course staff (instructors and the head/admin TAs). You can use it for correspondence that you don’t want to seen on our class forum. If you send a question that is of general interest, we may post the response on Ed (we will keep personal information out of it, of course). In general, you should expect a response within a few days. Only people who have the “CS61BL@” tag on the staff page will have access to this email.

If you have any problems that require an exception to course policy (e.g. medical emergencies or sudden necessary travel that result in extended absences), please contact cs61bl@berkeley.edu. Please do not email the instructors or course staff for exceptions.

Beacon

Rather than using bCourses, we will be using our own custom learning management system called Beacon located at beacon.datastructur.es. You can use Beacon to keep track of your grades and late assignments.

Reading

There is required reading from the online textbook before each Lab. The online textbook is written by Josh Hug (long-time 61B instructor) and a large team of course staff, and can be found at https://cs61b-2.gitbook.io/cs61b-textbook/.

If you find these notes insufficient, you might consider consulting Paul Hilfinger’s (free) Java Reference or Head First Java, 2nd Edition by Sierra and Bates (O’Reilly, 2005). The optional textbook for the weeks 5-14 of the course is Algorithms, 4th Edition by Wayne and Sedgewick.

The official description of the Java core language is available online in The Java Language Specification (Java SE 21 Edition) by James Gosling, Bill Joy, Guy Steele, Gilad Bracha, Alex Buckley, Daniel Smith, and Gavin Bierman. It’s extremely thorough and precise, at the expense of being quite dense and technical. You may find the official Java 21 documentation to be useful as well.

Software

This official coding environment and text editor for the course is the Integrated Development Environment (IDE) called IntelliJ. While we will not enforce using IntelliJ, we strongly recommend it. We will not officially support any editing or programming environment other than IntelliJ.

This semester, we will use Java 17 or higher. We require you to have an IntelliJ 2023.2 or higher in order to prevent setup issues with our style checker.

You will be able to do any work you’d like on any Windows, Mac OS X, or Linux computer. You will set up your own computer in Lab 1.

We’ll be using the version-control system Git this semester with private repositories on GitHub. Version-control systems allow you to maintain a series of “snapshots” of your files at various points in their development. Used properly, this provides you some back-up protection, so that you can recover previous states of your work when something goes wrong. Also for team-oriented projects (as well as in the real world), version-control systems help manage collaborative work.

Collaboration and LLM Policy

Collaboration Policy

Deadlines can be stressful, and we know that under extreme pressure, it becomes tempting to start rationalizing actions that you would otherwise consider inappropriate. Perhaps you’ll find yourself facing a CS 61BL project deadline, and under all this stress you’ll convince yourself that you’re just going to cheat for the moment so you can get the points, and that you’ll come back later and really learn the thing you were supposed to have learned in order to restore your karmic balance (I’ve heard something along these lines a few times).

Please don’t do this. We care that you learn the material, and that your grade reflects your learning, regardless of the timeline. If you feel that you need to engage in academic misconduct to meet a deadline, please reach out to course staff.

During the Spring 2017 semester, we compiled a series of incident reports written by students who were caught plagiarizing. If you find yourself tempted to cheat, you might turn to the words of others who have made the wrong choice for guidance.

Collaboration Policies
Homeworks, Labs, and Projects	Class assignments were created for learning. As such, they are intended to be completed primarily on your own (or with your partner on Project 3, which requires partners), particularly when it comes to writing the actual code. We do, however, encourage high-level discussion with peers and course staff (more details below).
Exams	For exams, we will be absolutely unforgiving. Any incident will result in a failing grade for the course, though Berkeley will let you retake CS 61B next semester. As above, all incidents of cheating will be referred to the Office of Student Conduct.

What constitutes cheating? The golden rule of academic dishonesty is that you should not claim to be responsible for work that is not yours.

This is obviously open to some interpretation, and you’ll be getting some help from instructors, the internet, other students, and more throughout the course. This is OK, and we hope that the class is an open, welcoming, collaborative environment where we can help each other build the highest possible understanding of the course material.

To help (but not entirely define) the bounds of acceptable behavior, we have three important rules for coding assignments:

By You Alone: All code that you submit (other than skeleton code) should be written by you and your partner alone, except for small snippets that solve tiny subproblems (examples in the Permitted section below).
Do Not Possess or Share Code: Before you’ve submitted your final work, you should never be in possession of solution code that you (or your partner) did not write. Looking up solution code online is effectively possessing solution code. You will be equally culpable if you distribute such code to other students or future students of 61B(L) (within reason). DO NOT GIVE ANYONE YOUR CODE – EVEN IF THEY ARE DESPERATELY ASKING. DO NOT POST SOLUTIONS ONLINE (on GitHub or anywhere else)! If you’re not sure what you’re doing is OK, please ask.

Cite Your Sources: When you receive significant assistance on a coding assignment from someone else, you should cite that assistance somewhere in your source code with the @source tag in a comment. We leave it to you to decide what constitutes ‘significant’. However, citing does not change the extent of collaboration or reference allowed.

Examples:

// @source I worked with [person], the code below receives a list of objects
// and iterates through the list until it finds the number 3 and
// returns the index.
...

// @source From https://stackoverflow.com/questions/16242733/sum-all-the-elements-java-arraylist,
// the following code iterates through the list and sums its values.
...

// @source This code was generated by ChatGPT. It reads and parses
// all integers from the file, which I then pass into my computeSum method.
...

For clarity, some examples of specific activities are listed below:

Permitted:

High-level discussion of approaches for solving a problem.
Giving away or receiving significant conceptual ideas towards a problem solution. Such help should be cited as comments in your code. For the sake of other’s learning experience, we ask that you try not to give away anything juicy, and instead try to lead people to such solutions.
Discussion of specific syntax issues and bugs in your code.
Using small snippets of code that you find online for solving tiny problems (e.g. googling “uppercase string java” may lead you to some sample code that you copy and paste into your solution). Such usages should be cited as comments in your code!

Permitted with Extreme Caution:

Working on a project alongside another person or group of people. Your code should not substantially resemble anyone else’s!
Sending code to someone at a company when you are applying for a job. You should never send code publicly. Rather, you can add the recipient as a private collaborator to your Github repository.

Absolutely Forbidden:

Typing or dictating code into someone else’s computer is a violation of the “By You Alone” rule.
Possessing another student’s code in any form before a final deadline, be it electronic or on paper. This includes the situation where you’re trying to help someone debug. Distributing such code is equally forbidden.
Possessing solution code that you did not write yourself (from online (e.g. GitHub), staff solution code found somewhere on a server it should not have been, etc.) before a final deadline. Distributing such code is equally forbidden. Looking at solution code online counts as possessing code.
Posting solution code to any assignment in a public place (e.g. a public git repository, Google Drive, Discord, etched into stones above the Mediterranean, etc). This applies even after the semester is over.
Working in lock-step with other students. Your workflow should not involve a group of people identifying, tackling, and effectively identically solving a sequence of subproblems.

Please also refer to the LLM Policy section for more details on what is permitted use of LLMs. If 61BL is causing massive disruption to your personal life, please email cs61bl@berkeley.edu.

In essence, our ultimate goal is for students to grasp the code they’ve crafted. It’s not just about completing projects; it’s about cultivating a deep comprehension of their code. We assign these projects to give you an opportunity to build a strong foundation in coding, ensuring that you truly understand the core principles behind the concepts we teach in this course.

Obviously, the expressive power of Java is a subset of the English language. And yes, you can obviously obey the letter of this entire policy while completely violating its spirit. However, this policy is not a game to be defeated, and such circumventions will be seen as plagiarism.

You can review our academic misconduct resolution procedures here.

LLM Policy

General Policy Use LLMs in the same way you might use a friend in the class. Just as it’s OK to ask a friend a conceptual question, you may use LLMs for conceptual questions. You would not ask a friend to write code for you, and similarly you may not ask an LLM to write code for you unless explicitly stated (e.g. LLM Experiment in HW 2) in the assignment. As a general rule of thumb, no code or instructions should be pasted/typed into an LLM. If at any point you find yourself stuck on an assignment, concept, or anything else related to CS 61BL, we encourage you to find our staff at office hours or lab!

Code Reviews and Interviews In order to discourage unacceptable LLM use, we will be conducting random code reviews for submitted project code for all projects, with some bias towards code that appears to be LLM-generated. If you find yourself at such a point of total desperation that cheating begins to look attractive, please come to office hours or lab for assistance. We are here to help! For students selected for code review, we’ll hold short interviews to verify that you are able to explain your code and are capable of generating similar code unassisted.

Question Types The below policy applies to all interactions with LLMs relating to CS 61BL content:

Reasonable Questions: These are things that are reasonable to ask an LLM.

“What’s the difference between Integer and int in Java?”
“What is a garbage collector?”
“What does this mean: Exception in thread “main” java.lang.ArithmeticException: / by zero”

Cautionable Questions: These questions are borderline, but allowed with caution. If answers to questions like the below end up generating code that ends up in your submissions, you must cite where the code came from.

“Write a snippet of code to make an array in Java.”
“Write a snippet of code to make every word uppercased in Java.”

Unreasonable Questions: These questions will massively detract from your learning experience in the course, and should not be asked to LLMs.

“Design an algorithm to solve this following task: [copy pasted from spec]”
Any prompt that involves copying, rewording, paraphrasing, etc. more than approximately 15 words of an assignment.
Any prompt that aims to generate code that can be directly copied and pasted into an assignment with minimal revision.
Any prompt that involves giving your own code to the LLM to review. This includes Github Copilot, ChatGPT, Claude, built-in LLM tools in IDEs, etc.

We believe that students are able to tell the difference between using an LLM to genuinely attempt to understand the course content more deeply and using an LLM to avoid engaging with the learning goals of the course or to complete assignments without learning more about the content. We also believe that LLMs are very prone to giving out incorrect answers, so we will not penalize asking about the accuracy of LLM output on course platforms. For example, if an LLM gives you information that seems to be wrong, please ask! We are here to support your learning and correct your misconceptions, and course staff is an official source of truth for CS 61BL. It’s better to ask us and be confident in the reply than to possibly internalize incorrect information after the end of this course.

Any AI-generated or inspired code must be cited and explicitly commented as such. Violation of this citation rule is a serious act of plagiarism. Additionally, note that the same restrictions on posting code in a public forum applies to posting LLM code. Do not post large amounts of code publicly on course platforms.

Citing LLMs as a Source

//TEMPLATE @source: used [tool] for [brief < 1 sentence purpose]
...

// @source: used ChatGPT to solve a NumberFormatException when parsing a string to an int 
...

// @source: used Gemini to figure out syntax for scanner.nextLine and its outputs
...

Please comment in specific regions where you received a significant amount of help from LLMs.

Acknowledgements: Portions of this policy are derived from CS 61C Spring 2026 and CS 189 Spring 2026.

Reusing Code from Past Semesters

If you have completed assignments during past semesters and would like to reuse your work, you do not have to let staff know ahead of time. However:

We cannot promise that the assignments are identical across semesters.
By submitting work from past semesters, in part or in whole, you are claiming that the work submitted is completed entirely by you (and if applicable, your former project partner). If you are unsure if the work is your (and if applicable, your former project partner’s) original work, we’d recommend redoing the assignment from scratch.
If you intend to reuse code for Project 3 (a partner project), you may be required to work alone. If you had a project partner while working on your project originally, you may submit the portions of the projects that they completed.

Auditing 61BL

We welcome those who are interested in auditing 61BL. We will provide access to our assignments and autograders, but you will not have access to anything that requires manual human effort (e.g. staff support, exam grading, lab sections, etc.). We cannot provide staff support for auditors.

61BL SU26 lectures will be made available to those with a Berkeley email. (If you are a non-Berkeley student, see the SP25 audit policy.)

We cannot add auditors to private platforms (e.g. bCourses, Ed, SU26 student Gradescope). All the information we can publicly share is available on this course website.

Note: If you’re auditing the course, you will not be able to access Beacon. Instead, you can directly clone the skeleton repo to get a copy of the starter code.

To get everything set up, go to Gradescope and select the “Add a course” button. Enter course code KDR8BZ to be added. You will not be given a student repo, so you will have to create your own on GitHub in order to submit assignments. After you complete setup and Lab 1, you should have access to all the code for the class.

A Parting Thought

Grades and penalties aren’t the purpose of this course; we really just want you to learn and be successful.

The entire staff is very excited to be teaching CS 61BL this semester and we’re looking forward to meeting such a large and enthusiastic group of students. Welcome to CS 61BL!

Acknowledgements

Some course handout material derived from previous terms, professors, and GSIs.