How I Won my First Ever Hackathon – 2 Wild Days of Research, Design, and Coding

I had no coding or engineering background. I studied biology in college, with no clue about what to do with my degree.

My first jobs were making cold calls in sales, but I made almost no money and was miserable with my work.

After failing at a few different sales gigs, I gave up and found a job preparing vegetables at a restaurant — not exactly the plant life I was expecting to work with after college.

I needed new prospects, and I was ready to find anything better. All it took was a strong work ethic, a willingness to learn, and a few key resources to get me onto a whole new career path.

This also got me involved in a coding competition that took me way outside my comfort zone.

While working at my restaurant job, I started hearing stories about people who taught themselves how to code and managed to develop that into careers. Willing to try something new, I started taking online courses with freeCodeCamp during my off-time from work.

Hours here and there turned into a full-time commitment. I left my job and followed freeCodeCamp’s curriculum, aggressively studying full-stack JavaScript as my new full-time job.

I spent a year and a half focusing on learning coding, and it paid off, too. I was accepted into a long-term contract as an entry-level coder at a New York City fashion company, which was generating over $2 billion a year in sales.

Learning was my top priority. Even in this new position, I continued to practice during my off-hours, this time focusing on best practices for my specific job responsibilities, which involved writing automated tests using the NodeJS version of Selenium.

I spent 10-15 hours per week doing Selenium tutorials, which helped me get my work done faster and gave me leeway to learn from my colleagues during work hours. I maximized in-between work times, talking to co-workers in the elevator or while walking to my desk. I learned what others did and what their responsibilities were for our company.

It didn’t matter if they were in the same role as I was. I spoke to my engineering supervisors and to people in our business units so I could better understand the structure of our company, find out how others had made progress in their own positions, and see if I could find some big problem that I’d be able to solve.

Around my third week of work, while talking to my senior director of engineering, I noticed a number of awards by his desk. He told me were from his past wins at our company’s annual Hackathon.

“Wow,” I said, “You've won a lot of awards.”

He responded, “Thanks. You should participate in the next Hackathon. It will be in a few months.”

I was still relatively new to coding and had never participated in a Hackathon, so after a day of mulling it over, I went back to his desk.

"Hey, I've seen a few other people with Hackathon awards,” I said, “but no one has nearly as many awards as you have. Plus, most of your awards say first place. How do you win so often?"

He told me, “I focus on projects that make an impact. For instance, for one of the Hackathons I built a prototype that would let our customers order off our website and pick it up in our stores. The judges realized this would be a big hit with our customers and would greatly increase revenue.”

When I asked him how to find a project that would make an impact, he explained that, during his time at our company, he’d gone ahead and learned all of the many different subsystems that powered our eCommerce business.

“Knowing the whole system makes it easier to see where the opportunities are," he said. "In fact, my broad understanding of our entire platform is what differentiates me and has allowed me to reach my current position.”

Finding a Project

I realized that the Hackathon would be the ultimate test of my abilities: could I take the strategies of hard work, learning from my co-workers, and my intense study of coding to the next level?

After years of feeling like I had been wasting my potential, I’d finally found a way to prove my worth. This wouldn’t just be about showing off, because I would need to find a project that was actually of use to the company.

I didn’t have a lot of time on my side, and my tech skills were relatively basic compared to the highly skilled senior level engineers I’d be competing against.

Even though I felt out of my league, I had the secret sauce for a solution in my back pocket: lessons I’d learned from Neil Rackham’s sales strategies book SPIN Selling, which gave me the four-step model for finding problems in large enterprises.

Step 1: Learn how something works.

Since I was advised to learn the inner workings of our eCommerce business, I started talking to employees in our planning department, conveniently located between my desk and the lunchroom (and between my desk and the bathrooms). They were responsible for deciding how much merchandise to buy and at what prices they would be sold.

I’d leave my desk and take a moment to ask questions like how they chose how much inventory to purchase in advance, how they set their prices, and if retail and eCommerce had different rules for pricing. Through my questions, I learned how planners introduced new clothing lines and calculated what to sell them at.

