Writing Homework and Problem Sets That Work

If you are asked to write or revise homework for the course you TA, this page is for you. That covers programming assignments and also problem sets in theory courses: discrete math, algorithms, theory of computation. A good assignment gives students practice on the skills the course is about and shows you, from what they hand in, who has them. A weak one mostly measures who decoded the instructions. The ideas below come from well-run computer science courses and from teaching centers' advice on assignment design, and nine example assignments show them at work. Your instructor's expectations come first; where this page and your course differ, follow your course and ask.

Defaults that work. If you only take four things from this page:

Start from one or two things students should be able to do when they finish, and make every part practice one of them.
Put the purpose, the task and how it is graded on the page, in that order.
Write the full solution and the rubric as you write the assignment, not after. For code, write the autograder tests too.
Do it yourself with a timer, then have another TA try it cold, before it goes to the instructor.

Before you write anything

What should students be able to do afterward?

Write one sentence per skill, with a verb you could watch someone do: "write a recursive function on a tree and explain its base case", "prove a claim by strong induction and state the inductive hypothesis", "design a greedy algorithm and argue why it is correct". Each part of the assignment should practice one of these sentences. If a part practices none of them, cut it.

What does the course already have?

Read last term's version and its solutions, the starter code or LaTeX template, the autograder setup, the course's AI policy, and the Piazza or Campuswire threads from the last time it ran. The questions students asked then are the places the old assignment was unclear. In a theory course, also check which definitions, notation and results from lecture students may use.

How long should it take?

Ask the instructor how many hours a week students should spend outside class, and size the assignment to that. Then do it yourself with a timer. As a rule of thumb, plan for students to take at least three times as long as you did. Proofs stretch further: you already know the key idea, and finding it is most of their time.

Writing the assignment

1. Say why first

One or two sentences on what the assignment is for and how it connects to the course: "This is the same pattern you will use for the project's data layer", or "Next week's algorithms all rely on this kind of exchange argument." Students who know the purpose make better choices when the instructions run out.

2. Break it into steps

Split a large task into parts that each produce something you can check.

Code: a function that passes its tests, then the next one. Starter code, a worked first step or a checkpoint partway through all help students who stall at a blank file.
Theory: a warm-up that tries small cases (n = 1, 2, 3), a lemma before the main result, or "first show this one case, then generalize". Students who see the pattern in small cases can usually find the proof.

Fade the support across the term as students get stronger.

3. Be exact about what is given and what is asked

Code: give input and expected output for the normal case and the edge cases you care about (empty input, one element, duplicates, bad input). Say what students may change and what they must leave alone (file names, function signatures).
Theory: state the claim precisely, with every variable's domain. Use the definitions from lecture, word for word, or link to them. Say whether students must prove, disprove, or decide which. For an algorithm, say what counts as a full answer: the algorithm, why it is correct, and its running time.

4. Say exactly what to hand in

List the files, the format and where they go (Gradescope, GitHub, Canvas). For written work, say whether it must be typed, give a LaTeX template if the course uses one, and ask for one problem per page so Gradescope pages match. Say what happens if code does not compile or a page is not assigned. Most avoidable regrade requests start here.

5. Say how it is graded

Give the points for each part.

Code: say what the autograder checks and what a person reads. If some tests are hidden, say so and say what kind of cases they cover.
Theory: say what a complete proof needs (the setup, the key step, the conclusion) and how partial credit works: a correct structure with a gap earns more than a page of algebra that goes nowhere. Say which results students may cite without proof. A shared checklist, like Stanford's in the reading list, makes "rigorous enough" concrete.

Students should be able to read the rubric and know what "done" looks like.

6. Ask for a decision or an explanation

One part where students choose and justify tells you more than another routine exercise.

Code: choose a data structure, a design or a test case, and explain the choice in two or three sentences.
Theory: find the flaw in a short wrong proof, give a counterexample to a false claim, or say which proof technique fits and why before writing it.

These are also hard to hand off to an AI tool without understanding them.

7. One new idea at a time

Put the new skill in a setting students already know, or a new setting with a skill they already have, not both at once. A new proof technique on a familiar object (induction on sums before induction on trees) lets you see whether they have the technique. When everything is new, you cannot tell which part they missed.

8. Make it worth doing

Real data, a small working program, or a problem students recognize keeps them going through the hard parts. In a theory course, a problem tied to something they have built (why this hash table resizing is fast on average, why this scheduler is optimal) shows why the proof matters. Nifty Assignments (below) has many tested programming assignments with starter code.

Problem sets in theory courses

