How to host a school hackathon for computing

A hackathon is one of those events that tends to sit in the head of computing's bottom drawer of good intentions. Most teachers have been to one, most can see the case for running one, and most have not quite found the week in the year to make it happen. The first one is genuinely the hardest because none of the templates exist yet.

This guide is for heads of computing or KS3 leads thinking about hosting their first one, or refining an event that ran last year and only half worked. It covers the choice between a one-day and a week-long format, how to structure the problem-solving so pupils actually lead it, where the NCCE Teach Computing materials are most useful, and how to find industry or university partners without spending months on outreach.

A school hackathon is not a scaled-down version of the start-up events many adults associate with the word. It is a tightly facilitated learning event, with a clear pedagogical purpose, that happens to use the energy and time pressure of a hackathon format. Pupils are not there to build a product. They are there to apply computational thinking and basic programming under conditions that look more like real engineering work than a typical lesson allows.

Before sinking time into planning, it is worth being clear about what a hackathon can do that a regular sequence of computing lessons cannot. The honest answer has three parts.

First, hackathons compress problem-solving into a window short enough that pupils have to make real engineering decisions: What to build, what to leave out, when to debug rather than rewrite. These decisions are very hard to recreate in a standard lesson where the task is usually fully specified by the teacher.

Second, the social shape matters. A hackathon is collaborative, public, and a bit competitive. Pupils who are quiet in a normal lesson often surface different strengths in a team that has to produce something by 3pm. Confident programmers learn what it feels like to depend on teammates who are not.

Third, the curriculum advocacy. A well-publicised hackathon is one of the better ways to put computing in front of the rest of the school: Other departments, senior leadership, parents at the end-of-event showcase. For a department arguing for option blocks or for resource, a hackathon does work that no scheme of work can.

One of the biggest planning decisions is the format. The two main shapes are a one-day event (usually a Saturday or an end-of-term collapse day) and a week-long event spread across lunchtime and after-school sessions. Each has trade-offs, and the right choice depends on your school more than on any general principle.

A one-day event is easier to run for the first time. External mentors are easier to recruit for a single day. The energy stays high because the time pressure is real. The downside is that the technical ceiling is genuinely limited: Pupils have maybe six hours of build time after the briefing and team formation. For Year 7 and 8 this is often fine. For KS4 and KS5, it can feel thin.

A week-long event allows a meatier technical project and lets pupils think between sessions. The downside is that it is harder to keep momentum across five days. The drop-off between Monday and Friday can be substantial unless the event is built into the timetable as a collapse week.

For a first hackathon, most departments find the one-day format easier to deliver well. Once the team has run one event, the week-long version becomes a more manageable next step.

The brief makes or breaks a hackathon. A brief that is too tightly specified turns the event into a standard practical lesson with snacks. A brief that is too open leaves pupils flailing for the first three hours. Most experienced organisers settle on a clear theme, a small number of specific constraints, and genuine room for pupils to choose their own approach within those constraints.

A theme that has worked across multiple settings is 'build something useful for someone in our school'. The target user can be a specific year group, the librarian, the catering team, the SENDCo. Pupils interview the target user for ten minutes at the start, build something based on what they hear, and present it back at the end. This gives the brief a real audience, a real problem, and a built-in evaluation criterion.

Other themes that tend to work: A specific challenge from a sponsor, a competition tied to a national event like the Bebras challenge, or a tightly scoped brief like 'build a tool that helps your team revise for a specific GCSE topic'. The worst briefs are vague references to social good, which usually produce six teams making slightly different recycling apps with no real engineering content.

Whatever format you choose, the structure within it matters more than the total time available. The pattern that works most reliably is a clear sequence of stages with timeboxes, mentor check-ins at predictable intervals, and a visible showcase at the end.

For a one-day event, a workable shape is: 30 minutes of arrival and welcome, 30 minutes of briefing and user interview, 30 minutes of team formation and ideation, three to four hours of build time broken by lunch, 30 minutes for preparing the demo, and 45 minutes of presentations and judging. The temptation to give more build time and less framing tends to be counterproductive: Pupils who jump straight to coding without thinking through the problem usually spend half the day rebuilding work they should not have started.