Step 2: Ask questions to find a problem.

Once I’d gotten a sense of how planning worked, I started looking for issues that might come up. Once they set an amount for inventory, does the company ever purchase the wrong amount? Do prices ever get set incorrectly?

I was trying to find the sort of mistakes or frustrations that I’d be able to solve.

Step 3: Ask questions to explore the problem’s implications.

After several days of asking questions, I learned about pricing issues, where prices would be set and appear incorrectly on our website. How did this problem come about and what were the implications?

I asked how often pricing errors would occur and what kind of further issues they might cause.

Step 4: Ask questions to explore the value of solving the problem.

If there were an automated computer script that found all the incorrectly priced eCommerce items, how helpful would that be?

I asked the planners questions that would help me figure out what sort of value I could offer them. If I was going to fix something at our company’s Hackathon, I wanted to make sure it had a noticeable impact.

After my conversations, I found that pricing mistakes would be a worthwhile project to work on. Each of our three or four assistant planners were spending 30 minutes per week manually checking for pricing errors. An automated system would save that time — an estimated 100 hours per year that would no longer be wasted.

Even though I had already been told about the Hackathon, there was no official date yet. I had a solvable problem in my back pocket, and, while I didn’t know for sure that I had the coding skills, I was fairly confident in my chances. Until the announcement came, I’d focus on my work. But whenever it arrived, I’d be ready to get started.

Confirming with the Planners

Two weeks later, I had an email in my inbox. The Hackathon event would be in one month, going for two days straight, which included a presentation on day 2, a Friday.

Project ideas would be judged on four criteria: originality of the idea, impact on the business, completeness of the prototype, and strength of the pitch. There were so many unknowns and it was impossible to predict whether one month would be enough time to prepare.

I went over to the planners and confirmed that the issue was still present — checking online pricing sales was still being done manually.

I was happy to learn that our company had a dedicated eCommerce merchandiser, who was responsible for reporting all incorrect website prices and resolving them. She would be able to give me far more information and could confirm whether or not it was an issue worth the effort of fixing.

I was unhappy to learn that she was on vacation, and I’d have to wait a week to speak to her. The clock was ticking, and I was stuck until then.

With three weeks until the Hackathon and our eCommerce merchandiser back in the office, I was able to start exploring the problem in more detail. She confirmed the issues I had heard about and said that building something that could automatically scan the website and find incorrect prices would be a big help.

In further conversations with the planners, I learned how pricing was uploaded to the website: planners would copy and paste a list of prices from an Excel spreadsheet to SAP, a software that does many things such as managing inventory for retailers. SAP would then push the prices to our eCommerce website.

I realized that the Excel prices could be compared to the website prices to find any issues. I would build a simple website that would let planners upload Excel pricing lists.

A script would then read the Excel pricing lists and compare them in real-time to our website prices. Any and all discrepancies would then be batched into a list and sent to our planners for review.

Excited that I had a way to solve the problem, I began explaining the project idea to other developers in our organization, asking if anyone wanted to join my team. However, I made it a strict requirement that any potential teammates would have to first speak to our planners in person and hear the problem from their perspective.

As part of the SPIN system, I needed teammates who were willing to understand the process and the problem before we could fully design the solution. Unfortunately, I failed to recruit any other software engineers to my project, but other engineers gave me valuable advice on how to code out my project and what technologies to learn.

I was on my own, but I was excited, feeling confident in my solution.

Needing to Pivot

Two weeks before from the Hackathon, I revisited one of the assistant planners and explained my idea for an automated script that would compare Excel and website prices and report discrepancies. She quickly informed me that my idea would be useless, since the Excel prices and website prices would always be identical.

The assistant planner continued to explain that the original Excel pricing lists were generated by a tool that took in product manufacturing costs, delivery costs, and other relevant factors, and then spit out Excel pricing lists, which our planners would then upload to the SAP software powering our website.

If the planners accidentally entered incorrect manufacturing costs or delivery costs into the pricing tool, then the price would similarly be wrong on the Excel lists.

