From Engineer to Boot Camp Teacher to Senior Developer Advocate

Megan took every opportunity to develop the skills needed to land her first DevRel role.

Megan Majewski gives a talk

Series sponsor

Common Room logo

Megan Majewski

Senior Developer Advocate

Canopy

Detroit USA

Previous companies:

  • Shopify
    Ford Motor Company

Key Takeaways

  • Megan transformed her passion for teaching and introducing people to the field of tech into a career by volunteering in diversity and learning initiatives at work.
  • She then took up a role teaching at a boot camp, which helped her build developer education skills.
  • Megan’s advice is to discover what you enjoy doing in DevRel and then focus on getting involved in any chance to do that so you can gain the experience you need for your first DevRel role.

Megan’s Origin Story

Watch on YouTube

Transcript 

What is your current DevRel job?

Hi, my name is Megan Majewski. I’m a developer advocate at Canopy and I’m excited to share with you today how I got into the developer advocacy and developer relations world. A little bit about me and my background before we get started is I’ve spent about six months at Canopy so far doing developer advocacy. Prior to that, I worked at Shopify for about a year doing developer advocacy as well. And prior to getting into DevRel in general, I spent about six years doing various software engineering positions, most of which I spent at Ford Motor Company.

How did you get into DevRel?

So how did I get into developer advocacy and developer relations in the first place? Well, while I was at Ford, I was always really passionate about trying to get involved and get underrepresented people into the field of technology. And because Ford was such a big company, there were a lot of opportunities for me to get involved and volunteer in any way that I was interested in.

Usually for me what that looked like was volunteering with local girls who code or even Girl Scout chapters to teach them about the basics of technology. But I also would sometimes run internal classes for personal development days that Ford would set up. This could be more technical topics, like how to do TDD or basics of JavaScript, anything like that that people would be interested in for personal development days internal to Ford. 

So while I was at Ford, I did apply to work for Grand Circus, a local boot camp here in Detroit, Michigan, for an after hours bootcamp class because I loved teaching and getting people into tech so much. And this local bootcamp was specifically for women only who wanted to switch their career in technology and for me that was something that seemed like a perfect fit. From there, I ended up liking teaching so much and I felt so fulfilled by teaching that I really wanted to start incorporating volunteering and teaching and doing things like that in my day-to-day role.

That’s how I came across the idea of getting into developer relations and developer advocacy. I was doing a lot of research on my own on how I could combine both working in tech and also my interest in teaching and training and upskilling people.

How was the recruitment process?

So let’s talk a little bit more about what it looks like to get a job as a developer advocate and maybe even what it looks like to get a job at a bootcamp, which was my first step. I had two different technical interviews each about 30 minutes that ask different questions like what’s the difference between const and let? Can you explain a do loop versus a do while loop? Things like that. An interview even had me read through some code and explain what was happening to my interviewer. After that passed, I also was invited to teach a lightning lesson. This was a 20 minute lesson on any technical topic that I was interested in and I chose to teach the difference between all different types of loops.

That lesson took almost the full 20 minutes. I was supposed to leave some time for Q and A at the end, but by the time we got through it, there was only time for one or two questions. But I did end up getting the job and I was able to teach the bootcamp for six months. At Shopify, interviewing for the position was very similar. I had a person in my network that was already working at Shopify, so she was able to connect me with the hiring manager for the developer advocate role. We had a quick chat and then after I felt comfortable, I moved on to a technical interview. This was a hands-on keyboard pairing coding assessment with a Shopify engineer. This is because at Shopify the developer advocate position was in the engineering organisation. So I was expected to be highly technical.

For me, this is something that I was really interested in, staying technical, so it was important that the position was in an engineering organisation. From there, I continued to talk with other developer advocates at Shopify. One of the most interesting questions that I had during those interviews was: can you explain something to me in five minutes? And it didn’t have to be technical, they just wanted to see how I could step through some instructions in a conversational tone and teach the person how to do something or how to accomplish something. I thought that was a really fun question and I think it was cool that they were looking for how I can break down a complicated set of tasks into clear instructions and how I could communicate that. 

Now from Shopify, I did move over to Canopy and the interview process here was similar. I talked with the hiring manager and did a take home coding test. After that test was complete, I had a code review with a senior engineer on the team. And after I had passed that, I had a short interview with two engineering managers, specifically related to developer relations. They asked questions like, what is a piece of content that you are most proud of? What would you measure as a gauge on how well a developer experience is going in general? 

Did you have to learn new skills for your DevRel career?

Let’s maybe spend a few minutes talking about the difference between a regular engineering role and a developer advocate role. Each one of them came with different sets of challenges. When I was doing software engineering, it was, for me, hands-on keyboard almost all the time. You know, just banging out stories, writing code.

When I switched to the bootcamp, it was a lot of coding samples versus technical solutioning, and focused more on leading the students to the right direction rather than solving the problems for them. Now at Shopify, I also was doing some coding samples, but this was more based on migration guides. So, as Shopify would release new versions of their API, people were required to upgrade their solutions to fit with the newest API. I had never worked at a company with an external API and so many external developers before, so it was really a good learning opportunity to try and understand how external developers use different words than we might use internally, and how to help get them to the right solution, and how to help update the documentation appropriately. 

Also, at Shopify, this is the first time that I was expected to create content. I had never created YouTube video scripts before. I had never recorded inside my home. So it was definitely an adjustment to kind of switch from an engineering brain to a more content focused brain. I had to also think about how I might communicate certain topics with people and be thinking about what the next YouTube video that I could create to help people would be. And for me that was a very different part of my brain that I had to start exercising. 

What does your current job involve?

Now at Canopy what I do is mostly what I would call internal developer advocacy. So, because Canopy doesn’t have a public platform just yet, we don’t have any third party developers developing on our APIs. I mostly focus on making sure that internal teams work really smoothly together. So, day-to-day I sit with our internal platform API team. I try to really understand deeply what it is they’re working on, and then from there I kind of liaison between the hardware and the front end team to make sure that the platform API is working for them and they understand how to use it completely.

If there’s any feedback from either of those teams about how to improve that API, I try to work with the API team on how to incorporate that, and I also do things like helping smooth out the developer process in general. I recently worked to create a release ceremony process, which is put together to help coordinate how all three teams, hardware, platform, API, and the app team, can release their software, so they’re not working independently on each other or blocked by each other at any point. Additionally, I try to help debugging as much as I can. So, as teams prep for large demos or as things break, I try to understand just enough about each part of the software so that I can point anybody in the right direction if something goes wrong. Now, that’s all that I have to share about my background and my current experience in developer advocacy.

Do you have any advice for any DevRel hopefuls?

If I could leave you with something, I would say my piece of advice would be start doing things to understand what it is that you like to do. So for me, that meant when I was at Ford in my regular software engineering position, I knew I liked volunteering and I knew I liked teaching. So, I tried to get involved in any opportunity I could to teach and train and volunteer externally, while I was still in my regular software engineering role. I got a lot of experience and I got to learn a lot while I was doing software engineering that helped with my current developer advocacy position and I didn’t need to completely leave my software engineering role in order to gain that experience. And that’s all I have to share. I hope that was helpful for you and I’m really looking forward to hearing some of everyone else’s stories. Thanks.