How to Master a Hackathon —Best Practices from AWS Experts on Acing Hackathons

Main ideas / concepts covered

Session purpose and structure

• An AWS expert (Madukaran / “Madukan”) leads an open-ended session on how to approach and succeed in hackathons, focusing on:
  • Hackathon mindset and preparation
  • Team formation and ideation/problem-solving
  • Building a prototype quickly (MVP mindset)
  • Pitching/presentation skills
  • How AWS Party Rock (a browser-based GenAI app builder) will be used for the hackathon
• Time is split conceptually:
  • Early portion: hackathon guidance + Party Rock walkthrough
  • Later portion: AWS Educate / course access and registration questions (handled by another AWS expert, Pratibha)

Core message about AI and career readiness

• AI will continue to grow rapidly; the key risk is not that AI replaces humans entirely, but that people who don’t upskill may lose job opportunities.
• AI skills are broadly applicable across industries (examples mentioned):
  • Manufacturing: digital twins, predictive maintenance
  • Travel & hospitality: personalized travel planning/agenda

---

Hackathon best practices (methodology & lesson list)

1) What to look for in a hackathon

• Bring together a group with different perspectives/ideas.
• The goal is to fail fast and iterate rather than build something that must be production-ready immediately.
• Hackathons are time-boxed (usually a few hours/day(s)), requiring a working prototype within constraints.

2) Mindset: MVP and working prototype over perfection

• Build a Minimum Viable Product (MVP):
  • The “viable” part is critical—prove the idea is worth exploring and achievable.
  • Expect it may be polished or not; the key is to demonstrate a functioning prototype.
• Don’t optimize for long-term perfection during the event:
  • Focus on: “Will this work?” and “Is this a good idea to explore further?”

3) How to win (winning strategy)

• Solve a real-world problem relevant to the audience/impact target.
• Embrace constraints:
  • Use limited time/resources/tech constraints as a creativity driver.
• Bias for action → fail fast:
  • Prototype quickly, test usability/demand.
  • Pivot or course-correct quickly if it’s not going well.
• Impact > complexity:
  • Winning isn’t about massive codebases or overly complex prompts.
  • Judging focuses on outputs and solution effectiveness, not implementation length/complexity.

4) Preparation steps before building

• Research:
  • Brainstorm and study potential angles for the problem and solution.
• Team setup and environment:
  • For Party Rock: browser-based, so minimal setup.
  • For coding hackathons: prepare tools (e.g., local environment, Git repo).
• Starter templates:
  • Build using provided starter templates in the platform (Party Rock).
• Source control for coding (if relevant):
  • Use a Git repo and commit/push as you build.

5) Team formation guidance (if working in teams)

• Build a team that covers complementary roles:
  • Core product/code integration (coder)
  • Design/UI/UX (designer)
  • Presenter/pitch (pitcher)
  • Domain expert (manufacturing/travel/finance/etc.)
• Network for teammate strengths:
  • Identify strengths (coding, architecture, prompt writing, domain knowledge) and fill gaps using collaborators.

6) Ideation and problem solving workflow (detailed)

• Brainstorm multiple ideas (not a single approach).
• Filter based on feasibility within:
  • Available time
  • Party Rock app constraints
  • Expected impact
  • Novelty vs “already done elsewhere”
• Sketch the MVP:
  • Whiteboard/rudimentary design on paper with the team.
  • Map what you’ll build, the problem it addresses, and how judges will see value.
• Narrow to one solution, but keep “backups”:
  • If early building shows it isn’t viable, revert to the second-best idea.
• Keep some time for pitching:
  • Suggested allocation: 10–20 minutes for the pitch.

---

Party Rock (AWS Bedrock playground) — how it works and how to use it

What Party Rock is

• A browser-based GenAI application building playground powered by Amazon Bedrock.
• Key characteristics:
  • “What you see is what you get” (UI-based builder)
  • Enables fast app building using natural language prompts
  • Apps can be shared and remixed
  • Designed to avoid AWS account setup/access complexity for hackathon participants

Access requirements mentioned

• Users can access Party Rock via the browser.
• Login can be via Google credentials (and other identity options were mentioned).
• No AWS console/account is required for Party Rock access (to reduce friction).

Why it was chosen for the hackathon

• It abstracts away complexity of:
  • Navigating many AWS services
  • Setting up AWS accounts and permissions
• Allows large audiences to participate quickly.

Practical features of Party Rock mentioned

• Create an app from a prompt (or start empty).
• Add widgets to form a complete app.
• Widgets:
  • UI elements (inputs, text outputs, image generation, chat, etc.)
  • Can pass information between widgets (input → processing/output → display)
• Remixing:
  • Share a version; others can modify and remix, then share again.
• Snapshots:
  • Create immutable versions to return to known states.