“So you're saying there is no master list that is guaranteed to always contain all the correct prices?” I asked.

“Exactly,” the assistant planner said.

It was the opposite of what I needed to hear. There went weeks of planning, thinking, discussing, and waiting — gone.

I was two weeks out from a Hackathon where my lack of experience was already holding me back, and I had nothing. There weren’t enough days to do this all over again.

I had to rethink my process.

Since timing was tight, I couldn’t do all the research and work I had tried the first time around. Instead, I would let the planners come up with the project requirements for me.

I came back to the planning department, this time with a different question: “Imagine you had a robotic script that could automatically grab numbers from anywhere, such as an Excel spreadsheet, a database, or a website, and automatically subtract, add, or compare the data. What problem could be solved with the help of such a script?”

After the assistant planner I was speaking to thought about it for a few minutes, she told me it would be useful for checking sales prices. She explained that our website ran weekly mass sales every Wednesday. The sales would be listed on our homepage and would use text such as “25% Off All Men's Jackets” or “15% Off All Women's Dresses.”

Every Wednesday morning, our 3-4 assistant planners would spend 30 minutes to manually click through our website and confirm the correct discounts were applied. If the planners found any incorrect sales prices, they would send them over to our eCommerce merchandiser.

Only IT was able to change live sales prices. To keep things simpler for IT, our eCommerce merchandiser might wait and send a list to IT in batches.

That meant that even once an incorrectly priced item was found — unless it was an emergency — the pricing wouldn't get fixed immediately.

I had a problem, and the solution wasn’t far off from what I’d originally planned: an automated script that could report all incorrectly discounted items would save time by reducing the amount of work involved for our planners, for our eCommerce merchandiser, and for IT, and it would make for a better customer experience by reducing the amount of incorrect sales prices and doing so quickly.

I’d only need a master list of all ongoing sales that could be compared to website prices, but the planners told me that no such “100% accurate” master list existed, at least not on paper.

“But a fully correct pricing list exists in our heads,” they said, “because we know our products through and through. That’s why we can click through our website and spot incorrect pricing.”

After thinking about it for a few moments, I asked, “What if you didn’t have to click through our website? What if you could get all our live website prices in a neat list just by clicking a button?”

“That would dramatically speed up our price checking,” they said.

We came up with a plan: I would build a simple website that would allow planners to upload dozens of item names and immediately receive an easy-to-read list of those items’ live website prices and sales discounts.

The idea was concrete and doable. It had an impact — conserved manpower, faster QA, and improved customer experience — and I was confident in my own ability to build it (even if I didn’t yet know exactly how).

I went back to my desk and typed up a document explaining the business requirements of what I planned to build, how it would be helpful, and the Hackathon date when I would build it.

I went back to the planners and had one of the planning managers and the eCommerce merchandiser read my document. There was no time to backpedal again.

They gave me the confirmation. The idea was set, and with a week left, it was time to figure out how I was going to make this a functioning, usable reality.

I went to the engineers at my company more advanced than I was (of which there were plenty) and asked, “How would you code a script that automatically returned the website prices for items we sell?”

After speaking to several engineers, I learned that our website product pages got their prices by querying our internal eCommerce database, which in turn got its pricing info from SAP. This was a Redis database that had its own neatly written documentation showing exactly how to request any pricing info from it.

I found the engineer who had built the database and learned that I could retrieve the website prices and sale prices of a whole list of items using just a single database call.

Even though my plan was coming together, I was still very aware of how much work I had ahead of me. I tried to recruit other engineers, but didn’t find much interest, especially when I told them about my expectation for them to speak to the planners.

With no engineering teammates, I spent every moment I could after work studying the material on my own, experimenting with making database calls and studying how to write JavaScript code to read Excel spreadsheets.

Expanding to our Main Brand

The day before the Hackathon, out of curiosity, I asked our planners how they knew what inventory options to sell. They responded that our company’s merchandising department was responsible for those decisions, so I went to speak to our merchandisers.