A few things that apply to proofs and algorithms in particular:

Mix the problem types. Prove, disprove with a counterexample, find the error in a given proof, put a scrambled proof in order, and design-and-analyze. The ordering kind (Proof Blocks, in the reading list) is autogradable and works well as a warm-up.
Avoid problems whose answers are one search away. Textbook exercises and famous puzzles have published solutions, and AI tools have seen them. Change the object, the numbers or the question so the idea is the same and the surface is new.
Avoid a single trick unless the trick is what you are teaching. If one insight unlocks the whole problem, students who miss it learn nothing from the rest. Add a hint or a first step.
Give a model. One fully written proof in the handout or in section shows the level of detail you expect better than any description of rigor.
Grade a few real attempts before release, if you have last term's work. That is where you find out whether your rubric's partial credit makes sense.

Example assignments by level

Nine short sketches, three each for programming, theory and informatics, at an introductory, middle and upper level. The course numbers show the level the sketch is pitched at, using CICS course descriptions as a guide; these are not real assignments from those courses. Each one uses the ideas above, named at the end. Borrow the shape, not the details.

Programming, introductory (a course like CICS 110)

Outcome: write a function with a loop and a condition, and test it on the edge cases.

The assignment: Streaks in the weather. Students get a CSV of daily high temperatures in Amherst and starter code that reads it into a list.

Write longest_streak(temps, threshold): the length of the longest run of days above the threshold. The handout gives five examples, including an empty list, no day above, and every day above.
Write two test cases of your own and say in one line what each one checks.
In two or three sentences: you could have counted with one loop or with two. Which did you use, and why?

Graded on: autograder 70% (half the tests visible; the hidden half are edge cases of the kinds shown), the two tests 20%, the explanation 10%.

What it shows: steps, examples with edge cases, a decision to explain.

Programming, middle (a course like CICS 210)

Outcome: implement a data structure to an interface, and check that the running time matches the Big-O analysis.

The assignment: Autocomplete, two ways.

Implement insert and starts_with(prefix) on a trie, to a given interface. A sorted-list version is provided.
Time both versions on the provided word lists of 10,000 and 100,000 words, and fill in the table in the template.
One paragraph: which version wins for which operation, and do your numbers match the Big-O you would predict? Refer to your own table.

Graded on: correctness tests 50%, the table 20%, the analysis paragraph 30% (rubric: a prediction, the evidence, an honest explanation of any mismatch).

What it shows: worth doing (a real feature), a decision tied to the student's own data, which an AI tool cannot supply.

Programming, upper (a course like COMPSCI 320 or 326)

Outcome: add a feature to code someone else wrote, with tests, and explain a design trade-off.

The assignment: Your first pull request. Students get a small working web app with a test suite.

Add search with pagination to one API route, and write tests for it, including an empty result and the last page.
Open a pull request whose description explains one design choice (for example, offset or cursor pagination) and its trade-off.
Review one classmate's pull request with at least two specific comments.
Commit at least three times. AI tools are allowed: say where you used them and what you changed in what they gave you.

Graded on: all tests pass 30%, your tests 20%, the pull request description 25%, your review 15%, commit history 10%.

What it shows: grading the process, a decision to explain, an AI policy on the page.

Theory, introductory (a course like INFO 150)

Outcome: count with the sum and product rules, and explain each step.

The assignment: Counting codes.

Warm-up: list every 2-character code made from the letters A, B and the digit 1, with no repeats. How many are there?
Codes use the letters A to Z and the digits 0 to 9. Count the 6-character codes with exactly two digits and no repeated character. Write one sentence for each factor in your answer saying what it counts.
A student counted the codes with at least one digit and got too many. Their work is shown. Find the double counting and fix it.

Graded on: correct answers 40%, the explanation of each step 40%, the error found and fixed 20%.

What it shows: small cases first, find the error, partial credit for reasoning.

Theory, middle (a course like COMPSCI 250)

Outcome: write a complete proof by strong induction, with the inductive hypothesis stated.

The assignment: Strings without 11.

Put the given scrambled induction proof in order (autograded, Proof Blocks style).
Count the binary strings of length n with no two 1s in a row, for n = 1 to 5. Conjecture a recurrence.
Prove your recurrence by strong induction. State the base cases and the inductive hypothesis in full sentences.
A short "proof" by induction that the count is odd for every n of 2 or more is shown. Check it against your table, then find the first false step.

