This is guidance for volunteers for how to create a new project for the piscine.
You do not need to read or understand this guidance in order to take the piscine as a trainee.
You can also see how we present these goals to our candidates in the Piscine prep, as well as the expectations we set for candidates.
The goals of the piscine are:
- Filter out graduates from ITP who are unlikely to get and thrive in a job in software.
- This may be for reasons of knowledge, understanding, commitment, or team-work.
- This may be because the trainee decides that this isn't for them, or because CYF assesses that this isn't for them.
- We want anyone who is ready to do the SDC and will realistically get a job after it to thrive in the piscine. But we also want to sign-post those who aren't realistically ready to get a job.
- As much as possible, we would like to be able to give suggestions to those who aren't ready about what action if any would help them to be ready (e.g. practice functions, practice breaking down problems, practice English language, etc).
- If a trainee is unlikely to get a job in a practical time scale, it's better for them to realise this early and decide to drop out, rather than waste more of their (and volunteers') time.
The goals of the projects in the piscine are:
- To test understanding of the concepts they were meant to learn in ITD and ITP. They should not require knowledge of significant topics that were not covered in ITD or ITP.
- To stretch the trainees and require them to deliver high quality results in a limited time. We should not give them step-by-step instructions for everything they need to do - they need to work some things out for themselves.
- To practice the skills learnt in ITP, gain experience, and see if the trainee is interested in doing more.
- To produce examples of well-done work which could be included in a portfolio.
Some projects will be done in groups, and others as individuals. If your project is better suited to one or the other, say so.
Your project description should be in a README.md file in a top-level direcetory of this repository named after your project, e.g. "Project-Song-Data" or "Project-Alarm-Clock". Any additional files needed by the project should also be in that directory.
Your project should at least list an introduction, a list of requirements, and a rubric. Additional sections are up to you.
State whether the project is intended for an individual trainee, a group of trainees, or either.
Your project should be able to be completed by a trainee (or team of trainees, for group projects) of ITP in no more than a week. This means roughly 20 hours of work, end-to-end, per person.
It's ok to include stretch goals in your project, but these must not be part of what's assessed. Some trainees quickly get through projects, and giving them more things to do with their time is useful. But many trainees get distracted by stretch goals when they haven't completed the main project. Make it unambiguously clear that stretch goals are not assessed, and they should only ever be attempted after the core project is completed.
We do not expect sample solutions alongside project specifications.
Is your project about making a clean UI? Is your project actually about making one particular widget and you don't care about the surrounding UI at all? Is your project really about processing data and just outputting an unstyled <ul> is actually fine? Be explicit about what is expected.
Trainees will waste days building a pretty UI if you don't tell them not to. Don't make them waste their time if a UI isn't important.
Also, reflect this in the rubric: If they have completed everything else, it's fine if they spent some extra time making it pretty. But if you told them not to worry about a UI, and they spent time making a pretty UI but didn't complete required features, they have failed.
It's ok to reference terms without explaining them and leaving the trainees to Google them.
It's also ok to link to a useful explanation that you recommend.
It's also ok to fully explain something in your project.
Consider which is most appropriate for the things you're trying to teach and test.
At this stage of a trainee's education, it's useful to see how trainees respond to ambiguity, but we don't have enough contact time with them to really explore ambiguity and discuss trade-offs.
Accordingly, try to be specific about anything that may be relevant in an assessment rubric. It's ok to leave things unspecified, but if we're going to be assessing on something, we should be explicit in the requirements what we expect.
When trainees fail, we need to tell them why they failed a project. Don't create opportunities for trainees to be surprised or disappointed by those reasons.
The outcomes of these projects will determine who we support to continue learning and get jobs. This affects people's lives. We need to be fair in our decisions.
Rubrics should be as objective as we can make them. Ideally they contain a series of boolean statements that can be easily tested without significant time with individual trainees.
By clear in the rubric what the threshold for success is. Probably it is yes answers to all questions, but if there are valid alternatives, or things that can be skipped, say so.
We assess projects in two ways:
- Manually comparing the submitted project against its rubric. This can be done as soon as the project as submitted (which must be by a deadline).
- Asking the trainee two high-level questions in an interview (which may yield lower-level questions):
- How does (feature x) work? (e.g. "How did the number 7 appear on screen here?" or "What caused this pop-up to appear when my mouse moved?")
- Explain (play computer for) this block of code.
The interview happens at the end of the Piscine, and the assessors may pick any of the projects to assess this way.
Probably the answer is "A GitHub repo, a git commit hash, and a link to a deployed website". Say so.
Make sure that whatever is submitted is sufficient to evaluate the rubric.
We include a git commit hash in here to help enforce that the project must be completed by a deadline.
Some projects are intended to be completed in a group. Group sizes are expected to be 3-4 trainees, and do not include non-trainees (i.e. there is no external PM or Tech Lead).
In group projects, we require an equal split of features between the trainees.
When specifying a group project, make sure four people can reasonably be working on their own feature in parallel. They only have a week to complete the project, so if one trainee can't be working until another is finished, this is bad.
At assessment time, we expect every trainee to be able to talk about every line of code in their project, even the ones they didn't write. It is up to the trainees how they ensure this.
Each project here should be self-contained; projects should not extend existing projects and assume they have been built.
It's fine to rely on prerequisite knowledge as long as there is a link to resources which would explain that prerequisite at the correct level.
Rule of thumb: a person should be able to complete a project without being part of CYF, and without having done any of the other projects.