Last updated on Friday, December 12, 2025

Callback: Unguided callback

The aim of this callback is to develop your independence and project-planning skills and to prepare you for the unguided lab. In this callback, you will:

1. Think of a modification or improvement you’d like to make to a previous lab.
2. Write a specification describing the planned change:
   • 2 or 3 sentences explaining what feature you plan to implement.
   • 1 sentence explaining which course concepts you plan to use or illustrate.
   • 1 sentence explaining the distribution of tasks among team members (all team members are expected to contribute equal effort to the final result).
3. Implement the change.
4. Receive a “checkoff” from a staff member:
   1. Give a short live demo of your feature.
   2. Walk the staff member through the code and tests that you wrote or modified, by showing them your Git history.
   3. Answer a few clarification questions.

Process

0. Read the rules below.
1. Form a team of 3 to 4 people.
2. Write a one-paragraph specification and submit it to Moodle by the proposal deadline. The specification should consist of:
   • 2 or 3 sentences explaining what feature you plan to implement.
   • 1 sentence explaining which course concepts you plan to use or illustrate.
   • 1 sentence explaining the distribution of tasks among team members (all team members are expected to contribute equal effort to the final result).
3. Implement your specification.
4. Submit your code on Moodle as a Git bundle (see § Submitting your code below).
5. Complete a brief individual self-assessment on Moodle.
6. Register as a team on Moodle for a checkoff slot.
7. Receive a “checkoff” as a team from a staff member. This should take approximately 4 minutes + 1 minute per person in the team. Be prepared to:
   • Give a short live demo of your feature. (2–3 minutes by a single team member)
   • Walk the staff member through the code and tests that you wrote or modified, by showing them your Git history. (1 minute per team member)
   • Answer a few clarification questions.

Rules

• Each team member should have a clearly distinct task and should be fully in charge of their part of the code.
• Don’t cheat—it’s okay to discuss ideas with classmates, but don’t share code or discuss implementation details except with your teammates.
• Don’t host your code in a public repository. Host it in a private repository on gitlab.epfl.ch configured such that only your team members have access.
• You may use AI coding assistants, but be sure that you can explain the code during the checkoff, and remember that you won’t have access to AI on the final exam.
• Similarly, you may consult resources such as textbooks or reference websites, but you must cite them and be able to explain any code or ideas you took from them.

Topic choice

You can pick any topic for your unguided callback, but:

• Your callback must be based off of one of the team members’ solutions for a previously completed lab.
• Your callback should be of the right scope: aim for approximately 30–45 minutes per person for the code + 20 minutes per person for the tests. We expect larger teams to achieve more than smaller teams.

Grading

The unguided callback is graded out of 10 points, based on the checkoff:

• Proposal quality
  • Clear, unambiguous, and well written: 1 point
  • Unclear, ambiguous, or poorly written: 0 points
• Proposal scope
  • Appropriately scoped: 1 point
  • Too ambitious or too simple: 0 points
• Correctness and completeness
  • Working demo with reasonable features and few or no bugs: 2 points
  • Mostly working demo with some bugs or some missing features: 1 point
  • Code submitted to Moodle is rejected by the grader, demo has severe bugs, or feature is trivial: 0 points
• Code quality
  • Clean, simple, functional code: 1 point
  • Overly complex, poorly organized, or overly stateful code: 0 points
• Documentation
  • Documentation and relevant require-ensuring annotations on each new function: 1 point
  • Missing documentation or pre-/postconditions: 0 points
• Git history
  • Clean commits with detailed descriptions of changes, in a private repository: 2 points
  • Clean commits without descriptions, in a private repository: 1 point
  • Sloppy history, no Git history, or repository left public: 0 points
• Tests
  • Mostly complete: 2 points
  • Incomplete: 1 point
  • Not present or not compiling: 0 points

Prior to receiving a checkoff, each team member must fill an individual self-assessment questionnaire on Moodle. This helps us detect grading discrepancies, and it helps you reflect on your performance. Submitting a self-assessment is mandatory, but your answers will not affect your grade.

Scores are individual, per EPFL policy. We may adjust scores based on a review of overall grading patterns. The staff member giving you your checkoff may ask for a score review in corner cases.

The unguided callback is worth 10% of the overall unguided assignment score. (The other 90% comes from the unguided lab. Together, the unguided lab and callback make up 20% of the overall lab score. This is also explained in the course policies.)

If you are not satisfied with your score, you may challenge it. You have two weeks to do so, starting from the moment scores are published; after that, your score is final. To challenge your score, make a private post on Ed, and explain where you disagree from the original score. Include instructions on how to run the demo. A TA (PhD student) or professor will compile your code on their own machine based on your Moodle submission and decide on a new score. This score may end up being lower than the original one.

Submitting your code

Submission is on Moodle, as usual. However, to preserve your Git history, you will submit your work as a Git bundle: a single-file copy of a repository. Use the following command to create submission.bundle:

$ git bundle create submission.bundle --all

The auto-grader on Moodle will just check your bundle and run your tests; the score that it returns is not used directly. If the code you submitted to Moodle doesn’t compile, you will get a 0 in the “Correctness and completeness” section in the rubric above.

