Homework Policies

The course staff must critically examine tens of thousands of pages of homework submissions this semester! We desperately need your help to make sure homeworks are graded fairly and returned quickly. If you have any questions or concerns about these policies, please don’t hesitate to ask in lecture, in lab, during office hours, on Ed Discussion, or on Discord.

• What homework is for
• Late submissions
• Deadly sins

• Logistics: How to submit
• Form: How to write
• Content: What to write

We apologize in advance for the length of this document. A lot of this stuff may seem obvious to almost everybody, but with many decades of combined experience teaching algorithms and models of computation, the various 374 instructors have seen a lot of strange things.

Homework handouts and solutions are available on a different page.

What homework is for

Every part of this course stresses a set of skills that can only be developed through practice and feedback, just like cooking or basketball or writing fiction or gardening or interviewing or teaching. Yes, there are several things that are useful to know and understand, but that knowledge and understanding is not enough. That comfortable feeling of, “Oh, sure, I get it,” when you watch a well-presented lecture, hear a TA carefully explain a homework solution, read considerately written lecture notes, or read a solution written by OpenAI or Claude, is a seductive, dangerous trap.

You can only learn to do the thing by actually doing the thing. The homework is your opportunity to practice doing the thing.

The lectures and textbook and office hours and labs and guided problem sets hopefully provide good intuition and motivation and justification for the skills we want you to develop, but the best way to develop those skills is by trying to solve the problems yourself. The practice is far more important than the solution.

We aren’t really asking you for solutions; we already have solutions. We’re asking for examples of your skill in developing and explaining solutions, so that we can give you feedback to help you improve.

Because the homework is intended to help you develop new skills, you are likely to get stuck; for some problems, you may have no idea how to even start. And that’s okay.  Getting stuck is completely normal, even for experts. You might even see some of the same problems that Emily got stuck on twenty years ago.

That’s why we have office hours and a textbook and lectures and lecture videos and PrairieLearn and Ed Discussion and Discord and a library and Wikipedia; helping you get unstuck is part of our job. That’s why we encourage you to work together; not so that you can share solutions, but so that you can share ideas and suggestions and feedback. 

Similarly, you won’t necessarily develop a complete solution to every homework problem yourself, and you may not be able to tell at first which parts of your final submitted solution are correct. And that is also okay. Asking for help is normal, even for experts.

That’s why we provide homework solutions—not just to show you the answer, but to help you see your own work more clearly. That’s why we grade your homework submissions—not to give you points, but to give you feedback to help you improve.

To get the most out of any particular homework problem, it’s important not just to aim for a solution to that specific problem, but to pay attention to how you’re solving it.  Every problem is an opportunity to practice that kind of problem. We don’t just mean every assigned homework problem; we mean every problem presented in class, every problem described in the textbook or notes, every lab problem, every solved problem in the homeworks, and even every exam problem.

It’s also important to aim for improvement—not perfection (which is impossible), not being better than other people (which can be toxic), but doing the thing better than you did yesterday, every day.

In practice, course grades in CS 374 are determined almost entirely by exams, which ask you to demonstrate the skills that the homework is meant to develop. Ultimately, homework scores have minimal impact (unless, of course, those scores are equal to or close to 0.) But even if your only goal is to optimize your course grade, practicing with the homework problems—developing both your skill and your confidence in that skill—is more important than getting the right answers.

Deadly sins

We’ve identified a small number of bad writing (and thinking) habits that are strongly correlated with poor performance in algorithms courses but are easy to avoid. Homework and exam solutions that commit any of these sins will be penalized. We’re not trying to be scary or petty (Honest!), but we do want to break a few common bad habits that seriously impede mastery of the course material or make it unduly difficult for us to give you feedback on homework or grade your abilities during exams.