For a week-long event, the same shape stretches across five days. Day one is briefing and team formation. Day two is a paper prototype and a project plan. Days three and four are build time. Day five is final build, demo prep, and the showcase. The midweek check-in on Wednesday is one of the most important interventions: It catches teams that are stuck before they lose the rest of the week.

Teams of three to five tend to work better than pairs or larger groups. Smaller teams cannot cover the range of work involved; larger teams develop passengers. The move that tends to work best is deliberate mixed-ability pairing rather than letting pupils self-select. Pupils who self-select tend to form teams of friends, which produces a few extremely strong teams and several extremely weak ones.

A workable approach is to ask pupils to fill in a short pre-event form with their experience level, and to form teams that pair stronger programmers with pupils who want to build presentation, design, or research skills. Roles within a team can be made explicit: A lead developer, a co-developer, a researcher who runs the user interview, and a presenter or designer. Roles can rotate during the day.

The shift towards pupil-led problem solving is the central pedagogical move, and it requires teachers to step back further than usually feels comfortable. The job of teachers and mentors during the build is to ask questions rather than provide answers. 'What have you tried?' 'What is the smallest version of this that would work?' A hackathon where teachers solve every problem for the teams produces less learning than a regular lesson.

External partners can add a lot to a hackathon: Industry mentors who bring real-world credibility, university student volunteers who pupils can see as plausible future selves, and judges who broaden the audience for the final presentations. Most schools find that partner recruitment is easier than they expect once they actually ask.

For industry partners, the practical starting point is the parent body. A short message to parents asking if anyone works in software or has contacts who might mentor often produces more responses than cold outreach to companies. Local tech employers, particularly small and medium-sized firms, are often more responsive than large multinationals.

For university partners, the computer science outreach teams at most UK universities have explicit budgets for school engagement and will often send student ambassadors or PhD students as mentors. The contact route is usually through the school liaison officer. The NCCE's regional network of Computing Hubs is another route: Most hubs have university partnerships and can broker introductions.

The BCS, the Chartered Institute for IT, runs a school ambassador programme that connects schools with industry professionals. Code Club and CyberFirst have similar networks. None of these are perfect, but each one shortens the outreach time substantially compared to starting from scratch.

The National Centre for Computing Education's Teach Computing curriculum is the most useful free resource for the pedagogical scaffolding a hackathon needs. Several of the KS3 units are well suited to feeding into one.

The Year 8 'Introduction to Python programming' unit and the Year 9 'Data science' unit are the most direct fits. If the hackathon sits at the end of one of these units, pupils arrive with the specific technical preparation they need. If it sits at the start, the hackathon serves as a motivating context for the unit that follows.

The other useful NCCE resource is the Isaac Computer Science platform, with self-paced material at GCSE and A-level. For older pupils, working through a relevant Isaac topic in the weeks beforehand tends to lift the technical ceiling of what their team can attempt. The NCCE's regional Computing Hubs are usually willing to talk through the planning of a first hackathon and connect you with other schools that have run one.

The strongest hackathons do not produce polished software. They produce learning that is visible to the pupils involved and to the rest of the school. The standard measures most organisers default to (number of teams, quality of finished projects, prizes awarded) are weaker indicators than they look, because they confuse the event's outputs with its purpose.

More useful measures: Whether pupils talk about the event a week and a month later. Whether pupils who had not previously considered Computer Science at GCSE are more interested in it during options conversations. Whether teams that struggled in the middle of the day produced something they were proud of by the end.

A short post-event pupil survey, run a week after the hackathon rather than on the day itself, tends to surface the more honest version of what worked. The most common useful feedback is usually about the brief, the team composition, and the level of mentor involvement. It is rarely about the technical kit, which is what first-time organisers tend to spend most of their planning energy on.

Pulling the threads together, here is a checklist for the four to six weeks before your first hackathon. Most of these prompts take a few minutes to think through, but missing any single one tends to surface as a bigger problem on the day.