top of page

Welcome
to NumpyNinja Blogs

NumpyNinja: Blogs. Demystifying Tech,

One Blog at a Time.
Millions of views. 

From First-Time Participant to 2nd Runner-Up: My SQL Hackathon Journey

Apr 1
8 min read

I recently participated in my first SQL Hackathon as a Data Analyst, working on real-world healthcare data focused on the organ donation pipeline.

Honestly, I didn’t know what to expect or how challenging it would be. It was exciting, a little overwhelming at times, but overall a great learning experience. I knew that just by participating, I would gain more confidence in SQL , not just in writing queries, but in understanding how to use it in real-world scenarios and how to think like a Data Analyst.

And by the end of it, we secured 2nd Runner-Up out of 16 teams. That moment felt really special and as a team we were so happy after they announced the results , not just because of the ranking, but because of everything we learned and built during those 7 days. reflecting our ability to combine SQL, analytical thinking, and teamwork effectively.

This hackathon was not just writing sql code but it was far beyond how we can analyze the data and give meaningful analytical insights and how we can coordinate in a team.

During hackathon I volunteered and served as a Team Lead to 5 members team that was made by the organizers , coordinating workflows, guiding discussions, and ensuring our team stayed aligned from data preparation to final presentation.

Let's begin. This blog shares my journey, the challenges we navigated , and the key lessons I learned along the way.

What is this Hackathon?

So what exactly was this SQL Hackathon about? It wasn’t just about writing queries — it was designed to test how we think as data analysts. Over 7 days, we had to first understand and clean the data, and then build our analysis step by step. Instead of just answering questions, we had to create meaningful questions ourselves and solve them using SQL. The evaluation was divided into three categories, each increasing in sql complexity, and scoring was based not just on correctness but also on query efficiency, optimization, reasoning, and the value of insights generated.

In addition to this, we had two rounds of presentations. On the 7th day, we presented our findings and explained how we approached the data analysis within the given time. Later, we had a technical presentation where we discussed the challenges we faced, how we solved them, and the outcomes of our approach.


Understanding The Dataset

Before starting any analysis, the first and most important step was to truly understand the dataset. We were provided with a PhysioNet link along with the dataset for the hackathon.

On the very first day, we spent time exploring the data — understanding what each table represented, identifying the objective behind the dataset, and figuring out how different tables were connected. We looked for common columns that linked the tables, identified important fields, and tried to understand the overall structure of the data.

We also went beyond what was provided and did our own research to better understand the meaning of each field. This included learning about medical terminology, identifying what values could be considered normal, and recognizing potential outliers. This step was very important because it helped us interpret the data correctly.


In this hackathon, we worked with the Organ Retrieval and Collection of Health Information for Donation (ORCHID) dataset from PhysioNet. It is a large-scale, real-world dataset that captures the organ donation and procurement process in the United States, including donor referrals, clinical details, and donation outcomes. The dataset is structured as a relational database with multiple linked tables, allowing analysis of the complete journey from donor identification to organ procurement.

For our analysis, we primarily focused on two core tables:

  • Calculated Deaths Table — representing expected donor opportunities (potential donors)

  • Referrals Table — representing actual cases referred into the donor pipeline

The main objective was to evaluate how many potential donor opportunities successfully progressed through the referral process and to identify gaps or drop-offs within the pipeline.

In simple terms, our analysis focused on:

Potential Donors → Referrals → Outcomes

This required not only strong SQL skills but also critical analytical thinking to derive meaningful insights from real-world healthcare data.


Cleaning the Data — Where the Real Work Began

Once we understood the dataset, the next step was data cleaning — and this is where the real work began. The data wasn’t analysis-ready, so we first created working copies to preserve the original data and then started cleaning step by step. We converted incorrect data types (like timestamps stored as text), handled missing and placeholder values, and standardized fields such as gender and race. We also created new features like workflow durations and age groups to make the data more meaningful for analysis. Along the way, we removed duplicates and filtered out logically incorrect records to ensure data quality. By the end of this process, we had two clean, structured tables ready for analysis — which made a huge difference in generating accurate insights.

Along with cleaning, we also focused on structuring the data efficiently. We defined primary and foreign keys to maintain relationships between tables, but we intentionally avoided over-normalizing the dataset. Instead of splitting it into too many tables, we created new columns within the existing structure to support our analysis. This approach helped us reduce unnecessary joins while solving category-based questions, making our queries simpler, faster, and more optimized.


From Question Creation to Insight Generation

When we started working on the questions, we approached them strategically rather than randomly. We closely referred to the hackathon reference document and scoring rubric to align our work with what the judges expected. This helped us understand not just what to solve, but how to solve it effectively. For example, the rubric defined that joins, grouping, filtering, and CASE-based logic would fall under Category 1, more advanced techniques like window functions and analytical computations belonged to Category 2, and user-defined functions, stored procedures, and other advanced implementations were evaluated under Category 3.