During our conversation, they mentioned in passing something about their counterparts in our main brand.

“Our main brand?” I asked. “Aren't you guys our main brand?”

“No,” they said. “The merchandising and planning for this floor is dedicated to our smaller brand, which is 15% of our total revenue. Upstairs is our flagship apparel brand.”

This couldn’t be happening. I knew we had several brands at our company, but the day before the Hackathon, I was finding out that my project was being built for the smallest brand in our organization.

With a weaker background in coding, no other engineers on my team, and the need to do something big to impress the judges, I wasn’t looking too great.

I walked upstairs and started asking around where I could find the planning department for our main brand. I needed to speak to them if my project was going to have a big enough impact.

There seemed to be at least 20-40 planners in our main brand. Who would I speak to?

I needed to find a planner who would understand what I had in mind, but also have the knowledge base and the creative thinking to find the areas I was missing.

What if the larger brand used a different system? I needed somebody dependable, and I didn’t have the time to spread out over a few weeks.

With the Hackathon a day away, I took a shortcut.

Planning had an open office space environment, which meant people were at cubicles with no walls. I began talking about my Hackathon idea to one of the planners in our main brand.

As I spoke, I raised my voice and began walking up and down the aisle, looking around at other planners as I did so. This allowed me to get the potential attention of up to eight planners at once.

One of the planners showed a ton of interest and asked a lot of questions. He was specifically interested in our Redis database and whether other information besides pricing could be found.

I showed him our database documentation and we quickly went through it all.

He mentioned that there was other information besides pricing that could be useful, such as whether the items were listed on our website, and what categories they belonged to. He then introduced me to eCommerce merchandisers from our main brand, who agreed that what I was building had potential beyond just pricing.

There wasn’t enough time for me to make any drastic expansions to my coding requirements, but we agreed that I could build my project in a way that was flexible enough for it to be used by planners from either our smaller brand or our main brand.

Hearing about my project’s value and viability from co-workers who were really enthusiastic about it was just the push I needed.

I had the confidence, the resources, the research, and, hopefully, the ability. Even if I didn’t, there would be no avoiding it — the Hackathon was starting the next morning, and it wasn’t going to wait for anything.

Finding a Teammate

The Hackathon was a two-day affair, over the course of a Thursday and Friday.

When I looked at the calendar for the date, I realized that I had a family commitment on Friday afternoon that I wouldn’t be able to avoid. The presentation and judging would both be on Friday, which meant that I absolutely had to find a teammate who would be able to present, or the project would be dead before I’d even written a line of code.

I approached the planners from our company’s smaller brand who I’d been in conversation with for several weeks already. I asked if any of them would be able to present our project to the judges. None seemed enthusiastic. A few told me they had meetings on Friday while others said they were nervous about public speaking.

Needing a teammate, I went straight to Oliver, the planner from our main brand who had such an active interest in my project. He was a popular guy with a kind face. His hair was greying, though he was in his mid-20s, and he had surprisingly made it to the role of senior planner within just four years out of college, when most took five to eight years to get to that point. He had a lot of awards at his desk, and plenty of snacks, too.

Oliver immediately agreed to present the project and said he was excited to do so.

We went downstairs to the Hackathon’s dedicated meeting space and we signed up as a team. We needed a name for our project so we called it PriceSeeker.

There were nine other teams competing, most of which were comprised of senior engineers. Some project managers and UX designers were also part of a few teams. With the exception of my planning teammate, everyone else competing belonged to our eCommerce department.

Simplifying the Design

I had my plan in mind going into the Hackathon: I’d build a simple website that would let users upload Excel lists of items.

My website would parse the Excel spreadsheet, retrieve the list of items, and request their prices from our Redis database. It would then return to the planners a new Excel spreadsheet containing items and their prices.

With this, instead of manually clicking through our website to check item prices, they’d be able to immediately see all relevant website prices at the click of a button. It would make price-checking a whole lot easier and more convenient.