• Sharing:
  • Apps can be made public or shared with friends/colleagues.

Model selection and capabilities (as shown in demo)

• In widget configuration, users can choose among model options (examples mentioned):
  • Claude 4.x family (e.g., “Sonnet”, “Haiku” style names referenced)
  • Other Bedrock model families (Nova/Pro/Lite style names referenced)
  • “Reasoning” toggle (enables deeper reasoning before responding)
  • “Internet access/search” toggle (allow retrieval)
• App builders can configure generation parameters:
  • Temperature: creativity vs factuality
  • Top P: restricts choices to likely word options
  • Additional parameters referenced in passing (e.g., controlling token usage)

Credits / token usage guidance

• Free access includes limited trial credits.
• When credits are exhausted, additional token charges may apply (not detailed, but mentioned).
• No credit card is needed to start (Google login is sufficient).
• Managing spend:
  • Use prompt constraints to reduce tokens (shorter outputs).
  • Use parameters like max tokens / similar controls.
  • Be concise and limit output length.

---

Prompt engineering (explicit lessons & instruction tips)

What prompt engineering is

• Writing effective instructions (prompts) to guide the underlying LLM/agent hosted by Bedrock to generate the desired output.

Types of prompting referenced

• Zero-shot prompting
  • Single prompt; no examples provided.
• Few-shot prompting
  • Provide examples or sample data so the model infers the pattern (e.g., sentiment labels with examples).
• Chain-of-thought prompting
  • Encourages the model to reason internally through multiple steps before answering.

Tips for good prompts (detailed)

• Be very specific:
  • Provide context and exact task requirements.
• Specify desired response style/constraints:
  • Example: professional, concise, no guessing.
• If unsure, instruct the model to use additional sources/context (e.g., knowledge bases).
• A good prompt “solves half the problem” by clearly specifying:
  • What to do
  • What format to output
  • What boundaries to follow
• Control output size to reduce credit usage:
  • Add limits such as word count, character count, or token budgets.
  • Examples of constraints mentioned:
    • “Write a one sentence poem”
    • “Provide a list of 10 nicknames”
    • “Create a story using 20 tokens”
    • “Limit all outputs to 100 words or less”
• Contrast shown conceptually:
  • “Write a short poem” vs “write a poem”
  • Shorter output generally consumes fewer tokens/credits.

Token explanation (basic)

• Tokens relate to how text is broken into smaller units; the presenter gave an approximate heuristic:
  • Roughly several characters per token (varied by model), with a general estimate like ~3–8 characters/token.
• Output length impacts tokens:
  • Longer responses (e.g., 1000-word essay) consume more tokens than short replies.

---

AWS Educate / course guidance (for MCQ preparation)

What AWS Educate is in this context

• A learning platform/program with multiple short modules/courses relevant to:
  • Cloud fundamentals
  • Machine learning
  • Generative AI
• Completion provides:
  • A digital badge (delivered via Credly)
  • Resume/LinkedIn proof of skills
  • Guided/simulation-based labs inside courses

Recommended courses (3 main ones)

• Cloud 101
• Machine Learning Foundation
• Introduction to GenAI
• Suggested (optional) course mentioned:
  • Introduction to Party Rock (primarily to understand the platform; not required for MCQs).

Registration instructions (detailed)

• Use the provided AWS Educate link from the chat.
• A pre-filled registration code is included:
  • Emphasis: do not remove it; refresh may require re-entering.
  • Code mentioned repeatedly in the transcript: EPBDIIN (treated as the required promo/registration code).
• Registration page fields mentioned:
  • First name, last name
  • Country, state, city
  • Email and additional email details
  • Select “Programs you are associated with”: AWS Educate or none of the above
  • Language preference (English mentioned)
• Important email consistency:
  • The email used in AWS Educate registration must be the same one used later when building a Builder ID.

Course completion expectations

• The three courses are recommended to prepare for the MCQ round, expected to cover AI/ML-related topics.
• Access continues even after the hackathon ends (reason given: ongoing learning value via the partnership).

Common issues addressed (from Q&A)

• If courses are missing:
  • Use the course search bar on the platform.
• If promo code is not visible:
  • It may be filled when using the shared link; otherwise scroll for the registration code field.
• Age restriction:
  • Minimum age requirement in India mentioned: 18 for access to these programs.

---

Speakers / sources featured

• Madukaran / Madukan — Senior Technical Account Manager, Amazon Web Services (AWS), India (hackathon + Party Rock session lead)
• Suba — Mentioned in the organizing/team context (not the main technical speaker in the provided content)
• Akancha / Akncha — Colleague mentioned to answer AWS Educate/academy questions (details handled by Pratibha later)
• Pratibha — AWS expert handling AWS Educate registration/access/course questions
• Aspire for Her — Program/organizer referenced (hackathon initiative)