Getting Started

An Overall Timeline to expect:

The timeline below shows the preparation starting 6 months before the hackathon and the follow-up activities that continue for up to one year after the event: 

Defining the hackathon’s format, scope, and location  

Building your Organizing Committee:

To successfully organize a hackathon, it is recommended to establish a small organizing committee with clearly defined responsibilities. Depending on the size of the event, the committee can include the following roles: 

  1. Program Committee: Defines the scope of the hackathon, decides on the educational program and level, establishes a schedule, tasks, deadlines, and activities, and communicates them to the other committees, and selects and invites the participants. (We recommend inviting representatives of your partner organization to be invloved this committee.)
  2. Administrative / Logistics Committee: Manages logistics such as the venue, materials, and volunteer coordination. 
  3. Communication Committee: Handles communication strategy, website, social media, and outreach. 
  4. Sponsorship / Partnership Committee: Identifies sponsors and partners, manages sponsorship packages and collaboration agreements, all within an agreed timeline (The OQI global network can help you reach out to industry leaders for support and sponsorship.)
  5. Accounting Committee: Focuses on budgeting and financial management. 

Fundraising and partners: 

You may seek funding from the following sources: 

  • National agencies
  • Local industry partners (e.g., logistics, banking, pharmaceutical sectors)
  • Local innovation hubs (e.g., incubators, venture capital firms)
  • Quantum computing companies; if they are interested in supporting the platform, please refer to Section XXX for further guidance

When reaching out to potential partners, it is important to highlight that they can support the hackathon in multiple ways, both financially and non-financially. 

Examples of possible contributions include: 

If you have multiple sponsors, you may structure them into defined sponsorship tiers, as shown below. Under each tier, sponsors should include the logos or names of their partner organizations in a similar format. 

Here are some key arguments you can use to engage potential sponsors: 

  • Be part of the quantum computing and innovation landscape 
  • Support local talent and student inclusion 
  • Access and recruit top student talent 
  • Increase brand visibility and industry presence 
  • Engage with real-world challenges and emerging solutions 
  • Network with key stakeholders in the ecosystem 

Building Support in your Hackathon

Preparing outreach:

Outreach and communication are fundamental parts of the planning phase, during which you must create your strategy to keep your audience informed and engaged. 

The structure of the website

This structure serves as a guide for the information that should be included on the website, both before and after the hackathon. 

Take inspiration from the existing websites:

Selecting Mentors

When selecting mentors, local or regional PhD students in quantum computing are a good place to start. In a hackathon setting, mentors should demonstrate innovative thinking, problem-solving abilities, and good communication skills. They should guide and support teams without imposing solutions, while being mindful of respecting all voices within the team and ensuring that every participant is heard.

Below is an example guideline for mentors during the hackathon:

https://docs.google.com/document/d/16LsU9lgNuMvukI9j1AhLF17xvUCNkfQm3PdgqZ9WDdQ/edit?usp=sharing

Selecting Judges

Select judges with diverse experience across industry, academia, quantum computing, innovation, and the Sustainable Development Goals (SDGs).

The judging panel should include experts in quantum computing, as well as professionals from fields such as business, innovation, entrepreneurship, public speaking, and sustainability. These broader perspectives can provide valuable insights, even without direct quantum computing expertise.

Ensure that all judges are clearly informed of their roles, responsibilities, and evaluation criteria well in advance of the event, particularly those who are new to hackathons.

If some judges do not have a quantum computing background, ensure that they are not responsible for evaluating highly technical quantum-specific criteria. Instead, they can focus on areas such as innovation, feasibility, impact, presentation quality, and alignment with the challenge objectives.

Judges may also serve as keynote speakers or panelists. See Section XXX for more information.

Guidelines for judges:

https://docs.google.com/document/d/1XS2MPg9PZGqQy14o25RAgUYpQcWewHkgV3wxKmvpOxM/edit?usp=sharing

For a sample judging rubric and scoring framework, see Section XXX.

Getting your students ready

Pre-hackathon Training 

Before the hackathon, organizers should provide courses and workshops to ensure participants are well prepared depending on their backgrounds and level of knowledge in quantum computing. The hackathon learning experience is not only about the event itself, but also about the skills participants develop during the pre-hackathon training sessions, making this phase an essential part of the overall experience. 

