The goal of the Piscine is to assess trainees’ current knowledge. We are not aiming to teach them any new skills. To be fair, we need to give everyone the same level of support, and we have set that same level at none.

As a facilitator, your goal is not to help the trainees with their projects. It is to unblock any logistic problems people run into with the course.

As an assessor, your goal is to provide meaningful feedback to help the trainees to grow. For demos, we provide this feedback after each demo. For projects, we provide this feedback after the interview is complete.

There is currently one exception to this: Breaking down a project to work on as a group is a skill not currently taught in ITP. Until this is resolved, we host a single, consistent workshop on this in the first sprint.

To smoothly run a Piscine, we ask that that the volunteers running it:

• Attend a weekly meeting to sync on how things are going and flag anything that needs to be consistently resolved.
• Assess projects against their rubric as early as possible after the submission deadline.
  • Leaving this work to batch up at the end is painful, and makes it hard to course-correct any major issues.
  • Wait until the submission deadline - often trainees edit their submissions after they post them.
  • Use the shared template for writing up feedback - this helps us to be consistent, to prepare for interviews, and to collate feedback to present to trainees at the end of the course.
• Fill in the trainee tracker spreadsheet as we go.

On class days, we:

• Attend each week.
• Start punctually at 10:00.
• Assign trainees to groups randomly. Make sure that trainees are working in different groups each week. Ideally there should be 0 overlap week-to-week.
• Treat showing up late as a failure.
• Sometimes take 30 minutes of the ITP class to present demos to the ITP class.
  • We never do this in the first week. First demos are generally bad.
  • But we limit this to 30 minutes to not disrupt the class too much - if we have more demos than that, we give them separately from ITP.
  • Warn our trainees this will be the case in advance, so they know what audience to prepare for.

We assess demos against 6 rubric points. A demo must pass any 5 of the 6 points to pass. Trainees must pass at least one demo to pass the course.

We give feedback after every demo, including a run-down of each rubric point.

These are typically our trainees’ first demos. We expect significant improvement through the course. The first sprint is expected not to be good (but sometimes is!).

Clearly introduce the topic of the demo.

Someone watching should be able to state the topic of the demo in one sentence. This topic should match how the trainee introduced their demo. If a trainee said their demo was about writing clear code, but it was actually about how to debug a test failure, they missed this.

The topic must not be "I will tell you about my project". It must be more specific than a project overview.

Explain what was done

Someone watching should be able to state what you have done in one sentence.

Explain the reasoning behind a choice.

Someone watching should be able to explain why you did at least one thing a particular way (and why it was a better choice than alternatives).

Show relevant code or artifacts (e.g. a website, a ticket, an discussion).

Someone watching should be able to identify at least one artifact of your work.

Stick to your time limit.

You should know how long you have for your demo, and stick to that time. You will be given a warning when you're running low on time. If a trainee is not done speaking at the time limit, they missed this. Finishing early is fine.

(Stretch goal): Ask questions.

Someone watching can state at least one question that was asked of the audience that is not "any questions?". The point of this is to engage the audience and get them thinking/caring about the demo. The question should generally be rhetorical - you don't have time to wait for answers.

To run a demo:

• Make sure someone is keeping time. They should clearly indicate when the trainee has 30 seconds left, and when they hit their time limit.
• It’s ok to let the trainee keep talking for up to about 30 seconds after the time limit, but don’t include any content after the time limit in your assessment.
• Give feedback on every demo. Make sure to include an assessment of all six rubric points, as well as any general feedback.
• Note the score of the demo, and at least one sentence of feedback, in the tracker.

The last assessment in the Piscine is an interview. The key goals of the interview are:

• Verify that the trainee actually understands the code they’ve submitted. If they produced it with ChatGPT and can’t explain it, they need to focus on code understanding before proceeding.
• Verify that the trainee can discuss code and technical ideas. This is similar to what demos are assessing, but in a more interactive scenario. This is an important skill to get a job.

Each interview is schedule to be 15 minutes. It is ok to run over by 5 minutes. We leave at least 20 minutes between interviews, to give time for things to go wrong and to write up feedback.

If something goes completely wrong (e.g. internet connections drop), try to recover, but if you think an interview can’t be fairly completed, assure the trainee they’ll be treated fairly, and we’ll work out how, e.g. reschedule.

Try to leave the interviewee feeling positive (that they could complete some tasks), but do not mislead them about outcomes. Do not share the outcome of their interview with them in the interview.

After all of the interviews are completed, we gather (ideally on the same day) to make final decisions as a group.

We record all interviews, so that we can get second opinions if needed. We make sure we’re calibrated such that everyone would give the same pass/fail decision.

Aim to come to a pass/fail decision on the interview that day, and write up any feedback within 3 days so it can be shared with the trainees.