• Don’t cheat. You must write everything in your own words, and properly cite every outside source you use, including other students or the use of an LLM to generate content. Using ideas from other sources or people without citation is plagiarism. Copying other sources verbatim, even with proper citation, even with their permission, is plagiarism. Don’t do that. As long as you are honest you’ll still receive full credit. See out academic integrity policies for more information.
• Write general solutions, not examples. Don’t “describe” algorithms by showing the first two or three iterations and then writing “and so on”. Similarly, don’t try to prove something by demonstrating it for a few small examples and then writing “do the same thing for all n”. Any solution that includes phrases like “and so on”, “etc.”, “do this for all n”, or “repeat this process” risks getting a score of zero, because it doesn’t actually describe the algorithm (or automaton, etc.) itself. Those phrases indicate precisely where you should have used iteration, recursion, or induction but didn’t. Examples are not the same as an algorithm or proof.
• When describing algorithms, don’t submit code. You are not describing algorithms for the compiler. You are describing algorithms for a fluent programmer who doesn’t share your intuition, training, or intelligence, and who thinks your favorite programming language sucks, and your goal is to help them understand your algorithm, not just see it. Describe your algorithms using structured English and/or pseudocode. Bare code with no English explanation risks getting a grade of zero, even if it is correct.

More generally, explain what you’re doing. Whenever you introduce a new abstract object, explain in English what it means. When you describe a DFA, specify in English the purpose/meaning of each state and transition. Whenever you describe an algorithm, specify in English precisely what problem your algorithm is meant to solve. Whenever you give a recurrence, describe in English precisely what function the recurrence is supposed to compute.

You should already be doing this whenever you write code.

Just keep doing it.

Logistics: How to submit

• Submit homework solutions as PDF files on Gradescope. Submit one PDF file for each numbered homework problem. Gradescope will not accept other text file formats such as plain text, HTML, LaTeX source, or Microsoft Word (.doc or .docx). Homework submitted as images (.png or .jpg) will not be graded.

• Groups of at most three students can submit group solutions. We strongly encourage (but will not require) every student to work in a group with at least one other student. Students are responsible for forming their own homework groups. Feel free to post on Ed Discussion or Discord if you’re looking to form one. Groups may be different for each numbered homework problem. Group member do not need to be registered for the same lab section. Gradescope automatically limits groups to at most three students.

  • Exactly one member of each group submits the solution to each problem. Even if the groups are identical, the submitter may be different for each numbered homework problem.
  • The submitter also tells Gradescope the names of the other group members. (The other group members must have already enrolled on Gradescope.) Gradescope then automatically applies the grade for that submission to everyone in the group. If this information is not entered correctly, the other group members’ grades cannot be delayed, and they may be lost entirely. The submitter can fix this information even after grades are released. Emily expects a very large percentage of students to not to receive grades for Homework 1 when they initially released due to submitter error. Please prove her wrong!
  • The submitter also selects which pages are relevant for each lettered subproblem ((a), (b), etc.). 

• Each submitted PDF file should include the following information in large friendly letters at the top of the first page:

  • The homework number
  • The problem number
  • The name and NetID of every group member

  If you are typesetting your solutions with LaTeX, you are welcome to use our solution template.

• If you discover that you did not receive credit for your group’s homework submission, please ask the submitter to use the “View or edit group” link that appears to the top-right when viewing the submission.

Form: How to write

Please make it easy for the graders to figure out what you mean in the short time they have to grade your solution. If your solutions are difficult to read or understand, you will lose points.

Be Honest

• Write everything in your own words, and properly cite every outside source you use. We strongly encourage you to use any outside source at your disposal, provided you use your sources properly and give them proper credit. If you get an idea from an outside source, citing that source will not lower your grade. Failing to properly cite an outside source—thereby taking credit for ideas that are not your own—is plagiarism.

  The only sources that you are not required to cite are the official course materials (lectures; lecture notes; and lab, homework, and exam solutions from this semester) and sources for prerequisite material (which we assume you already know.)

• List everyone you worked with. We strongly encourage you to work with others, including those outside of your submission group, but you must give everyone proper credit. If you work with 20 students outside your submission group, then all 20 names should be cited on your homework solution. If someone was particularly helpful, describe their contribution. Be generous; if you’re not sure whether someone should be included in your list of collaborators, include them. For discussions in large groups, where collecting individual names is impractical, it’s okay to write something like “discussions in lab” or “Thursday homework party”.