Key Topics to be covered: 

Topics can cover both technical and non-technical areas. Below is an overview of some of the topics that may be covered: 

The resources section of this guide includes free materials on these topics, with some providers offering certification courses for a modest fee. If budget permits, these are preferable, as they allow students to interact with instructors and receive live support ahead of the hackathon. 

You may also choose to build this programme in-house with your teachers or local experts. 

For OQI-supported hackathons, the following pre-hackathon training programme has been followed across all hackathons: 

Participants selection

When selecting participants for a quantum computing hackathon, it is important to strike a balance between technical skills, interdisciplinary knowledge, and motivation to learn. Priority should be given to individuals with a foundational understanding of linear algebra, computer science, and programming languages such as Python. However, the expected prerequisite level should ultimately depend on the objectives and technical depth of the pre-hackathon programme. A background in quantum computing can be considered a plus, but should not necessarily be mandatory. 

To foster diversity and creativity, teams should also include participants from fields such as physics, engineering, mathematics, chemistry, and, where relevant, policy or sustainability-related fields (e.g., environmental sciences). Ultimately, the goal is to form teams that are not only technically capable but also collaborative, open-minded, and eager to innovate.

Selection criteria may also consider prior project experience, problem-solving ability, and a demonstrated interest in quantum technologies.

Communication Channels

Choose a communication platform that supports collaboration, transparency, and accessibility. Since teams are usually required to start working in advance, they should have an easily accessible communication channel before and during the hackathon. The platform should support team formation, file sharing, real-time communication, and allow mentors and judges to monitor progress and access submissions. It should also be user-friendly, accessible across devices, and capable of organizing discussions by team or topic. Common options include Discord, Slack, Microsoft Teams, or any communication platform already supported and commonly used within the university or organization. 

Technical Aspects

1. Problem framing and SDG alignment 

Strong submissions begin with a clear, specific connection to a Sustainable Development Goal rather than attaching SDG labels as an afterthought. We recommend the following procedure:

  1. Start from the SDG itself.
  2. Identify a specific and measurable sub-problem.
  3. Confirm that it reduces to a tangible computational task that can be mathematically formulated.
  4. Justify why quantum methods are appropriate for that task.

Below is an example workflow:

2. Challenge Development

Gathering the right expertise is a key responsibility of any hackathon organiser. Each challenge requires both SDG and technical expertise, as outlined below. Depending on the challenge format, this may be provided by domain specialists and quantum practitioners recruited in advance, or by the participants themselves. In all cases, the quality of the challenge depends on the quality of the expertise involved.

3. Recommended Methodology

Once the relevant expertise is assembled, SDG and technical perspectives should be developed in parallel and then combined. SDG experts refine broad sustainability challenges into concrete problems, while technical experts identify where quantum approaches offer an advantage over classical methods. Both are essential: without quantum understanding, problems may lack viable formulations, and without domain grounding, solutions may lack real-world relevance.

The two sides then converge on a single question: does the computational structure of the SDG sub-problem match the regime where the quantum algorithm has the potential for advantage? Mismatches are common and resolving them is central to challenge design. In Guided or Pipeline Challenges, organisers lead this process; in Open-Formulation Challenges, participants are expected to do it themselves.

4. The Spectrum of Challenge Complexity 

The level of challenge complexity determines how responsibilities are shared between organisers and participants. The table below summarises the key differences across challenge types. 

Across all levels, the common thread is scientific honesty: participants should know what they are optimising for, why quantum methods are being considered, and have considered whether and how their solution might improve on the classical alternative. 

The diagram below shows the spectrum of challenge designs and how work is distributed between organisers and participants. Grey boxes represent organiser tasks, while coloured boxes represent participant tasks. 

For guided and pipeline challenges, to keep submissions comparable and fairly evaluated while leaving room for creative approaches, we recommend organisers provide the following materials at the start of the hackathon:

  • A clear problem statement with a specific, measurable quantity of interest that both quantum and classical approaches compute, enabling a direct and fair comparison 
  • A recommended quantum algorithm with a justification of why it is appropriate for the problem’s computational structure
  • A dataset or data-generation procedure so that all teams work on comparable instances
  • An honest statement of current quantum limitations, so participants are not misled about expected outcomes.