Based on this structure, we focused on writing queries that generated clear KPIs and meaningful insights rather than just technical outputs. In Category 1, we built strong foundational analysis by calculating key metrics like procurement rates, referral-to-death ratios, and OPO performance comparisons. In Category 2, we went deeper into analysis using window functions, rankings, workflow delays, and funnel conversions to uncover patterns in the donor pipeline. Finally, in Category 3, we worked on more advanced logic such as functions and reusable analytical components that supported dynamic analysis and real-world use cases.


Technical Challenges & Problem Solving

While working on the analysis, we faced several technical challenges that required both analytical thinking and collaboration.

One of the first challenges was related to data quality — especially inconsistent timestamp sequences across the donor workflow. Although individual timestamps looked valid, the overall sequence (referral → approach → authorization → procurement) was not always logically aligned. To address this, we validated the workflow by comparing end-to-end durations with intermediate stages and removed records with conflicting timelines to ensure accuracy.

Another major challenge was designing a meaningful donor funnel analysis. Since different stages used different denominators and had inconsistent formats (such as authorization stored as both ‘Yes’ and TRUE), it was difficult to create a fair comparison across OPOs. We solved this by standardizing the data, building a unified funnel structure, and applying consistent logic across all stages to accurately measure drop-offs and performance.

We also faced challenges in aligning expected donors with actual referrals, as both existed in separate datasets. A direct join led to loss of important records, so we implemented a LEFT JOIN strategy to preserve the full population and used distinct aggregations to avoid duplication. This helped us accurately identify missed donor opportunities and gaps in the pipeline.

One of the biggest challenges during this phase was ensuring that our questions were not repetitive and that each query added unique value. As a team, we spent time reviewing all our questions together, identifying overlaps in logic or insights, and refining our final set. This collaborative process helped us keep our analysis focused, meaningful, and aligned with the evaluation criteria.

In addition, we worked on optimizing query performance by reducing data size through pre-aggregation, minimizing unnecessary joins, and handling cases like divide-by-zero errors. This ensured that our queries were not only correct but also efficient and scalable.

Overall, these challenges pushed us to think beyond writing SQL queries and focus on building reliable, real-world analytical logic — which was one of the most valuable learning experiences of the hackathon.


Team Collaboration & Leadership

One of the most important aspects of this hackathon was teamwork. While every team member contributed in their own area of strength, I took the initiative to coordinate and manage the overall workflow to ensure we stayed aligned and on track. Since the hackathon had multiple components — data cleaning, question design, SQL analysis, and documentation — it was important to divide the work efficiently. We identified each team member’s strengths and assigned responsibilities accordingly, which helped us work in parallel and make the most of the limited time.

Throughout the process, we stayed in constant communication, discussing approaches, reviewing each other’s work, and refining our analysis together.

What made this experience special was how well the team supported each other. Whenever we faced challenges, we worked through them together, combining our ideas to arrive at better solutions. This not only improved the quality of our work but also made the entire experience more collaborative and rewarding.


Key Insights & Findings

Through our analysis, we were able to generate several meaningful insights from the dataset. One of the key findings came from the donor funnel analysis, where we observed significant drop-offs at different stages of the pipeline — particularly between referral and authorization — highlighting critical gaps in the process.

We also identified variations in performance across OPOs, where some organizations showed higher conversion rates than others. By standardizing the funnel logic, we ensured fair comparisons and gained a clearer understanding of performance differences.

Another important insight was around missed donor opportunities. By aligning expected donors with actual referrals, we were able to identify gaps where potential donors did not enter the referral pipeline.

Overall, these insights demonstrated how structured SQL analysis can help uncover inefficiencies and support better decision-making in real-world healthcare systems.

After all the analysis, challenges, and teamwork, here’s what this journey truly taught me.

Final Thoughts & Learnings

Going into this hackathon, I knew it was an important opportunity for me to grow as a Data Analyst, but I didn’t fully know what to expect. Since it was my first experience, it felt a little overwhelming at the beginning. However, once the hackathon started and we have our team, things began to fall into place. As we started working, we gained clarity — how to approach the problem, how to think strategically, and how to move step by step.

It was a thrilling yet high-pressure experience because of the limited time. But that’s what made it even more valuable — everyone gave their best, and we pushed ourselves to apply as many SQL concepts and analytical techniques as possible within that time. By the end of the hackathon, I not only had a much clearer understanding of how to approach real-world data problems but also how to work effectively in a hackathon environment.

After securing 2nd Runner-Up, I gained valuable insight into what judges look for — especially in terms of presentation, documentation, and structured thinking.

At the same time, watching other teams’ presentations gave me new ideas and perspectives, helping me understand where we can improve further. This experience has made me more confident, and I now feel better prepared to participate in future hackathons with a more strategic and focused approach.

This journey has not only strengthened my SQL skills but also shaped my confidence as a Data Analyst.


 
 

+1 (302) 200-8320

NumPy_Ninja_Logo (1).png

Numpy Ninja Inc. 8 The Grn Ste A Dover, DE 19901

© Copyright 2025 by Numpy Ninja Inc.

  • Twitter
  • LinkedIn
bottom of page