We had two days to work on our project and then present it to the judges, who were high ranking leaders within our eCommerce department. My senior director of engineering — who had introduced me to the Hackathon in the first place and taught me about making an impact — was one of the judges. He was also available throughout the Hackathon to answer any coding questions.

Excited to begin, I sat down at my computer.

I soon got up from my computer, because I had very quickly hit a wall: I didn’t have enough coding knowledge to figure out how to set up a basic HTML website that could easily read from an uploaded Excel sheet.

I approached my senior director of engineering for advice, and he suggested I simplify my design and just make a form with a text area. Users would copy items from Excel into the form and submit it.

Upon submission, the pricing would be requested from our database. The pricing would then be returned in a simple HTML table, which users could copy into Excel if they wanted.

No longer needing to write code to read Excel documents simplified things a lot.

Building PriceSeeker

Even with the help, it was still an intense day of near-constant coding.

I took some breaks to check in with our planners and get approval on the design. I grabbed plenty of snacks from Oliver’s desk. I also spoke with other engineers whenever I needed help or got stuck on the code.

I wasn’t alone, and I was grateful for the help, but it was my responsibility to keep pushing through the difficulties and put in the physical and mental effort of writing out all the code.

I was extremely aware of my disadvantage in the competition, but I was happy to find that by the end of the first day, I had managed to get a decent prototype working. It returned information for small lists of four or fewer items, but for larger lists it returned nothing at all.

The day was ending and I didn’t have the time to investigate or troubleshoot, so I uploaded PriceSeeker onto Github Pages, emailed the website address to several planners, and went home. Hopefully, a good night’s sleep and some time for responses would help me along my way.

When I got back to work on the second day, I found an email waiting for me from Oliver — he wasn’t able to get PriceSeeker working, but he helpfully sent me several screenshots showing what he’d tried.

Seeing the screenshots, I immediately realized that I hadn’t properly explained how to copy and paste items into the form. I emailed Oliver back a screenshot showing him how to do so, and he emailed me back two minutes later, showing me that it was working.

After taking some time to get into the proper headspace, I went to Oliver’s desk. There were several other planners around his desk and on his screen was PriceSeeker, which they were discussing.

Oliver had sent the website address to all the other planners on his team. The planners were discussing how amazing it would be to further explore collaboration between planning and engineering. I was excited by the enthusiasm, and especially by the possibility of opening new doors with this collaboration.

This especially excited Oliver, since he loved the idea of breaking through the barriers that siloed departments and closed them off from each other. Maybe we could create further opportunities for finding problems and impactful solutions by encouraging communication between departments.

Since I knew I wasn’t going to be around for the presentation, I spoke to Oliver, and we went over his five minute pitch. He started by displaying our working PriceSeeker website and showing it in action. He copied and pasted items into the form, submitted it, and explained why it was so useful to be able to get the prices instantly.

His demo went on to explain how “the sky's the limit,” with examples of other data that would be useful to receive. He explained the business impact of how our automation website would reduce manual effort and lead to an improved customer experience.

He concluded that though PriceSeeker currently only returned pricing, there was a lot more that was possible. It was amazing hearing him speak about the website's possibilities. He focused entirely on business terms like “reduced manual effort” and “increased annual sales,” and given that he was a planner himself, Oliver was able to talk about our project with far more accuracy than I ever could have.

When he finished his presentation, I asked questions to both learn more about our project's value and to give him additional practice at explaining its potential impact: “How much manual effort could be reduced?”

“How would automating the checking of our website data improve your abilities to order the right amount of inventory?”

“In addition to planning, what other teams or departments would benefit from automated checking of website data?”

“Why?”

I knew to ask these questions because I learned this question-asking technique from the book Spin Selling. Spin Selling acknowledges that sellers sometimes cannot present directly to buyers and need to rely on intermediaries to pass on the messages. The book advises coaching your intermediaries by asking them questions that get them to explain the product's benefits in their own words.

That’s exactly what I did, asking lots of questions that got Oliver to further explain all the many ways our project could add value.