For open-formulation challenges, the last point still applies, while the other materials are less relevant as decisions are left to participants. However, examples can still be useful to guide them. 

5. Submission Requirements

Each submission should address five components (outlined below), aligned with the evaluation rubric and a shared slide template. To ensure consistency, teams should not reorder or remove sections, so all submissions are assessed on the same criteria. 

For slide deck and code repository templates, organizers may refer to previous hackathon materials available in the:

https://hackathon.nyuad.nyu.edu/year/2025/

Here are a few GitHub repositories from previous winning teams that students could use for inspiration and reference when developing their projects:
https://github.com/OpenQuantumInstitute/Ghana-team-5.git
https://github.com/OpenQuantumInstitute/2025-team-mohituQ.git

6. Technical Evaluation Rubric 

Submissions are evaluated across five criteria by judges with backgrounds in quantum computing, advanced classical methods, and sustainable development. This rubric prioritises rigour and honesty over ambition: a well-defined, reproducible result will score higher than an impressive but unverified claim. The weights indicate the relative importance of each criterion. 

The weights below reflect the relative importance of each dimension:

Judges will focus most on Problem Formulation and Quantum Implementation, as these capture the core contribution.

Baseline and Benchmarking (40% combined) ensure that results are properly supported—weak or selective comparisons will be penalised.

Reproducibility (10%) acts as a gate: if the code cannot be run, marks may be deducted across criteria.

Selecting a Quantum Computing Platform

If possible, secure a platform partner to support your hackathon. There are generally two types of platforms, each with different advantages and limitations. 

  1. Hardware Providers

Examples: IBM, IQM, Azure, Pasqal, IonQ, Quantinuum, QuEra, D-Wave, Rigetti, Xanadu …

Hardware providers may offer free access to quantum hardware or computing credits. However, these platforms are often less beginner-friendly for students, are limited to their own technology stack, and may not always be able to provide dedicated technical experts to support participants during the hackathon. 

Pros & Cons: 

  1. Multi-Provider Platforms (Quantum-as-a-Service) 

Examples: Qbraid,  AWS, Quapp, OVH Quantum, Qcentroid, Classiq,…

These platforms provide access to multiple quantum hardware and software providers through a single interface. They are generally more technology-agnostic, often have experience supporting educational events and hackathons, and may be able to provide technical experts to assist participants. 

Pros & Cons:

You can use the following platform evaluation questionnaire to help navigate the available options. 

Questions for hackathon platform providers – Google Docs 

An Example of a Challenge: Membrane Design for Desalination (SDG 6)

This example illustrates the challenge design process as it would be completed by organisers preparing a Guided Challenge. The SDG target, computational bottleneck, and algorithm are all resolved before participants begin work, and the outcome of this process is what organisers hand to participants as the challenge framing. In an Open-Formulation Challenge, participants would work through these same steps themselves; in a Pipeline Challenge, they would instead be given a running desalination simulation and asked to identify where a quantum component could be inserted.

Step 1:  Select a specific SDG sub-target. 

SDG 6 (Clean Water and Sanitation) is too broad to act on directly. However, Target 6.1 calls for universal and equitable access to safe and affordable drinking water. In arid and coastal regions, desalination is one of the most viable routes to achieving this, but its energy cost remains the principal barrier to widespread adoption. The measurable quantity of interest is therefore the energy cost per litre of desalinated water.

Step 2: Identify the computational bottleneck. 

The dominant cost driver in membrane based desalination is membrane selectivity: a membrane that passes water while rejecting salt more efficiently requires less pressure, and therefore less energy. Improving selectivity requires predicting how Na+ ions interact with candidate membrane materials, specifically computing their binding energy to graphene oxide configurations. This is the computational bottleneck: evaluating thousands of configurations using accurate quantum-chemical methods is expensive with classical tools.

Step 3: Confirm the task is mathematically tractable. 

The binding energy of Na+ to a membrane configuration is a well-defined eigenvalue problem on the molecular Hamiltonian. Given N candidate configurations, the task is to find the one minimising binding energy subject to synthesis feasibility constraints.

Step 4:  Choose the quantum algorithm. 