Graded on: the ordering 10%, the table and conjecture 15%, the proof 55% (base cases 10, hypothesis stated 10, inductive step 25, conclusion 10, following the course's proofwriting checklist), the false step 20%.

What it shows: mixed problem types, small cases before the proof, a rubric that rewards structure.

Theory, upper (a course like COMPSCI 311)

Outcome: design a greedy algorithm, prove it correct with an exchange argument, and analyze its running time.

The assignment: Covering office hours. Students have asked for help in given time windows; place the fewest TA check-ins so every window contains one.

Try two natural greedy rules on the small instance provided. Show that one of them fails.
Give your algorithm in clear pseudocode.
Prove it uses the fewest check-ins, with an exchange argument.
Give its running time and say which step dominates.

Graded on: the counterexample 15%, the algorithm 20%, the proof 45%, the running time 20%. A correct algorithm with a proof that has one gap earns most of the proof points if the structure is right.

What it shows: a familiar problem in a new setting (so the answer is not one search away), a counterexample before the proof, explicit partial credit.

Informatics, introductory (a course like INFO 248)

Outcome: join and clean two datasets, make one clear chart, and say what the data can and cannot show.

The assignment: Is the dining hall busier on rainy days? Students get daily meal-swipe counts (aggregated, no individual data) and daily weather.

Join the two files by date in the provided notebook, and decide what to do with missing days. Say what you did and why in one sentence.
Make one chart that answers the question. Label the axes and give it a title that states the finding.
Write 150 words: what the chart shows, and one reason it might mislead (for example, rain falls more in some months).

Graded on: the notebook runs top to bottom 30%, the chart 30%, the write-up 40% (rubric: a claim, the evidence, a limitation).

What it shows: a question students care about, a decision to explain, a written limitation.

Informatics, middle (a course like INFO 348)

Outcome: build a predictive model, compare it with a simple baseline, and explain where it fails.

The assignment: Predicting bike-share demand. Students get a public city bike-share dataset with weather.

Hold out the last month as the test set before doing anything else.
Build a baseline (tomorrow equals today), a linear model and one model of your choice.
Pick an error measure, say why it fits this problem, and report all three models in one table.
One paragraph: which features mattered, and the days your best model got most wrong, with a guess at why.

Graded on: a clean train and test split with no leakage 20%, the models 30%, the table and the measure's justification 20%, the error analysis 30%.

What it shows: a decision to explain, a baseline that keeps results honest, analysis tied to the student's own results.

Informatics, upper (a course like INFO 494PI, Personal Health Informatics)

Outcome: design a small health-tracking feature, test it with people, and reason about privacy.

The assignment: Design and test a tracker.

A one-page brief: who it is for, the need, and each piece of data it collects and why.
A paper or clickable prototype.
Try it with three people and take notes on what they did and said, not what you hoped.
A privacy section: who sees the data, how long it is kept, and what you would never collect.
Half a page: the one change you would make after testing, and the evidence for it.

Graded on: the brief 20%, the prototype 15%, the testing notes 25%, the privacy reasoning 25%, the change and its evidence 15%. A peer review round before the final version.

What it shows: grading the process, evidence from real users, an ethics question built into the task.

Generative AI

State the course's policy on the assignment itself: what is allowed, what is not, and how to say what they used. Then design so the learning shows in what students hand in, not only in the final answer:

Ask for a short explanation of a decision, a trace of the code on one input, or the one step of a proof the student found hardest and why it holds.
Grade some of the process: checkpoints, commit history, a scratch page of small cases, or a short reflection on what went wrong.
If the course allows AI, say for which parts, and ask students to show what they changed in what the tool gave them.
For proofs, remember that AI tools write confident proofs with wrong steps. "Find the error" problems teach students to check, whether the proof came from a classmate, a tool or themselves.

Detecting AI use by feel is unreliable. Designing the assignment well is a better use of your time.

Using AI to build the assignment itself? Usually fine with your instructor's OK, if you check everything and say so on the assignment or in the syllabus. Using Generative AI to Draft an Assignment has a fill-in prompt and a checklist for judging the draft.

Before it goes out

Check the solution. Run your code through the autograder from a clean copy of the starter code. Have another TA read every proof in the official solution line by line; errors in solution keys are common and costly.
Have another TA do it cold with a timer. Fix every place they had to ask you what something meant.
Write the three questions you expect on Piazza, and answer them in the assignment instead.
Give the instructor a short table: the outcome each part practices, its points, and your timed estimate.

After it runs

Keep a little evidence for next time: the questions students asked, the tests most students failed or the proof step most students skipped, and how long it took. One optional question at the end ("About how many hours did this take you?") is enough for the last one. It also makes a good small teaching-improvement project: change one thing about an assignment and measure what happens.