The goal of the Checkpoint 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 Checkpoint:

To smoothly run a Checkpoint, 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.

Before class days

• Tell the trainees what time they should expect to do demos, particularly if they’re doing remote demos.

On class days

• 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. 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.

You can see the rubric on the Demo block of each Checkpoint day-plan.

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 Checkpoint 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.

Try to come to a clear yes/no conclusion, but it’s ok if you can’t - someone else can re-watch the interview and give a second opinion (or if needs be, we can even do a follow-up 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.

Before the Checkpoint starts, there will be a meeting to brief you on how the Checkpoint 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 to answer the following questions during the briefing.

• What is the schedule of Checkpoint? When are people expected where?
  • Demos happen on the first three Saturdays - they are expected to be available online/in-person from 10am-5pm and will be notified when demos are happening.
  • Projects begin on each Saturday and are due in the following Thursday - they have six days to complete them, and should be available for communication from their team during this period.
  • Note: The intended structure of Checkpoint is three consecutive weeks of work but this may be affected by bank holidays or other events, so check with the edu team about the possibility of any changes before delivering this briefing
• When are trainees expected to show up in person or on calls?
  • As alluded to above, for each of the 3 Saturdays they should be fully available online/in-person from 10am-5pm.
  • They will be notified in advance whether their Saturday sessions will be handled remotely or in-person.
  • This expectation is a requirement of passing Checkpoint, we will try to accommodate extenuating circumstances if they let us know with ample advance but generally trainees will not pass Checkpoint if they don’t attend as requested.
• What should people do before the first session?
  • In their own time, they should work through the preparation steps to ensure everything is covered.
  • Make sure to explain the prep for the first demo; all other demos will be about Checkpoint projects, this one will be based on something they’ve already done (e.g. in ITP).
• What’s expected of trainees in the first session, and in the first week?
  • They must deliver a demo and be prepared to engage in their first group project.
• How should trainees be working as a team?
  • Plan together - Outside of the demo slots on a Saturday, they are expected to be working and planning with their group.
  • Work together - They may want to work on code their own, but they should be aware of, communicating about, and reviewing the work done by the rest of their team. They may be asked about any of the code in their project during the interview and they should be able to explain it!
  • Pair programming [optional] - Working together as driver and navigator is not required, but can be a really useful tool for productivity and collaboration.
• How will trainees be assessed?
  • Projects - A passing project must meet the rubric points listed for the specific project, as well as the project submission guidelines which apply to all three. They must pass their solo project and at least one of the two group projects. Note: projects are not marked for their styling, so CSS should be minimal and only serve to achieve basic usability and accessibility of the app.
  • Demos - Checkpoint demos are different from those they did in ITP, they are marked against a very specific rubric. To pass, they must hit five of the six rubric points. They will be given up to 3 chances to deliver a passing demo, and they must pass at least one.
  • Interview - The interview will take 15 minutes, and they will be asked three questions during it. They should be prepared to be asked about code and/or feature of any of their submitted projects, including code they themselves did not write.
• How do trainees hand in their projects?
  • Instructions for handing in projects will be given on Slack - pay attention!
  • Generally they amount to sharing a link to the repo, the hosted version of the app, and a GitHub SHA of the relevant commit from which we want to mark the project.