# Bianca Buzea - Head of DevRel Chronicle | Privacy Academy Interviews

- Speakers: [Bianca Buzea](https://streameth.org/speakers/bianca-buzea)
- Channel: [Ethereum Cypherpunk Congress](https://streameth.org/ethereum-cypherpunk-congress)
- Date: 2025-10-09
- Duration: 13:05
- Topics: hackathon, web3, develpoer, dev, privacy, tips, web3privacy now, blockchain, Education
- Watch: https://streameth.org/watch/yt-U1M5XVkBAf8
- YouTube: https://www.youtube.com/watch?v=U1M5XVkBAf8

## Description

In this Privacy Academy Interview, we sit down with Bianca Buzea, Head of Developer Relations at Chronicle (the first oracle on Ethereum) and founder of DevRel Uni, to explore how to get the most out of hackathons.

From team formation & storytelling to avoiding common pitfalls, Bianca shares practical insights from her experience as a hacker, mentor, and organizer. Whether you’re new to Web3 or a seasoned builder, this conversation is packed with tips to make your next hackathon experience truly impactful.

Timecodes:
00:00 – Introduction: Bianca Buzea, Chronicle & DevRel Uni
02:00 – Why hackathons matter: Networking, learning & co-founder hunting
03:05 – Redefining “winning”: Beyond prizes & bounties
04:00 – Team diversity: Why technical + storytelling skills matter
05:00 – Common hackathon pitfalls & how to avoid them
06:00 – Practical tips for forming strong teams & preparing early
07:10 – Mentorship at hackathons: Unblocking & connecting builders
09:00 – Why sponsor booths are crucial: Real-world examples
10:40 – Ideal hackathon team: Technical execution + storytelling
12:30 – Final tips: Be curious, share your work & prepare before the event

This interview is part of Privacy Academy Interviews — a peer-to-peer knowledge project exploring the most important ideas in Web3, privacy, and digital freedom.

Links:
https://academy.web3privacy.info

Camera & sound: https://x.com/BabyBitProd
Interviewer: https://x.com/0xfarbey

Let privacy be with you!

## Transcript

[Music] Hi, I'm Bianca. I'm head of de at Chronicle. The team of Chronicle is the team behind the first oracle on Ethereum. Uh back in 2017, part of Maker in 2023 spun out of Maker and now we're serving Maker and the rest of the and projects across the rest of the web free ecosystem. I'm also the founder of Devil Uni where we teach people how to uh get into developer relations and how to uh work into such a field and build uh connections with other individuals in the space. In terms of my background, I used to work in web 2. I used to be a solutions architect in a big corporation. Then uh in 2017, I discovered web 3. I knew uh since then that I I want to go in that direction, but uh it took me until my very first in Denver to actually make the move and go full-time in web free. >> As a dev, I enjoy hackathons um a lot and I've been involved in hackathons in different forms. I've been a participant, I've been a hackathon organizer, I've been a judge, I've been a mentor. So I kind of seen 360 degrees if you want uh how a hackathon uh evolves how and how to >> uh bring builders uh together >> and I believe uh when it comes to hackathons a lot of the time people um it's important to kind of set your expectations both as a both as a builder but also as a organizer uh when we're talking about um hackathons because I I think there are different types of uh wins if you want when it comes to a hackathon from from the builder side. You might go uh connect with people in the space. You might go to evaluate if um web free is for you. You might go with an idea and you want to maybe find a co-founder. You might go just to explore with a new tech. There are like really various reasons for a builder to to explore this. But this also applies from the point of view or the organizers or different uh projects and partners who uh are contributing to a hackathon. And it's it's important for those to kind of have a clear understanding why they are doing it. For example, you might want to evaluate um how builders are interacting with a new uh product or your technology. You might want to get your documentation tested. You might want people to be aware about your stack. You might want people to experiment with it and build uh new things. So I think all these sort of um activities can can be great outcomes uh for a hackathon. When it comes to winning at the hackathon, I think again it's important to uh identify like what's your goal for the hackathon. For me, for example, the experience itself um can be winning. Making a new friend at a hackathon, that can be winning. You can have that friend for life. Getting recognized by someone from a protocol you really enjoy, that's also winning. So, different uh definitions if you want of winning beyond like the classical I won uh the bounty or I won uh the hackathon. maybe other uh tips if you want when you approach as a builder um the hackathon. I think it's important to to realize that a successful uh project and the successful ideas needs a diverse uh skill set. So I've seen quite a lot people focusing a lot on the technology which is great. You want to have that as polished as uh possible but at the same time you need to recognize the constraints of the hackathons and you need to be aware that the presentation itself and the explanation of why what you're building it's important are equally uh relevant sometimes even essentials for uh your project to get the the proper recognition in terms of u pitfalls I I've seen at hackathons uh maybe one very common one is team teams going at the hackathon getting excited seeing like the different tracks the different sponsors and then like trying to bundle as many as possible into one project. Sometimes you can naturally um connect more than one a few a few sponsors, a few projects together uh and it makes sense but other times I feel people are kind of pushing that artificially and at the end you might not get the the best results. So I would advise um against that. I would rather if I were a hacker, I would advise people to kind of focus on one to maximum three uh free sponsors, free projects that they are passionate about and to kind of go deeply into those to really try to understand uh what those projects are doing, how to best uh connect them uh with each other to go to the booths and try uh to speak with the people uh from those projects and to get a better understanding and support from their team and see what are the opportunities. even after the hackathons because a lot of the times those projects will be open to support you uh post hackathons to kind of uh ship your idea further. So I would really optimize for yeah uh rather going deeper uh with um more limited number of project rather than trying to take every possible sponsor uh from the event. In terms of team information probably I would say it makes sense to start before uh the hackathons and there are a lot of opportunities to to to do that. It can be in your circle but also if you're new uh and you don't know people uh to team up with you can also approach a lot of these hackathons are having different chats where you can introduce yourself. uh sometimes they're offering speed dating or whatever that might be called where like hackers can come and connect with uh each other. So there is really a lot of opportunities for you to um to connect with other builders and to identify who might be a good teammate. One one advice probably would be uh to share with others uh both the technologies that you're comfortable enough or and your skill set and to also be open with uh other people with other um other skill sets uh than you and to kind of optimize to complement uh each other with your uh with your talents. Probably the the top advice I would give to a young engineer who wants to enter the space would be to to be curious both curious when it comes to uh meet new people, experiment with uh tools, experiment with different uh technologies and to be open to to share your work. I think engineers a lot of the the time are a bit introvert and sometimes uh they don't they don't share as much as they could what they are working on what are their passions but when you put yourself out there a lot of opportunities are coming your way so yeah be curious and be open probably my my biggest learning since I entered the space and since I've been doing developer relations is to to be comfort to be comfortable with context switching especally Especially for a role such as developer relations, uh you need to to be able to do uh a lot of things. Uh one one activity you might do something with the engineers, then you're switching on the marketing side, then you have like some feedback on the on the product side. So you need to be uh comfortable uh doing different different roles and uh helping different teams. I think uh if you're a non-technical uh person and you're looking to connect with someone technical maybe to build a project it's important to present your skills because at the end of the day if you're looking at any project out there that the technical part it's essential and important but it's not enough. Uh the product won't sell itself the product won't uh have support uh by itself. So you need the different uh different sort of people with different uh skills to help you ship the product, go to market, find support, find investors. So I think there is a value in having a team which has different uh skills, different backgrounds. I think the the role of a mentor when it comes to hackathon, it's kind of uh twofold. In on one hand it's important that the the mentor is there cheer the builders helps them uh connect um with uh different uh opportunities different people relevant uh that could help them helps them unblock them when builders get stuck uh but also I think the mentor um it's important to kind of uh connect different people who are at the hackathon and help them find ideas, find uh people to work with. So I think uh both of these are are needed equally. I think speaking uh with the sponsors and going to the booths and speaking with the representatives when it comes to hackathons is very important and I can give you a very practical examples. A lot of the times we had uh so we work with with oracles and a lot of the times we we have builders coming to us showcasing us the the projects and giving us an overview of what they're trying to build and how they want to integrate and for example uh something I identify a lot of the times people come and say like I want to do this this oracle and use average for it but average is not really a good uh mechanism um to aggregate data Because if you're thinking you might have like some outliers and when you're doing average you the result uh won't won't be good will be skewed. So instead one what you want to use is you want to use median and this is something where very well known for any for anyone that works with oracles they will like tell you straight away don't don't use average go for median but when you're not uh working in oracles and you're just like a builder that is exploring tech and you don't have this insights you might feel like okay this using average might might be good might make sense you don't have like this overview but just by having this simple conversation come coming to the boot you might get this huge unblock that could save your project. So yeah, it's very important to go uh speak with the people at the boot. They uh get to know you. They can give you uh tips both for the hackathon itself but also post hackathon. When it comes to the perfect team on hackathons, I I don't think there is one size fits all. It really depends. I've seen uh solo hackers doing a great job. I've also seen larger uh teams but probably I would say at least uh you need to make sure you cover two very important areas. The first one is the technical area that you can't really skip. And the second one which is uh equally important is the the storytelling the the history and the explanation basically of okay why do we need this project why this uh product is important and how it will actually makes uh people's lives better. So if you have these two covers I think those are the the most important. The rest of course are like nice nice nice additions to your team but at least uh you need those two. I think probably one last uh tip when it comes to hackathon is to start early and what I mean by that is you even though you can't start writing the code before the start of the hackathon you can explore what are the the partners that will take part of the hackathons what is their tech stack and you can start preparing from that point of view. I think this will grant you a great uh head start when the hackathon actually starts. [Music]