VQE (Variational Quantum Eigensolver) is designed to approximate the ground-state energy of a Hamiltonian: E0 =min θ  ⟨ψ(θ) | H | ψ(θ)⟩ (1) The standard classical alternatives are Density Functional Theory (DFT), which is fast but approximate, and Coupled Cluster methods (CCSD(T)), which are highly accurate but scale as O(N7) in system size. Both struggle with strongly correlated electron systems, particularly those involving transition metals or open-shell configurations.

Step 5:  Verify that the problem matches the regime where VQE has the potential to offer advantage.

 VQE offers a potential advantage when the system exhibits strong electron correlation, when exact diagonalisation is computationally infeasible, and when classical approximations are known to break down. Graphene oxide membranes with functional groups or dopants introduce precisely this kind of correlated electronic structure, where DFT is known to underperform. The Na+ binding energy problem reduces directly to the eigenvalue problem VQE is designed for. After second quantisation and a Jordan–Wigner mapping, the qubit Hamiltonian takes the form: E0 =min θ  ⟨ψ(θ) | HJW | ψ(θ)⟩ (2)

Step 6: Define the challenge. 

The agreed challenge is to use VQE with a UCCSD ansatz to estimate the Na+ binding energy of a small membrane fragment, benchmark it against a DFT baseline and (where feasible) a CCSD(T) reference, and extrapolate the scaling to larger system sizes. This outcome is what organisers provide to participants in a Guided Challenge format. 

Definitions

Definitions of commonly used language in the guidelines:

• Hackathon Challenge: A problem statement that connects a specific UN SDG target

to a computational task.

• Hackathon Submissions: A team’s response to the challenge, output depends on the

methodology used by the organisers (See section 4)

• Hackathon Organisers: The individuals or the organisation (Often Universities or Re

search centres) that are responsible for hosting and running the hackathon. Organisers

make the decisions regarding challenge complexity and the final scoring grid.

• Hackathon Participants: The teams (Often made up of students) who develop and

submit solutions during the hackathon.

Reference Material

The challenge development process outlined here closely mirrors the review and scrutiny applied to Open Quantum Institute (OQI) use case teams. Both hackathon participants and use case teams are expected to complete an educational module designed by OQI and Qplaylearn, which establishes the core expectations required when scoping and developing an OQI use case. Since a hackathon submission can be viewed as a highly compact use case, these guidelines draw heavily from that shared foundation. The module can be found below, and we encourage all involved with the hackathon to complete it.

https://oqi.qplaylearn.com

An OQI use case should integrate thinking about its impact on the SDGs right from the initial stages of development. It is crucial to the use cases OQI fosters that impact is treated as a foundational criteria throughout their development rather than an afterthought. OQI has developed an impact framework to assess the potential benefits of use cases for people, planet, and prosperity. Participants are asked to reflect which SDGs their solution specifically impacts, and whether their approach might create unintended consequences on other SDGs. Even within a hackathon’s compressed timeframe, participants are encouraged to explore the OQI Impact Tool to help map the real-world implications of their work.

https://oqi-impact-tool.app.cern.ch

Launch your event

This section of the guide helps you know what to do during a successful quantathon. Understand what it takes to launch it, based on the QPEG mission.

Two weeks before the event, you should ideally: 

  • Add all participants to the communication platform
    • Create separate channels by team so participants can start brainstorming and communicating early 
  • Send all preparatory materials
    • Challenges/problem statements
    • Evaluation/judging rubric
    • Slide deck template for final presentations
  • Organize an online briefing session with mentors
    • Explain mentor guidelines
    • Clarify expectations, support role, and schedule
  • Organize an online briefing session with judges (if possible)
    • Walk through the judging criteria and scoring process
    • Align expectations across judges
  • Schedule onboarding with the platform provider
    • Ensure participants know how to use the platform/tools
    • Especially important if this was not already covered during the pre-hackathon phase

Students actions before the hackathon 

Students should prepare before the hackathon by understanding the challenge type, reviewing the provided materials, and developing initial ideas or approaches in advance. Preparation should vary depending on the challenge methodology chosen by the organizers. 


Hackathon Schedule

Here is an example of a three-day schedule: 

Pitch in nutshell template

Pitch slides template

Speakers

During the hackathon, inspirational talks can support ideation, while technical keynotes can aid development. Speakers can include industry leaders, academic researchers, and former participants with inspiring career paths, and may also serve as judges.

Mentors’ Roles and Importance

