I still remember my first conference talk. I was nervous and unsure, with a million questions running through my head. Is my topic interesting enough? Will anyone even show up? What if I forget everything I wanted to say? After speaking at ng-India, DevDays Europe, FrontEnd Nation, and many other international conferences, I can say that those concerns never completely disappear. You simply learn how to live with them and turn that nervous energy into something that can actually help you deliver a great talk.
Before You Submit Your First Talk
Many people think a conference talk starts when you walk onto the stage. In reality, the real work starts much earlier, when you decide to submit a proposal. And that is where I had to overcome my first major obstacle: the feeling that I had nothing valuable to share.
I had spent years working with Angular, solving problems, designing architectures, and leading teams. But somehow, I thought all of that was too obvious and that everyone already knew it. It wasn't until I started talking to other developers that I realized my "obvious" solutions weren't obvious to everyone else. Something that has become part of my everyday work could be a real breakthrough for someone else.
Choosing a Topic - What Do You Really Want to Say?
When I first started preparing for conferences, I spent a lot of time trying to come up with the right topic. I had several ideas, but none of them felt good enough. Eventually, I realized that the best talks usually come from real experience. You don't need to come up with something revolutionary. You need to share something you have actually experienced and learned from.
Most of the topics I chose came directly from problems I had faced in my day-to-day work. They were things I could talk about for hours because I knew the details, the pitfalls, and the solutions inside out. That's my first piece of advice:
choose topics you genuinely know, rather than topics that simply seem trendy or popular.
The Call for Papers
Most conferences have a Call for Papers, or CFP, where speakers can submit their talk proposals. Usually, you need to describe your topic, provide an abstract, and often include some information about yourself. Popular international conferences can receive hundreds of submissions, so your proposal needs to stand out.
I've learned that a good abstract isn't just a dry description of what you're going to talk about. It's a promise of value to the audience. Instead of saying,
"I'll talk about state management in Angular,"
you could say,
"I'll show you how to avoid three common state-management mistakes that cost my team weeks of debugging."
The difference may seem small, but it's significant. In the second version, the audience immediately understands what they will get out of the talk.
It's also worth remembering that conference organizers are looking for variety. Not every talk needs to be about the latest framework features. Sometimes a talk about successfully migrating legacy code can be much more valuable than yet another presentation about signals or standalone components.
Preparing the Presentation - Less Is More
When I got confirmation that my proposal for my first international conference had been accepted, I felt a mixture of excitement and panic. Suddenly, I had a deadline and had to create something that would be worth the attention of hundreds of people. That's when I made one of the most common mistakes new speakers make: I tried to fit everything I knew into a single presentation.
My first slides were packed with text, diagrams, and code examples. I wanted to show how much I knew. Feedback from more experienced speakers eventually made me realize that this wasn't going to work. People simply can't absorb that much information in forty-five minutes. It's better to say less, but make sure people actually remember it.
So I started again. I chose three main ideas that I wanted people to take away and built the entire presentation around them. Every slide had to support one of those ideas. If it didn't, it was gone. It was painful because I had to remove many things that I thought were important, but the final result was much stronger.
Slides - Visual Support, not a Teleprompter
One of the most important lessons I learned while preparing for conferences was understanding what slides are actually for. They aren't there for you to read from. They're there to support your message visually. If everything you're saying is already on the slide, why would people need to listen to you? They could just read it themselves.
I started following a simple rule: one sentence or one diagram per slide. Sometimes, just one word. This forced me to explain things in my own words and connect with the audience instead of staring at the screen and reading.
Code on slides is a separate challenge. At FrontEnd Nation, I had a presentation with lots of code examples. I learned that code on a slide needs to be minimal: only show what is absolutely necessary to understand the concept. Everything else becomes noise. It's much better to show five lines of code and explain them properly than fifty lines that people quickly scan and forget.
Practice, Practice, and More Practice
There is no such thing as too much practice. Before a conference, I usually run through my presentation many times. I practice out loud, in front of a mirror, while recording myself, with my family, and with colleagues. Every time, I discover something new. Maybe I stumble over a sentence, lose my train of thought, speak too quickly, or realize that an example isn't clear enough.
Recording yourself is particularly useful and, at the same time, painful. Nobody likes listening to their own voice, but it's one of the best ways to spot your own habits. I discovered that I had a tendency to say "kind of" and "basically" in almost every other sentence. Once I heard myself doing it, I could finally start working on it.
I also strongly recommend speaking at a smaller event, such as a meetup, before presenting at a large international conference. The audience is usually more relaxed about mistakes, there are fewer lights and cameras, and the whole experience tends to be more informal. It gives you a chance to see how the talk works with a real audience and a live Q&A.
It's also important to practice with a timer. Conferences have strict time limits, and going over your allotted time is unprofessional. At FrontEnd Nation, for example, I had forty-five minutes and needed to finish on time. That takes practice. You need to know how long each section of your presentation takes.
The Day Before - Logistics and Staying Calm
The day before my conference, I spent a lot of time checking everything over and over. Did I have the presentation on my laptop? Did I pack the charger? Did I have a backup? Did I know where the room was? Did I know what time I needed to be there?
It might sound excessive, but trust me: you don't want to discover a technical problem five minutes before going on stage. I've seen speakers deal with projectors that didn't work, laptops that died, or presentations that suddenly disappeared. Most of these problems could have been avoided with a little preparation.
I also try not to work on the presentation the day before the talk. If it's not ready by then, staying up late for a few extra hours isn't going to save it. It's much better to get some sleep and arrive on stage fresh than to stay up until three in the morning tweaking slides.
On Stage - The First Few Minutes Matter
I still remember walking onto the stage at DevDays Europe. Hundreds of people, bright lights, a microphone, and a heart that was beating like crazy. Then I remembered advice from a more experienced speaker:
the first thirty seconds set the tone for everything.
If you start confidently, the rest tends to follow. If you start uncertainly, you can end up fighting that feeling throughout the entire presentation.
That's why I always practice my opening lines until I know them inside out. I don't improvise at the beginning. I know exactly what I'm going to say, how I'm going to say it, and where I'm going to stand. It gives me a sense of control when the stress is at its highest. After the first minute or so, the adrenaline starts working for me rather than against me.
Eye contact with the audience is another thing I had to learn. The natural reaction is to look at the slides or stare at a single point on the wall. But a presentation is still a conversation with people, even if it's mostly one-way. I try to look at different people in different parts of the room and make brief eye contact. It makes the presentation feel much more personal.
Dealing with Questions
The Q&A after a presentation used to be one of the most stressful parts for me. What if someone asks a question I don't know the answer to? What if someone challenges my assumptions? Over time, I learned that this is simply part of the process, and there's nothing wrong with saying,
"I don't know, but I'll look into it and get back to you."
The worst thing you can do is pretend to know something when you don't. People can usually tell, and you lose credibility. It's better to be honest. Being an expert doesn't mean knowing everything. It means knowing what you don't know and being comfortable admitting it.
After the Talk - Networking and Feedback
A conference talk isn't just about the presentation itself. It's also an opportunity to connect with other developers, speakers, and organizers. After my talks, people would often come up to me with questions, comments, and their own experiences. Those conversations were often just as valuable as the presentation itself.
I also always ask for feedback. Not everyone will give it, but when they do, it can be incredibly useful. Maybe you speak too quickly. Maybe your examples were too complicated. Maybe the audience needed more context. Every piece of feedback helps you become a better speaker the next time.
Rejections Are Part of the Game
Not every talk I've submitted has been accepted. I've received plenty of rejections, sometimes without any explanation. At first, I took them personally. Over time, I realized that rejection is simply part of the process. Conferences have a limited number of slots and have to choose from many strong proposals. A rejection doesn't necessarily mean your topic is bad. It may simply not have been the right fit for that particular conference.
The key is consistency. Apply to multiple conferences, don't let rejections discourage you, and learn from every submission. With every application, you get better at writing abstracts, choosing topics, and presenting yourself.
Is It Worth It?
People sometimes ask me whether it's really worth spending so much time preparing for conference talks. After all, we're talking about dozens of hours of work, stress, and travel. My answer is always the same: absolutely.
Speaking at international conferences has opened doors I didn't even know existed. I've met amazing people, built collaborations that are still going today, and developed a stronger presence in the developer community. All of that has had an impact on my career in ways I could never have predicted.
But even without those external benefits, preparing a presentation is incredibly valuable in itself. It forces you to organize your knowledge, rethink things that once seemed obvious, and look at a problem from the perspective of someone who has never encountered it before. It's an exercise that makes you a better expert, whether or not you ever step onto a big stage.
Final Thoughts
If you're wondering whether you should try speaking at a conference, give it a shot. Start with smaller meetups, internal presentations at work, or lightning talks. Every talk gives you experience and brings you one step closer to bigger stages. You don't have to be perfect the first time. Nobody is.
I remember my own awkward first attempts and compare them with how I feel on stage today. The difference is huge, but it didn't happen overnight. It came from dozens of talks, hundreds of hours of preparation, and thousands of mistakes that I made, learned from, and fixed. You can take the same journey. You just have to start.
