1. Home >
2. Developer Blogs >
3. What I Learned as a Rookie Engineer on a Hackathon Team

---

Hackathons are like special holidays for engineers. Everyone gets into the alpha zone mindset, making their frontal and temporal lobes happy when the boss says, “Hey, here’s an opportunity to learn, be creative, live up your crazy idea.”

There I was, just one week after my bootcamp, participating in my first hackathon ever. While it sounded exciting, I kept asking myself, “What can I bring to the table to enrich their approach?” and “What role could be best for me around these coding superheroes?” Determined to make a positive impact, I mustered up all my confidence and said to myself, “Let’s go swim with sharks.”

The team I joined had one goal in mind, boost the speed with which users log in and begin their work day. What stood out to me was that the first hours had little to do with any coding. The first few hours were all about:

• how to define the goal
• what to research
• what services were affected
• what were the rewards and risks

Since our platform has such a high volume of traffic and must maintain 99.99% uptime, all the improvements we were making had to be done with care and surgical precision.

Once we split the work among the team members, I was tasked with cloning the repository, checking out the hackathon branch, and looking at the encrypt password flow, the area we identified as needing the performance boost. The goal for me was to understand the old code and port it to NodeJS. Of course, I had some help from trusty friends Google and Stackoverflow. However, they were no match for my growth as an engineer. The hackathon team surrounding me was a tremendous resource: always willing to help, pair program, and answer any questions I had. I found the code review parts to be particularly helpful. Much of this great feedback usually came in the form of “Okay, this will work, but can you make it more efficient?”

During the code review you are getting feedback about the quality and efficiency of your code. In this case, we used the Peer Code Review approach because we were running over time and we wanted to achieve the hackathons goals at a faster pace than usual. You can almost call it the “life running code review.” Any questions, coding approach or thinking is shared here and you get back feedback on your work. During the process you will get to learn new and interesting coding patterns, and senior people will explain to you how to achieve an efficient way for your work.

I learned a lot about the professional engineering workflow being involved in the setup and execution of all of the reliability tests the team put together. I got valuable insight in using tools such as envchain (to manage access between environments), kubectl, k9s (to access kubernetes), k6.io, grafana (to run performance tests and measure results) or npm audit (to check and validate that we fixed security issues), but also getting the explanation why and what we are doing and testing with these tools and how it fits our reliability and scalability goals.

At the end of the week, the goal was achieved, and I got to experience this magic, cathartic moment when the whole team was in the flow state and engaged from 8 am to 11 pm. I was able to watch such amazing creativity, accountability, and collaboration as all team members were fully focused to reach the goal. During these two days, we were able to remove password validation and login attempts flow from the legacy monolith and create them as a new microservice. We cut the user login response time down to half of what it was and increased resiliency of the platform all while reducing the cost of maintaining and operating the old solution.

The most rewarding part was making an impact on a project that makes our OneLogin customers even happier.

---

---