Preparing for the checkoff

As a reminder, the unguided callback is graded by a checkoff with a staff member. Checkoffs will happen in selected help session rooms. Here is how the checkoff will work:

Before your checkoff

• Register (as a team: no need to register individually!) and fill in your self-assessments (individually!) on Moodle: If you come without a registration, or without all self-assessments completed, you won’t be able to get a checkoff.

• Rehearse: The checkoff is very short, and we will unceremoniously cut you off if you run over. Review the grading scheme and the description of the checkoff to know what is expected of you and exactly how long you have for each part.

On the day of your checkoff

1. Arrive on time: Be there at the start of your scheduled slot.

2. Be flexible: Since registration slots are 1 hour long, you may have to wait for up to 50 minutes. Please bear with us in case of delays.

3. Prepare your materials: Have the following ready on your computer.

   • Your demo, ready to run.
   • Your proposal.
   • A Git log with diffs for each student’s changes:
     git log --graph --author=“Name” --patch first_commit~..
     You can find first_commit by consulting the output of git log.

4. Wait for a staff member to come to you: Once you are ready, raise your hand. We will move around the room.

5. Leave the room when done: This way staff members can easily identify who is waiting.

To comply with EPFL rules, your staff member will not be able to give you a score right away. We’ll post scores on Moodle within a week.

Example specification

Stepwise calculator

Spec: Implement a new function stepwise(e: Expr) that takes an expression and prints the result of evaluating e step by step (one reduction at a time, e.g. (7 + 1) * (4 - 2) → 8 * (4 - 2) → 8 * 2 → 16. Implement two versions and compare their efficiencies: one that works with Expr directly, and one that converts the expression to Polish notation, then repeatedly alternates between printing the expression and reducing the last operator of the expression.

Course concepts: Recursion, evaluation by substitution

Work distribution: V will implement the recursive version; C will implement the Polish-notation version.

Callback suggestions

Below are some suggestions for inspiration, but we hope most of you will come up with your own ideas! In all cases, make sure that you create adequate tests in addition to implementing the functionality.

Find

FFP3 (3-4 people)

Extend find with new kinds of filters (this will require modifying the supporting library to expose other properties of files and directories, the command-line interface to expose new flags, and the testing code to mock that data). Think carefully about how to test your new filters!

Baby’s first sentence (3 people)

Generalize the interface of find by allowing combinations of filters, such as -name foo -and -size +200c, -name foo -or -size +200c, or -not -name foo. Do you need a parser to support arbitrary combinations of filters? Or have we already seen an easier way to represent and evaluate complex expressions? (hint).

Boids

Loopy times (3-4 people)

Explore unguided geometries in the boid world: wrap the world on a torus, add wormholes to transport boids across the board, use non-Euclidian distances to compute forces, etc.

Not all the same (3-4 people)

Invent multiple new boids classes and vary their speeds, colors, and behaviors: perhaps some boids escape certain forces; perhaps some boids have more influence on others; perhaps some boids chase other boids; etc.

Road work ahead (3-4 people)

Include obstacles or environmental hazards. They should affect how a boid behaves: either by wanting to avoid them or by affecting their velocity/position. Some hazardous zones such as wind currents could move around the world.

Calculator

Can it cook rice? (3-4 people)

Add a separate type of logical (boolean) expressions to the calculator, with operators like and, or, not, etc. Add a conditional construct (if) to the main type of expressions, using your new type of logical expressions for the condition in the if. (Suitable for 2 people. With more, add additional constructs beyond if, like while or do … while.)

Can it run Doom? (3-4 people)

Add an additional context for functions and add support for calling them. Function calls need to have the correct amount of arguments. Consider and define how should function parameters using existing variable names behave!

Anagrams

Not wet (3 people)

Change the sentence-anagrams enumeration algorithm to produce results unique up to word permutations (that is, different sentences in the output cannot have the same words in different orders). Your algorithm should eliminate permutations as it computes anagrams (and not eliminate them after the fact).

Scalashop

Rose-tinted glasses (3-4 people)

Add one new image filter per team member.

Negative examples

Below you will find some negative examples of what your callback should not be, together with a short explanation why it is not ideal.

Boids feeder

For boids, add the possibility for a user to click on the canvas to make some food appear. Then boids will be attracted towards the food. Once consumed, boids grow larger and their physical inertia increases.

This proposal would require understanding the simulation web interface and extending how it interacts with the server. Unlike the “Road work ahead” proposal, this one requires implementing client-side user interactions. If you have not worked with similar code before, this is too much work for the scope of the callback.

Colorful flock

For boids, assign random colors to individual boids.

This is too little work. If additionally there is a change which requires extending the UI (like generating random shapes), then it would be a balanced callback.

Operating on numbers

For calculator, add new operators (power, modulo, logarithm, etc.) and handle them in the simplifier/evaluator/printer.

These changes are very analogous to the existing features, making this callback too simple. If additionally these new operators are supported in the parser, then it would be a balanced callback.

© 2023–2025 EPFL. All rights reserved.