About an hour before the judging would begin, I had to leave. I was sorry that I wouldn’t be able to be there for our presentation, but I was comforted to know that we were in good hands.

I wished my teammate good luck and asked a coworker to text me if my project placed in the top three.

The Results Are In

After leaving, I sat on a train for two hours. On the way, I mentally prepared for what would happen once the contest was over.

I'd gotten the feeling that we were the only team that had extensively started planning even before the Hackathon was officially announced. I'd also gotten the impression that we were the only team who had prepared our presentation to focus exclusively on a business impact.

I had some confidence because of this, but I was still nervous because there were so many uncontrollable things that could prevent us from reaching the top three places or even winning the Hackathon.

I kept imagining all the things that could go wrong without me being able to do anything. Maybe it would turn out we’d done something wrong and we’d get disqualified somehow. Maybe Oliver wouldn't be able to present. Maybe another team would deliver a superb presentation that rocked the house.

While sitting on the train, I realized that planning to win the Hackathon was not something useful, as it wasn’t something I could control. I decided that — regardless of the results — I would continue working on my project and implement it in a way that would lead to an increase of $20,000-80,000 in profits.

I chose those numbers rather arbitrarily, but it felt like something achievable. To reach my goal, I knew there was still a lot of work that would have to be done after the Hackathon was over.

I got off the train and made it to my family event. Part of me was still somewhere else, but I knew there was nothing I could do now. I didn’t look at my phone for a bit, which is why it took some time before I saw the text. The results were in. My team had won.

For a brief moment, I was shocked, relieved, happy. I’d reached this point after so much work, so much waiting and struggling, and it looked like it was finally paying off.

Victory didn’t last long, because now I was overthinking all the negative possibilities again. To pull off this win, I’d done a lot of things at work I’d never expressly gotten permission to do.

I'd given the link to our database's documentation to planners who quite clearly were not members of our eCommerce department. I'd hosted our Hackathon project in my own personal GitHub rather than in our company's code repository. I'd been constantly sneaking off during lunch breaks and at the end of the day to talk to the planners, which meant my coworkers could argue that I was neglecting my regular workload.

Even more than all of this, I was worried about the social repercussions. I was extremely far from any level of seniority in my engineering department, so what kind of reception would I get for besting the more senior engineers?

After the Hackathon

I made it to work after the weekend, concerned for the worst, only to find that no one seemed to care much.

When I returned, a bunch of people gave me high-fives and wished me congratulations. But my regular day-to-day workload stayed the same as it was before the Hackathon. I was told by upper engineering management that there wasn't enough engineering leeway to let me or any other engineer be given official permission to work on PriceSeeker.

Our heads of planning said they were in the midst of a major restructuring and said they wouldn't be able to devote time to my project for at least several months. I was frustrated to find that, while I was receiving positive feedback from coworkers, all my efforts amounted to a neat side project I could be proud of, but wouldn’t be able to actually do anything with.

I had a lot of work to catch up on now that the Hackathon was over, so I went back to focusing solely on my workload, with 5-15 hours per week after work spent studying Selenium best practices. It took me about a month or two working on my skills to get to the point where I was finishing my workload in enough time to have a few hours during the day to spare here and there.

PriceSeeker was almost done and there was just a bit more coding that had to be done to fix all the bugs. I felt I needed maybe a day or two more, but without official permission, it would have to be my own project to secretly complete on my own.

None of my coworkers knew I was spending time on PriceSeeker, nor did they care, since I was getting my regular work done and submitted on time.

After some considerable effort and tinkering, I managed to solve all of PriceSeeker’s bugs.

Excitedly, I headed to the planners from our minor brand to show them the working model. They told me they didn’t need it anymore. I couldn’t believe it. I was so shocked that I could barely even ask what was wrong.

As I found out, the issue of incorrect pricing had been a temporary one caused by a recent change in how pricing would be displayed. At some point after the Hackathon, the pricing displays had been updated in a way that would let planners find any incorrect pricing a lot quicker.

