In the first part of this blog, we understood what Developer Advocacy means and the definitions of different terms in the realm of Developer Relations. As promised in this part, we'll dig deeper into some common questions around DevRel, learning resources, and I will also share how I prepared for my first Dev Rel interview. As I am sharing my thoughts with the community, I am learning from them too. So feel free to add to my experience and share your views.
When is it the right time to become a full-time Developer Advocate?
There is no right time to start Developer Advocacy. If you've been helping the community with being a better developer, you're already a developer Advocate. Go ahead and tell your firm you would like to do this full-time. I personally feel your work as a developer advocate gets easier if you've had a good experience as a developer first. You can understand your audience well only if you've gone through the same journey. Well, in our case, same bugs.
I am bored of being a developer, so I want to turn to Developer Advocacy.
Ideal Developer Advocacy does not mean that you only talk and preach about your product. It also requires you to build and develop new material to help other developers have a better experience with your product. Being good at development NEVER hurts. If you think developer advocacy is all fun and no work, then my dear friend, you are up for a bad rollercoaster ride.
Remember, you are the face of your company in the developer community. It is very important to be empathetic, accountable, and reachable in times of need to the community.
Do I have to be a great coder to become a developer Advocate?
No. But being a great Communicator is important. There is always scope to learn more in Tech, and no one is the absolute best.
What does the day of a developer Advocate look like?
Well, let me talk for myself. On a normal day (when I do not have any events to handle), I find myself working on strategies to reach and onboard developers to our platform. Some amount of the day is spent in gaining feedback about our product and creating tutorials/blogs that make it easier for developers to adopt our product. However, on days of Hackathons or talks, catering to the doubts of the audience and navigating them through their issues takes the front seat.
Getting started right away
If you're reading this blog because you want to start your DevRel career right away, let's give you a roadmap. It is going to be a long process of building your portfolio and your skills, but it is worth it.
- Create your Github account.
- Create a Twitter and LinkedIn profile.
- Follow people from the tech domain, from DevRel, and learn from their content.
- Create and build more projects in the tech stack you are comfortable with.
- While you're at it, share your progress on Twitter and your milestones on LinkedIn.
- WRITE BLOGS (writing blogs has extraordinary benefits. Trust me or ask Sumudu Siriwardana).
- Start reading more documentations. Journal the ones you find very easy to understand and the ones you thought were tough to get through.
- Start contributing to open source. The best to start is by joining Eddie's community.
- Build a network of like-minded people and constantly engage with them. Support them with whatever you are good at.
- Attend meetups, webinars, and Twitter spaces on topics around community, opensource, devrel, and anything around tech that you are looking forward to evangelizing.
- Study different startups, their products, their customer personas. And if you're a go-getter (like me) who likes to create their own opportunities, go ahead and connect with the developers of that startup/product and share your feedback with them. You never know, an opportunity might be waiting for you there. This brings us to our next section
My interview experience and learning journey
I developed my interest in DevRel after following some amazing folks on Twitter. I have mentioned them in my previous blogs but here are some more who are my absolute favorites too:
1) Dalia
2) Patrick
3) Ravin
4) Kunal
5) Pratham
By the time the job was offered to me, I was deeply involved in learning what it takes to be a good DevRel person. But this would be my transition role, from Developer to Developer Advocate. I wanted to show what I could bring to the table and how. Way before the interview call was arranged, I had already gone through our product's website, documentation, blogs, and everything available online. Using my understanding, I created a game plan/ roadmap which I thought would help the company with its mission.
Tip: While creating a presentation for a company, make sure you not only mention the areas where they are lacking(because they already know that most of the time, and that's why you're being interviewed) but also the solutions you think will help in tackling those issues.
You can find a good amount of DevRel resources on DevRel Space And with this, we come to an end to this two-part series.
Believe in yourself, work hard and let compounding do its magic💖
Thank you for reading till the end. Also, make sure you check out Dasha. Follow us on Twitter for new features, giveaways, and lots of contests! If you build with Dasha, we’ve got you covered!