Mentors play a key role in guiding teams throughout the hackathon by:

  • Encouraging openness to ideas during the early stages.
  • Asking guiding questions and providing constructive feedback.
  • Supporting curiosity and problem-solving instead of directly giving answers.
  • Helping teams define realistic and achievable project scopes.
  • Participating during coding and development phases when needed.
  • Promoting teamwork, active participation, attendance, and punctuality.

Mentors should generally be assigned to a specific team to provide consistent guidance throughout the hackathon. Judges may share feedback with mentors, who can then help teams improve their work. In some cases, floating mentors may also be available to support multiple teams when needed. 

The Judging

Judges will already have interacted with students throughout the hackathon and may therefore have prior knowledge of the teams’ progress and projects.

Depending on the number of teams, final presentations can last between 5 and 10 minutes per team. We recommend providing a standard presentation structure aligned with the judging criteria to help teams clearly communicate their work (see Section X).

After each final pitch, judges may ask follow-up questions (approximately 3–5 minutes) to better understand the team’s approach, technical implementation, sustainability impact, and decision-making process. Since judging panels may include both technical experts and SDG/sustainability professionals, questions can address both the technical and societal aspects of the project. Judges are encouraged to remain supportive and constructive, especially if a team did not fully complete their project, by asking guiding questions that allow students to explain missing components, intended next steps, or technical elements they were unable to fully demonstrate during the presentation.

A scorecard with clearly defined evaluation criteria (example in Section 5) should be provided to judges to support fair and consistent scoring. After all presentations, judges should hold a 30–45 minute discussion to review scores and finalize decisions before publicly announcing the winners.

The judging phase may also include a more in-depth review of the code and technical implementation produced by the teams. The platform provider or technical support team may assist the judges by preparing a short technical code review for the top-ranked teams. Based on these additional technical findings, judges may collectively decide whether to adjust the final ranking. Priority should always be given to the technical quality, originality, and implementation strength of the project. 

Possible questions for the technical code review may include: 

  • Is there a clear README.md in the GitHub repository with instructions for judges on how to run and evaluate the project?
  • Does the code run successfully and reproduce the results claimed by the team?
  • Does the project use a real QPU (Quantum Processing Unit) or quantum hardware component?
  • How clean, organized, and well-documented is the codebase?
  • What is the quality of the machine learning components used to support the quantum computing workflow?
  • What is the quality and relevance of the datasets used?
  • How strong and well-justified is the claimed quantum advantage?
  • How did the team address quantum circuit depth, noise reduction, and qubit optimization (when applicable)?
  • Does the project reference scientific papers, and how strong is the implementation compared to the referenced work?
  • Did the team mainly rely on copied AI-generated code or demo notebooks, or did they demonstrate meaningful customization, originality, and technical understanding?

Award Ceremony and Prizes

  • Distribute prizes to the winning teams (e.g., 1st, 2nd, and 3rd place awards).
  • Ensure photos are taken during the prize ceremony and team recognition moments.
  • Distribute participation certificates to all teams and invite participants on stage when receiving them.
  • Ensure participants are informed about the prizes and award categories before the hackathon begins.
  • Publish the final results on the event website.
  • Share the results through social media, newsletters, news outlets, and other communication channels.

Prizes should ideally focus less on one-off rewards and more on helping students build momentum in their early careers and continue their engagement with quantum technologies and sustainability. Possible prize formats include: 

  • Internship opportunities, for example when a company commits to offering internship positions to one or multiple members of a winning team.
  • Invitations, sponsored visits, or participation opportunities for local, regional, or international events related to quantum technologies, sustainability, or innovation.
  • Connections with future OQI hackathon organizers in the participants’ region to help students remain engaged within the growing OQI and quantum ecosystem.
  • Cash prizes or any non-sentimental prizes (while not necessarily recommended by OQI, they are always appreciated by participants).

Keep the momentum going

A hackathon should not end once the event is over. Maintaining communication, supporting promising projects, and creating future opportunities are essential to maximizing long-term impact. 

Links to previous OQI-supported hackathon articles: 

NYUAD International Hackathon for Social Good – open-quantum-institute.cern 

SEA Quantum Hackathon – open-quantum-institute.cern 

Alexandria Quantum Hackathon – open-quantum-institute.cern