• List every LLM you used and why. You are welcome to consult generative-AI chatbots to help solve homework problems (just like any other source.) But if you use an LLM for any reason, you must include them in your list of sources (just like any other source,) and you must provide course staff with a brief explanation of what you used the LLM to do, whether it was to improve LaTeX formatting, clean up your draft solution (the output of which you need to make sure matches your own words,) or solve a problem from scratch (the output of which you absolutely have to rewrite in your own words.)

• The list of sources and collaborators as well as LLM explanations should be given at the end of each lettered part of each problem or at the end of the entire problem if it contains only one part. This rule exists so the graders don’t have to spend time jumping around multiple irrelevant pages of your submission as they try to grade a single lettered problem part.

• You must include the list of sources and collaborators whether you used any or not. If you have nothing and nobody to cite, you must still write ”Sources and collaborators: None” or something equivalent. An empty bibliography is still a bibliography!

• Please see our academic integrity policy for more details.

Be Clear

• Write legibly. You will lose points if the graders find your work difficult to read. Writing legibly also helps you think more clearly.

  • We strongly recommend typesetting your homework, especially if you have sloppy handwriting. We recommend using LaTeX, but you are welcome to use whatever program and/or markup language you like. A LaTeX homework template is available.
  • You are welcome to submit scans of hand-written paper homework solutions, provided they are clear and easy to read. Write with black ink (not pencil; many scanners have trouble picking it up) on white unlined paper (not notebook or graph paper), and use a scanning app to create a high-quality PDF.
  • You are also welcome to submit pdfs created using a drawing device on a tablet. As before, writing should be black on a plain white canvas. The writing and pdf page size should be such that it would look natural printed on an 8½“×11“ sheet of paper (small writing and/or large canvas sizes lead to a lot of very frustrating zooming for the graders.)
  • The graders have complete discretion to decide whether a submission is difficult to read. In borderline cases, the graders will first give a warning, asking the student for specific improvements in future homework submissions, rather than immediately deducting points. Please take this feedback seriously, and remember that different graders have different tolerances for or abilities to read borderline submissions.

• Write sensibly. You will lose points for poor spelling, grammar, punctuation, arithmetic, algebra, logic, etc. if it leads to any doubt about what you’re trying to communicate. This rule is especially important for students whose first language is not English.

• Write carefully. We can only grade what you actually write, not what you mean. We cannot read your mind, and we will not insult you by trying. If your answer is ambiguous, the graders are explicitly instructed not to try to make it right. Remember to avoid the deadly sins.

• Don’t submit your first draft. Revise, revise, revise. First figure out the solution, then think about the right way to present it, and only then start writing what you plan to submit. See again, “write legibly”.

• State your assumptions. If a problem statement is ambiguous, explicitly state any additional assumptions that your solution requires. (Please also ask for clarification in class, in office hours, on Ed Discussion, or on Discord!) For example, if the performance of your algorithm depends on how the input is represented, tell us exactly what representation you require. Yes, even if the assumption is “obvious”.

• Remember your audience. Write solutions directed toward somebody who has attended the same lectures and labs and has read the same course material up to the point when the homework is due. If you require a lemma or theorem not taught in this course or a prereq, be prepared to explain and prove it. If you require a data structure not taught in this course or a prereq, be prepared to explain how and why it works. And for both of those cases, cite where the result comes from; it should be a human or book, and not the LLM that was trained on them.

  Again, describe algorithms using clean, human-readable pseudocode. Your description should allow a competent programmer to directly implement your algorithm, in their favorite language, using a software library containing implementations of every algorithm we’ve seen in class, without knowing what problem you’re trying to solve. Oh, and they think your favorite programming language sucks.

Be Concise

