Skip to main content

How to create a challenge

This guide walks organizers through creating a challenge in Core, field by field, with recommendations for each setting.

Before you start​

  • You need access to the Challenges resource in Avo (the Engineering, Events, and HackDays teams can create and edit challenges — see Who can access Avo).
  • Know whether your event is project-first or challenge-first — this decides where the submission form is configured. See Programs and submission flows.

Step 1: Open the form​

  1. Go to https://core.mlhtools.com/resources/challenges.
  2. Click Create New Challenge. This opens the challenge creation form.

Step 2: Basic challenge information​

  • Name (required): the title of the challenge. Keep it clear, concise, and user-facing. Examples: "Build with Gemini API", "Best First-Time Hacker".
  • Description (required): the full explanation of the challenge — what participants need to build, submission requirements, and judging criteria if applicable. This is the main content hackers read, so be detailed. Supports rich text (headings, lists, links).
  • Prize Description (optional): what participants can win — swag, cash, an internship, etc. Keep it clear and motivating. Most relevant to League challenges.
  • Short Description (optional but highly recommended): a 1–2 sentence summary used in challenge listings and featured cards/banners. If not set, the challenge falls back to other content, which usually looks worse — set it.
  • Background (optional): an image used as the challenge's banner/visual background. Recommended size 1024 × 720. Strongly recommended when Featured is on — without it, featured challenges look visually incomplete. A background is required for a Short Form challenge that is Featured.
  • Type (required): the kind of challenge. Choose carefully — it affects where the challenge fits:
    • Overall — general placements like 1st/2nd/3rd. Mostly for hackathons.
    • Event — event-specific challenges (e.g. Best First-Time Hacker; most GHW challenges are Event).
    • League — MLH-wide challenges (hackathon challenges).
    • Short Form — lightweight tasks (e.g. address-form submissions, event check-ins).
    • Third Party — external sponsor challenges.
  • Position (optional): used by Zoho to maintain ordering; not relevant to the challenge page itself. Must be between 1 and 999.

Step 3: Visibility and behavior​

  • Featured (optional): shows a featured badge and places the challenge in the banner/top section. Use only for high-priority or sponsored challenges. For GHW, Featured also gates basic swag — see GHW event setup.
  • Allow Multiple Submissions (optional): on → a hacker can submit more than once; off → one submission per hacker. Set it according to the challenge type.
  • Active: on → the challenge is live and accepting submissions; off → hidden or inactive.
  • Auto Approve Submission (optional): on → submissions move straight to approved; off → each submission needs manual review. Recommendation: enable for simple/automated challenges, disable for judged competitions.
  • Survey Link (optional): a link shown to hackers after they submit — useful for feedback forms, sponsor surveys, or extra data collection.
  • hack.mlh.io Accent Color (optional): used for branding on hack.mlh.io. Not applicable to the challenge page.

Step 4: Tagging and metadata​

  • MLH Sponsorship (optional): link the challenge to a sponsor (e.g. Gemini, Solana). Helps with categorization, data analysis, and visibility. See MLH sponsorships and challenges.
  • Tags (optional): select one or more tags to aid filtering and discoverability. You can create new tags at https://core.mlhtools.com/resources/challenge_tags.
  • External Submission URL (optional): use it when submissions happen outside Core (a Google Form, a Devpost link). When set, Core acts as a redirect to that URL.
  • Estimated Completion Time (optional): sets hacker expectations. Examples: "15 mins", "1–2 hours".
  • Backup Challenge (optional): mainly for Global Hack Week. Lets a submission to another challenge count for this one — e.g. if a hacker can't complete the primary challenge, a designated backup can count instead. A backup can only be set on a Featured challenge (and a challenge can't be its own backup).

Step 5: Submission form configuration​

This section controls what hackers must submit (project URL, project name, screenshots, description, built-with, demo URL — each can be required and given help text). For a challenge-first event you configure it here on the challenge; for a project-first event it lives on the program instead. Full details: Submission form settings.

Step 6: GHW (Global Hack Week) settings​

Two special-purpose settings appear for GHW:

  • Is this Address Challenge?: enable for challenges that redirect to an external form (e.g. address collection) — typically operational workflows.
  • Is this a Main GHW Event Check-in Challenge?: used to track main-event participation. The challenge counts as complete once the hacker has checked in to the event the challenge is linked to.

See GHW event setup for how these tie into swag eligibility and the one-click setup actions.

Final step: Save​

Review every field, make sure the required fields are filled and the submission settings match what you expect, then Save.

note

Creating a challenge does not put it on an event. Once it exists, attach it to an event.