For Candidates
Login
Book a demo

Our goal was to improve our CodeLive solution to further facilitate real-life, engaging live coding interviews for engineering teams.

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 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 engineers 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 the 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!

Tomasz is a Software Engineer and Team Leader at Codility. He is passionate about creating solutions that prove to be valuable for the customers – not only in terms of technology and usability, but also in solving real, business needs.