• Keep it short. Every homework problem can be answered completely in at most two typeset pages or five handwritten pages; most problems require considerably less. (No, this is not a hard requirement, but if you’re violating it, something has likely gone wrong.) Yes, we are deeply aware of the crushing irony here.
• Omit irrelevant details. Don’t write “AVL tree” when you mean “balanced binary tree” or “dictionary”. Don’t write “depth-first search” when you mean “linear time whatever-first search”. Don’t submit code; we want to see your ideas, not syntactic sugar. If your solution requires more than two typeset pages, you are probably including too many irrelevant details.
• Don’t regurgitate. Don’t explain binary search; just write “binary search”. Don’t write the pseudocode for Dijkstra’s algorithm; just write “Dijkstra’s algorithm”. If the solution appears on page 374 of Jeff’s book, just write “See page 374 of Jeff’s textbook.” If your answer is similar to something we’ve seen in class, just say so and (carefully!) describe your changes. You will lose points for vomiting, especially if you get the details wrong. If you think you need to give a detailed description of something we’ve seen in class in order to fit in a few subtle modifications, it’s a sign that you should have constructed a new input for a black-box reduction.
• Don’t bullshit. You will not get partial credit for word salad that happens to include some correct keywords. Partial credit is assigned according to the standard rubrics.

Content: What to write

• Answer the right question. No matter how clear and polished your solution is, it’s worthless if it doesn’t answer the question we asked. Make sure you understand the question before you start thinking about how to answer it. If something is unclear, ask for clarification! This will be especially important on exams.

• By default, if a homework or exam problem asks you to describe an algorithm, you need to do several things to get full credit:

  • Describe the precise problem that your algorithm is supposed to solve. This is often the hardest part of designing an algorithm.

  • Give a concise English or pseudocode description of your algorithm. Don’t regurgitate, and don’t turn in code! A dynamic programming algorithm that follows the standard dynamic programming rubric counts as a valid English description.

  • Describe a correct algorithm.

  • Justify the correctness of your algorithm. You must provide a brief justification for your solutions, as evidence that you understand why they are correct. Unless we explicitly say otherwise, we generally do not want a complete proof of correctness (because complete proofs would be too long, tedious, and unenlightening) but rather a high-level sketch of the major steps in the proof.  If your algorithm is a close match for something in the standard rubrics, then justification should already be “baked in”.

  • As an exception to the general rule, greedy algorithms do have to include a formal proof of correctness. Even a correct greedy algorithm is unlikely to receive very many if any points, because it is far too easy to submit something that sounds correct, but isn’t. The onus is completely on you to convince the grader of correctness in these cases. If there’s any doubt, you probably want to stick to dynamic programming.

  • Analyze your algorithm’s worst-case running time. This may be as simple as saying “There are two nested loops from 1 to n, so the running time is O(n^2).” Or it may require setting up and solving a recurrence. We only care about worst-case running times; give the smallest big-Oh bound you can that correctly describes the performance of your algorithm on any input. Unless we specifically ask otherwise, you do not have to analyze space.

  • Describe the fastest correct algorithm you can, even if the problem does not include the words “fast” or “efficient”. Faster algorithms are worth more points; brute force is usually not worth much. We usually won’t tell you what time bound to shoot for; that’s part of what you’re trying to learn. However, if your algorithm is incorrect, you may not get any points, no matter how fast it is!

    More specifically, for each problem we assign, we have a target running time in mind. Correct algorithms that meet the target running time are worth full credit. Correct algorithms that are slower are worth significant partial credit. We typically deduct 2 or 3 points out of 10 for each extra factor of n in the running time; however, every correct and clearly presented algorithm, no matter how slow, is worth some partial credit. On the other hand, algorithms that are faster than the target time bound are worth extra credit; again, we typically award 2 or 3 points for each factor of n. We usually do not give the target running time in the problem statement, because when we do, a lot more students than would otherwise end up submitting an incorrect algorithm with the target running time. First make it work; then make it fast. (And if you can do so correctly, make it faster.)

  Some problems may deviate from these default requirements. For example, we may ask you for an algorithm that uses a particular approach, even though another approach may be more efficient. (Answer the right question!)

• Whatever is written in the standard grading rubrics about a solution type trumps everything else written above. Yes, even on exams.