<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=12616&amp;fmt=gif">
Hackathon Projects: A Retrospective on CodeLive | Codility

Hackathon Projects: A Retrospective on CodeLive | Codility

Codility's development team recently conducted a Hackday (Hackathon) project to update CodeLive with new functionality. Review some of our key takeaways here!

Inside Codility

Our goal was to improve our CodeLive solution to further facilitate real-life, engaging coding interview sessions. We hit many bumps during the project because our focus was split amongst other initiatives and we didn’t consider some crucial elements. I wanted to sit down and write out my thoughts on how this project went, and how we can improve for the future.

The CodeLive Video addition started as a Hackathon project and was later pulled into product work. Initially, it started as a ‘cross-team’ initiative—a handful of people across several engineering sub teams collaborated on this solution outside of normal product work.

The project was estimated to be very short, but when it started to grow, communication and focus problems appeared. It became difficult for participating engineerings and product owners to know when each other was available to work on the project and sync up. There also wasn’t a clear driver for the initiative. In summary, it’s challenging to be on two teams at the same time.

Takeaways for Hackathon projects

At the retro meeting, we came up with several steps we could work towards to achieve success in the future for similar Hackathon projects:

  • Team members, even if cross-functional, should have the project as a primary focus instead of juggling several things at once.
  • The project should have a clear objective and a clear boundary between prototyping and starting preparations for going to production.
  • The cross team should form a new, temporary team focused solely on a particular goal and have complete ownership over that.
  • The roles, especially driver/product manager/leader, should be set from the start.
  • The project should have a normal development process like dailies, retros, refinements, QA, and story mappings.
  • If needed, it’s good to have stress testing done by infrastructure team.

Another big takeaway from the project is to validate things as soon as possible. We had great success in the first few days—the video itself was working, but we didn’t validate it through a beta with customers. Instead, we decided to drive it until we were production-ready, and then verify the whole idea. We should’ve been driven by data and feedback throughout the project, not driven by assumptions and gut feelings.

On the other hand, there were a lot of signals from the marketing and sales teams that this solution would be hugely beneficial—there was a solid business case for driving the project. We still should have validated earlier though, probably after a week of development instead of spending three months polishing without validation.

Takeaways for our wider development initiatives

Lessons learned about our big-picture process:

  • We should always have a clear distinction between stages of the development with milestones with clear goals
  • When building a new solution, we should align with sales and marketing to gauge why and how it would benefit them.
  • Scope pieces of the Hackathon project for validation, testing, and being production ready

Things that we learned and appreciated:

  • Prototyping works great in small Hack-a-teams
  • People who volunteer themselves for these Hackathon projects are full of energy and drive
  • Operating on a cross-functional team increases knowledge-sharing about the system for normal product teams
  • WebWhiteboard was fun to use during our partially remote retrospective meeting. We did a DAKI exercise—here’s what we came up with!

Final thoughts

This innovative, small project showed us that prototyping could be done quickly and in a lightweight manner. I’m proud to say that we used our Hackathon resources in a really smart way. The project was never left hanging—we ‘recycled’ it and pulled it into product work, and improved it along the way. There are a lot of things we could’ve done better, and will do better in the future. This was not just a fun internal change to some code, but a bigger project considering and impacting the needs of marketing and sales. Retrospectives are a great way to review how a team collaborated and accomplished (or didn’t) an objective, and I look forward to more Hackathon projects and retros in the future!

If you'd like to talk to us about the CodeLive solution or learn more about our Hackathon project, click below:

Talk with us

Keep Reading

How We Hire Developers at Codility

Hiring the right people is crucial to any company's success. It's no secret that it takes a long […]

Meet Recruitee, our newest ATS partner

We know how hard it can be to find top engineering talent. Findings from our 2018 Developer […]

Collaborative Tech Hiring in People Operations (Panel Discussion)

Two Head of People Operations on Collaboration with Engineers Collaborative hiring is a trend that […]