For volunteers
How to run a Piscine
Intentions
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.
If you feel a rubric clarification is needed, coordinate with the other assessors before providing this clarification. We need to make sure everyone gets the same clarification.
Below is a list of learning objectives that are not currently taught in ITP, and how we handle them in the Piscine:
| Learning Objective | How we handle it |
|---|---|
| Break down a project to work on as a group in parallel | We teach this in a workshop in sprint 1 |
| Test a project reasonably thoroughly | We only require one non-trivial test |
| Anticipate and prevent time-zone and daylight-savings bugs | Time-related project briefings, contain warnings and guidance |
Routines
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.
Assessing demos
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. This feedback, including a score, should ideally be given straight after the demo, and absolutely no later than the same day.
Where possible, we suggest having two assessors in a demo session, to get more opinions and discuss any uncertainty.
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.
Interviewing
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.
Pre-Piscine Briefing
Before the Piscine starts, there will be a meeting to brief you on how the Piscine works, and answer any questions.
You will be notified on Slack when this meeting will be.
For trainees
Before the meeting, think about any questions you have. What are you not sure about?
Make sure you attend the meeting.
For volunteers
Make sure everyone knows:
- What the schedule of the Piscine is. When are people expected where?
- What people should do before the first session.
- What’s expected of trainees in the first session, and in the first week.
- How trainees should be working as a team.
- How trainees will be assessed.
- Which projects, demos, and interview trainees need to pass, and what it means to pass them.
- How much to style your projects, and why.
- When trainees are expected to show up in person or on calls.
- How trainees will hand in their projects.