Hackathon behind the scenes: Insights from our software engineer

His team developed an AI assistant that extracts key information from CVs and stores it in a structured format, allowing recruiters to quickly match candidates to job descriptions. We spoke with Uladzimir about what surprised him, what helped his team stay on track, and why simplicity can often beat structure in high-speed environments.

You’ve been working in software engineering for over 11 years, but this was your first hackathon. What made you finally decide to take part?

That’s true. I’ve taken part in conferences, meetups, competitions, trainings, seminars, and workshops. But a hackathon? Never. When I found out about the AI hackathon at EffectiveSoft, it felt like the right moment. I’d been following developments in generative AI for a while, and I saw this as an opportunity to step out of my routine and apply my experience in a completely new format. I wanted to see what it was like to build something meaningful in just a few days.

How would you describe your overall impression of the hackathon?

A hackathon is an adventure. It can be fun, it can be tense, and it takes time and effort. You need to combine skills from different areas, and even then, things may not go as expected. And like with any adventure, the better prepared you are, the more likely it will be a success. How many people are in your team, what technologies each member knows, what your idea is, which domain you work in—knowing all this beforehand helps your team start working on the idea right after the hackathon begins. But it’s important not to go too far.

What do you mean by “go too far?”

I thought, “We’ve got the team, the technologies, and the idea. Now, we need to establish the processes.” So, I started planning everything: a Jira board, CI/CD pipelines, a communication strategy, clearly defined roles and responsibilities, sync meetings every two hours, and agreed-upon deadlines. Luckily, my department manager, Eugene Kileiko, gave me a great piece of advice. He said, “You won’t have time for all this. Keep it simple.” And he was absolutely right. The only process that could work during these two days is the infamous get things done. Anything more would’ve just slowed us down.

And how did your team manage to stay aligned?

We relied on direct communication, quick responses, and ad hoc meetings. Everyone took initiative and full ownership of their work. This is only effective when you work with proactive, independent, and focused specialists. I was lucky to be on a team with exactly such people.

Sounds like your team had great chemistry. Did that dynamic come naturally from the start?

Not really. None of us had worked together before, and we came from completely different domains. Although everyone was motivated and ready to work, we didn’t make much progress at first. It took time to get used to each other, especially the ways we each communicate, approach tasks, and make decisions. This is essential even in the two-day hackathon format. And it paid off. On the second day, although we were even more tired, we were much more effective.

Glad to hear your team found its rhythm. Let’s switch gears for a moment and talk about AI, which was the focus of this hackathon. How did you approach using it in your project?

We treated AI as a tool: nothing more, nothing less. Or actually, a whole set of tools. Some are easy to use, even for non-developers. Others require serious technical knowledge, or even changes in how your whole workflow is structured. And like any tool, it only makes sense when you know exactly where it can help and where it can’t. Sometimes, introducing AI may lead to extraordinary results and more efficient processes. But sometimes, it just burns time and resources for very little return. AI isn’t magic. You can’t just throw it at a problem and expect everything to get better.

Dealing with AI opens up a lot of possibilities, and there’s always a temptation to try more things. How did your team manage to stay focused on the main goal?

It’s true. There were times when someone suggested a great idea—something we all wanted to create. Or we realized that the tools we’d chosen weren’t perfect, and we started thinking, “Maybe we should try a few other options and see what works better?”

But the reality is: you don’t have time for that. You have a goal and a very limited amount of time to accomplish it. So, we had to put aside sometimes even very good ideas and focus on the ultimate goal.

We saved some of these ideas for the “Future Improvements” section in our presentation. And in some places, we used tools that we knew we could replace later, just to keep us going. The most important thing is to focus on what you can finish, not what you can perfect.

In the end, your team delivered a working proof of concept. What was it like to achieve this goal? Would you repeat the experience again?

It was great and yes, I would do it again. It gave me a different perspective on how to build things fast, as a team, under pressure. There were presentations, there was a jury, there were winners, but honestly, there were no losers. Everyone tried something new, and everyone came out with something valuable.