In hindsight, I should have realized this during the lead-up to the Hackathon, but I must have been so enthusiastic about my plan that I hadn’t properly investigated all areas where it could go wrong. Regardless of why I’d missed it, this meant that PriceSeeker had been effectively useless for quite some time.

Oliver told me that PriceSeeker as it was would likewise be useless for our main brand. However, he told me that there was an issue where items on our website would occasionally “fall off.” This meant that certain items and colors that were in our inventory would accidentally get removed from our eCommerce store.

This happened rarely, but the planners wouldn't know about it until reviewing weekly eCommerce sales reports, noticing some items had zero sales, and then checking if they were on our website. At that point, they would mark the products to be returned to our website.

Once again, this was more manual work and less productivity than was optimal, and Oliver advised that it would be very useful if PriceSeeker could be modified to let them know whether or not an item was on our website.

After going through our database documentation, I realized it would be a very simple matter to query our database to see if an item was listed on our website or not, so I quickly updated PriceSeeker to also include that check.

Oliver told me that our eCommerce merchandisers were the ones who were responsible for quality checks of website inventory and they would benefit most from this new feature within PriceSeeker. I approached the eCommerce merchandisers for each of our brands and found that they were very happy with what I showed them.

They copied and pasted hundreds of items into it at once and quickly verified that PriceSeeker was properly reporting all items that were unlisted on our eCommerce store. And just like that, they began using it several times per week.

Over the next several weeks, I continued to talk to planners and merchandisers, trying to find other areas where PriceSeeker could be useful.

I learned that our planning department had recently set up a data science team. The team was responsible for building automated scripts and dashboards to help our planners make better decisions. Reporting unlisted eCommerce inventory had actually been on their to-do list.

I enjoyed speaking with the data science team and exchanging ideas, but with no official sanction to work on PriceSeeker or anything else, our conversations were mostly theoretical. Still, I was happy to know that my project had accomplished something and was finally seeing the light of day.

It wasn’t long afterward when I got an email from my consulting company’s human resources department. They wanted to schedule a meeting.

I went in to talk to them and was told there were going to be layoffs. Several consultants would not have their contracts renewed. I was one of them. I had three weeks’ notice before my contract ended.

I knew that the fashion brand had been facing a decline in sales and firing a consultant was easier than getting rid of a full-time employee. Nonetheless I was still quite surprised that I would be among those let go.

In my last few weeks, I tidied up my regular work and gave some extra attention to PriceSeeker. I wanted to see if I could quantify the financial impact it had made, but the value of detecting accidentally unlisted inventory would not be easy to quantify.

When I went to our eCommerce merchandisers, they told me its impact would be impossible to measure. There were so many complicating factors involved, such as how many unlisted items would be detected, what brand they were from, the popularity of those items, and how much inventory remained.

Oliver summed it up, “though we can’t give a monetary value to PriceSeeker, we are certain it has a positive impact on our bottom line.”

With my contract ended, I was left looking back at around seven months in a company where I’d had some amazing adventures, most exciting of which was our Hackathon.

After our Hackathon was over, many of my colleagues told me that I won because I “focused on a business impact.” Though they meant it as a compliment, I always felt hollow when I heard that being given as the sole reason.

Personally, I credit my win to actively preparing even before the Hackathon was officially announced. By doing so, I was able to continuously get the feedback I needed to improve my proposal so that it eventually had a legitimate business impact.

I couldn’t have done it without the help of others. So much of the work felt like it was up to me, like I had to be the one to push and discover and self-teach and work.

The truth is, I wasn’t alone. The ones who offered passion and enthusiasm — my senior directing of engineering and my teammate, Oliver — were the ones who pushed me to be part of a competition I wouldn’t have ever gone near two years earlier.

I’m still learning. I’m still trying new things. I’m still hoping I’ll find more of that collaboration that enabled me to create something helpful for my company and meaningful to my own journey.

Thinking back, it’s still hard for me to believe that someone like me, who had struggled so hard to land a career, would be able to enter the corporate world and turn their life around.

For me, the Hackathon was a second chance. And I made the most of it.