June 20, 2022

How To Become A Developer Relations Engineer


Ways to Change the Workplace with Prina Shah + Guests
For those who stand against crappy work cultures, lousy leaders and toxic teams!

Listen on: Apple Podcasts   Spotify

Transcript

Don Hansen:

All right. In this episode, we're gonna be going over what a developer relations engineer is and how to become one. Um, and again, I can wanna continue exposing a lot of these other tech and coding related positions that are, you know, kind of outside traditional, like front end, back end development, just to give people an idea of what's out there. Right? You can use your coding, you can use your technical skills. Land you a lot of well paying positions in tech. Um, so in this one, we're gonna dive into what being a developer relations engineer is like. So I invited Tarik, who is one currently. Um, I do appreciate you, cause I think you're, you're kind of trying to schedule this, um, as best as you could throughout your week. So I appreciate you being flexible,

Tarric Sookdeo:

but welcome. Awesome. Thank you for having me glad to be here. Um, okay.

Don Hansen:

So. I guess let's dive into kind of who you are. Do you wanna talk a little bit about your background and what got you into becoming a developer

Tarric Sookdeo:

relations? Yeah, sure. So I'm TA um, I'm a developer relations engineer at a FinTech company called Dola right now. And before this, I was a technical coach at, um, a coding bootcamp called flat iron school. Um, and before that I was also a student at flat iron school. Um, and prior to that as well, I actually did start off, um, getting a degree in computer science from, um, CUNY system in New York, from Queens college, however, um, ended up dropping out and going to a bootcamp and ended up here.

Don Hansen:

Gotcha. Okay. Mm-hmm so you, when you went to flat iron school, were you initially wanting to, to become a software engineer?

Tarric Sookdeo:

Yeah, so I was. You know, there was not a lot of light around these engineering adjacent positions. So yeah, I did go in, um, with the intent to become either a front end or backend software engineer. Okay. Um,

Don Hansen:

so why developer relations?

Tarric Sookdeo:

So after doing some research on the position, cuz when I was going through a job search, I did notice the position was popping up a lot. Um, Google was hiring developer relations, engineers, Amazon, Facebook, Stripe, and bunch of other startups. And after doing some research on the position, it turns out it's something more along the lines of what I would've wanted to do. So. Instead of just focusing on programming all day, develop relations engineers, also work hand in hand with marketing and, um, with the engineering teams and create content around the products that engineering builds. So

Don Hansen:

is it, so you're definitely more focused on the technical side, um, and creating technical documentation.

Tarric Sookdeo:

Yeah. So part of the role is creating, um, technical documentation and maintaining, um, SDKs and, um, creating blog posts and videos for around the product.

Don Hansen:

Okay. So you create content that's user facing as well? Yeah. Gotcha. gotcha. Okay. Um, Why? So what, so why focus on actually, let me ask you this. Um, why don't you want to focus on programming all day?

Tarric Sookdeo:

It's a good change of pace. Switching from programming to content, um, pretty much at will. Um, it leads to, I guess it leads to less burnout that way. And the context switching kind of have you deep dive more into the product, just because you're spending more time with it. Um, because you're including content, understanding the nitty gritties of it and whatnot.

Don Hansen:

huh? Okay. I mean, as a, as a software engineer, I definitely enjoyed getting interrupted. Um, I liked breaking my day up for sure. So I'm definitely not someone that can just, that wants to code for seven hours straight every day. Yeah. Do you feel like you have to, I guess what departments do you usually interact with? Um, to figure out like what content and documentation you have to create?

Tarric Sookdeo:

Yeah. So that's another great part about being a developer relations engineer is we interact with a lot of departments. So the ones I interact with mostly is marketing and engineering, but we also have a pulse on our developer community, more than any other team, because, um, you know, that's pretty much who we're creating content for creating these SDK for, and, um, So I would say about 70% of our interaction is with engineering, another 30% with marketing, but of course every company handles developer relations, slightly different. It's not necessarily a well defined role. Like,

Don Hansen:

you know, I noticed that, um, cuz I actually. It's weird saying this because it's still currently a recording, but I'm going, I talked to someone else that's in, um, his title was like developer advocate and I feel like he explained that there's tons of variations among this type of position. Um, yeah. What keeps you there? What do you enjoy about

Tarric Sookdeo:

it? Where I work tends to be very flexible. And I get to have a lot of ownership of the work that I do. So I enjoy that a lot. Um, there's guidance, but never pushing and yeah, what keeps me here basically. I, I like being close to the action, so to say, And again, having that pulse on our developer community, like what they want, what they need, um, gives the devel teams a lot of input on both the marketing side and even the product side outside of our team. So I. There's definitely a lot of ownership in the, in the roles of devel and, um, you know, a lot of cross team communication, which is, is nice to have, um, because in standard software engineering, you know, there's never really much talking with marketing and stuff like that. Um, but yeah. Yeah, that makes

Don Hansen:

sense. Um, again, I guarantee you, some of my, uh, team members were annoyed, cuz I'd always wanna. Talk to departments I didn't need to talk to, but I, I liked, yeah, I think it's really interesting. I'm someone that's multifaceted and I am interested in a lot of different things and departments and, uh, different, uh, pieces of a business and how it operates. Um, yeah, I, I mean, that's why this kind of position kind of seems attractive to me specifically, but you know, going to a cutting boot camp, you're spending a lot of money. How much was flat iron.

Tarric Sookdeo:

flattering when I attended was 15,000 for the full-time boot camp that I attended. Okay. I believe the price that was two years ago. So it definitely went up. I don't know the current pricing though. Okay. Mm-hmm

Don Hansen:

with their focus on software engineering, do you feel like for your current position, you're now over prepared technical

Tarric Sookdeo:

wise? Technical wise, I would say I'm just enough prepared. Um, you know, there's only so much, you can teach somebody within three to four months of a bootcamp, enough to get a job. And then, you know, the remainder gets learned as you go. Um, but yeah, I would definitely say that the bootcamp is worth it for people looking at it as a career path or a career change

Don Hansen:

for dev relations specifically.

Tarric Sookdeo:

So the catch with Derell is you still have to know how to program very well. Um, so yeah, it does give you that, that skillset. Um, so yeah, I would say it's still definitely worth it.

Don Hansen:

Are there any other skill sets that you recommend people pick up if they wanna get into that?

Tarric Sookdeo:

Yeah, definitely. It doesn't hurt. Creating content. Um, and this can be any kind of content, um, video content, blog posts, social media posts, things along those lines. Good thing is a lot of people do have this skill set without even realizing it. Um, but yeah, having that skill set is important endeavor just because you are, um, externally facing a lot. Um, but yeah, other than that, Communication skills are really important because you are communicating with other teams that might not necessarily have technical skills. And you have to, for example, communicate with marketing, um, how to market these, these products that are highly technical, such as like, do we have a sophisticated account to account payment API, you know? Um, so definitely how to communicate technical concepts to a variety of audiences. Um, is important as well. So you,

Don Hansen:

it almost sounds like, um, you also need to get better, not you specifically, but just get better with explaining technical concepts to non-technical people as well. Do you find that challenging? Yes.

Tarric Sookdeo:

That is the hardest part of like, not the programming, not the creating content. The hardest part of the job is explaining technical concepts to non-technical people. Okay. I love it.

Don Hansen:

Um, mm-hmm I feel like a lot of people can relate to that. A lot of software engineers anyways. Yeah.

Tarric Sookdeo:

Um,

Don Hansen:

what kind of content did you create to get this position?

Tarric Sookdeo:

So I had a technical blog before starting this position, which I had no intent of going into developer relations. I just had the technical blog because I actually did enjoy, um, putting out like tutorials and different content related to, um, technical concepts. So that's one of the reasons why when I found developer relations, I realized like, oh, this is more up my alley rather than again, coding eight hours a day. Um, but of course, again, being part of developer relations, you are still spending a decent portion of your day programming, reading, code examples, things along those lines, um, and creating, supporting code around the core product such as SDKs. Um, so you are still honing that skill, but you're also honing your, your technical communication skills as well.

Don Hansen:

Do you communicate a lot with users?

Tarric Sookdeo:

The devel team does. So me specifically, I do spend time definitely, um, communicating with users, but, um, we do have forms and other ways of communicating with, um, our developer community, but the team does. Yeah. okay.

Don Hansen:

I guess this is more of a selfish question too, cause I, I guess I'm just really curious about this when you get a developer relations position. Um, I've definitely heard other people with disposition mention that like, well, they were already content creators. Right. And I think that's something that did give them a little boost in the interview. Um, mm-hmm . But I've also heard concerns about like maintaining the rights to your own content. Do you, are you aware of like companies trying to kind of, I guess just push that boundary a little bit and try to gain some ownership of it? Like, do, do companies feel, I guess, entitled to your content while you're at that company?

Tarric Sookdeo:

Yeah. So this is definitely a conversation. That should be had at the interview stage for developer relations roles. And it, there should be a clear boundary. Um, I have heard those same stories where companies try to own the, the content of the, um, the developer relations employee, but there should be a clear. Boundary between your personal social media accounts versus the companies. And there should be a clear boundary between content you create for the company or content you create on your own. So, um, it is, that does happen, which you just mentioned, but it should be a conversation and an expectation that's set at the interviewing steps.

Don Hansen:

Okay. I like that. That's really good advice. Yeah.

Tarric Sookdeo:

How do you, oh, go ahead. Oh, yeah, I was just gonna mention yes. So for example, the company should have like a, a specific Twitter account for the developer relations team, um, where that's, where those social posts go and whatnot. So there's always, should be a clear cut there. Yeah. That's just one example of it though.

Don Hansen:

No, I like that. Um, because I think. even when you give suggestions, like even for software engineers, um, there are some states that don't protect software engineers that will build projects in their own time with their own resources. Right. And I think even just understanding what to look out for and the contract, um, where it does split those boundaries is important. And like you said, you know, essentially, maybe that contract should state. The company's social media handles in the content creator within that. Yeah. That's probably like, I'm not an attorney talk to an attorney, but that, you know, probably something to, to look out for in that contract. Cause I, I, I always feel like even when I would go to developer interviews, I'd get the, um, the acceptance letter or the offer letter. And I always felt like I never had the contract explained well enough. And even when I would ask about a specific clause, I think even some C. They just outsource those contracts to attorneys and they don't even fully understand them either. And so, yeah. I don't know. I, I, I just think contracts are really important to just make sure you understand everything fully.

Tarric Sookdeo:

Yeah. I agree with that a hundred percent. Um, luckily where I am there's, there's no issues like that. There's that that clear boundary does exist. Um, But, yeah, it's definitely important to get help understanding your employment contracts, especially in tech, just because these employment contracts can be complicated with, you know, salary, stock options. Then these little nuances with, again, what you can put on your own personal social media accounts and all that. Yeah.

Don Hansen:

Yeah, absolutely. That's really good advice. You had mentioned that like your, your focus really is to make sure the developer experience is great, right? Yeah. But what's like, what's your metric for that? How do you know?

Tarric Sookdeo:

Yeah. So one of the most important metrics to measure for this is time to value, meaning. DUIs sells an API product. So the customer, our developers, and how long does it take for a developer to find our product, decide to use it and have a MVP, um, up and running. And if your time to value is relatively low, meaning like, let's say they can have a minimum viable product in 30 days. Chances are you're having a really good developer experience. They're finding what they need in the documentation, in the external supporting content or even other people in the developer community are, are helping out, um, that are necessarily related to dollar or do content. Um, so I think that's the most important metric. to measure for that. Okay.

Don Hansen:

That's um, I mean, yeah, that essentially like focusing on that output that's that's interesting. So you don't really lean on, do you, do you post surveys for developers that

Tarric Sookdeo:

you do? Yeah, so again, I think time to value is definitely most important and taking in feedback from surveys. Um, and having open lines of communication between your developer, um, community such as like a slack channel and things along those lines, um, is important. Okay. I gotcha. All right. Um,

Don Hansen:

that's interesting. I do you, do you find there are any frustrating moments around creating documentation in your position? Can you think of.

Tarric Sookdeo:

Yeah. So whenever you have a product that is, you know, dwells product is fairly complicated. It's account to account payments. You have to not only deal with the issues of technology, but the legal issues of the whole banking system and all the problems that comes with. So abstracting all of that away to. API calls is difficult and can be frustrating, especially to developers who don't necessarily, it's important to think about the legal aspects of stuff, but don't necessarily think of it as like the most important aspect. Like how do you display balances to a customer? Um, why can't it be real time things along these lines? Um, So I think the frustrating aspect is probably dealing with the industry itself in terms of like account to account payment and trying to combine it with technology.

Don Hansen:

Gotcha. Yeah. Industry knowledge, uh, especially around, um, industries that require like, uh, tight knit security and protocols around user data, especially that can get. frustrating for a lot of people.

Tarric Sookdeo:

Yeah. I think the most annoying one is probably like healthcare with the HIPAA requirements. Mm-hmm I, I don't envy those developers at all. They have a, a tough time.

Don Hansen:

Yeah. I, I mean, thankfully I wasn't on the back end team for my first position. Yeah. But we worked at like, um, kind of, you can order health services and we would set you up with the lab testing and we had to deal with a lot of HIPAA compliance, even just like. I mean super strict protocols, um, knowing all the information that you can and can't even mention in slack, cuz it's not HIPAA compliant and there are other chat features that are, um, or maybe slack is with like an enterprise Fe. I don't know. But they said it wasn't. Um, okay. That makes a lot of sense. I get. So like for your technical knowledge, do you feel like. Focusing a little bit more on backend or front end would benefit you in a developer relations position.

Tarric Sookdeo:

Definitely backend. Um, most of the code that I write circles around, um, SDKs and sample projects related to these SDKs. Um, and again, I could be biased here because do sells an API. So it's like, it is backend stuff at the end of the day. Um, true. But yeah, definitely more backend for me.

Don Hansen:

Okay. I gotcha. Um, okay. I mean, to, to be honest, the way you describe it, it almost sounds like it's. Harder to get into a developer relations position than a traditional software engineering position, because the way I'm hearing it is like, you still feel like you needed a full coding bootcamp to essentially get the technical skills, but you also need to work with multiple departments and be able to explain technical concepts to non-technical people which you'll do as a software engineer a little bit, but probably more as developer relations. And you also need to be able to write documentation. So you need to focus on writing. You're interacting with the users a lot more, which like, you know, product UX will probably take that role from software engineers, but you, you're kind of doing all of this. Do you feel like it's harder to get into your position than a traditional role?

Tarric Sookdeo:

Whew, that's a tough question. I would say they're on par with each other. Um, You do need to have a higher level of those so-called soft skills in developer relations versus standard software engineering. But in terms of the interview process that I went through and, um, everything else they're about the same and requirements and whatnot. So I would say getting into them are. The same level of difficulty. I would even say the jobs themselves are the same level of difficulty. It's just how they're split up. Um, as what's different, like how the day to day is split up. Okay.

Don Hansen:

Um, what was your interview process like for the dev of role?

Tarric Sookdeo:

Yeah, so, um, Applic application. I'm just gonna go right through the process here. Sure. Um, you know, start off standard application where resume, cover letter, whatnot. Um, then it was a technical assessment that was a take-home assessment followed by a, um, a technical interview. And then a, like the other interview, the behavioral or. You know, the follow up to the technical, not many technical questions to ask just more about you scenarios things you've worked on projects, whatnot. And then that was yeah. Offer a new offer at that point. Okay.

Don Hansen:

Um, okay. So you had a take home and then a technical challenge when you got to the office or interview? Yeah. Okay. Don't, you know, we don't have to leak anything, but, um, Are you able to share anything about like the difference between the take home and the technical challenge, what people should expect?

Tarric Sookdeo:

Um, the take home is definitely, I found that a little more challenging just because I'm assuming they, you know, the take home, they're thinking you're gonna spend a couple hours on it versus 45 minutes to an hour on the technical interview portion. But, um, The good thing about my interview for my role was it didn't involve any of the, those trick algorithm questions that have nothing to do with the job. They were actual questions about debugging, like node calls as, um, node fetch calls and all that. And, um, Yeah. One of them was, if I remember correct, was about the O or two specifications, um, how they debugging something with that as well. Okay. Interesting.

Don Hansen:

They didn't, did they look at any of your content or, um, give you any sort of like writing tests or

Tarric Sookdeo:

so no writing tests? They definitely did check out my content. From before though. So I'm guessing that's why that wasn't included. They figured I already have writing content and checked it out. Gotcha. Okay. That makes sense. Pro tip. Yeah. To pro tip probably for dev interviews is, um, if you do have a take-home assessment, I ended up like being, doing like a little extra stuff and creating a YouTube video to describe it. Um, For a position that might go circle around content creation, stuff like that. That definitely, um, could help out a lot, like going an extra step compared to other candidates. I like

Don Hansen:

that. That's a nice pro tip.

Tarric Sookdeo:

Yeah. Okay.

Don Hansen:

I, I do appreciate that. So I feel like. You know, cuz especially with the last interview, I feel like yours is, it sounds like yours is a lot more technical and you're doing a little bit more coding than my last interview, but I could be wrong with that. But it, it does feel like a little bit more of an encompassing position that could have a variety of responsibilities depending on the company, depending on the product. Who do you. Who do you think would even enjoy this position? Like what kind of person do you have to be to enjoy this position to do well in it to succeed in it?

Tarric Sookdeo:

Yeah. I think anybody that would enjoy normal software engineering, but wouldn't necessarily wanna spend their whole day programming, um, or focus on like, you know, Coding all day long, um, somebody that enjoys programming for the most part and also does enjoy, um, like you said before being interrupted to create content or to help an external developer solve a problem about the product that, um, you're creating content around. Um, I think that context switching again, leads to less burnout and. A deeper understanding of the products that you're, you're ultimately building. I

Don Hansen:

like that. Do you think you need to be interested in the product to get a dev role at that company?

Tarric Sookdeo:

Yeah, you definitely do. Um, again, you're, you're spending a lot of time marketing the product, creating social posts, things along those lines. So understanding the product is needed because. Worst cases. Now you end up marketing a feature that actually doesn't exist or something along those lines, you know? Okay. But yeah,

Don Hansen:

I like it. That's good feedback. Um, I highly recommend people because I, I see people in LinkedIn or they even will post their blog posts on LinkedIn, YouTube videos on like, there are definitely. People that love creating content and exploring the depth path. And this feels like a really cool combination to just blend those in. Um, if you enjoy both, um, I think it's a position you should consider. Do you feel like it's pretty accessible to entry level people?

Tarric Sookdeo:

Yeah, I think so. I think the flexibility of the role makes it accessible to entry level. Just because again, your day isn't gonna be. programming all day long and you have flexibility to, to learn a little more and grow with it. Okay.

Don Hansen:

Let me challenge that a bit. I've heard a few larger YouTubers that kind of talk in private chats, um, that they mentioned it's not very entry level friendly. And they usually suggest people become software engineers for maybe a year or two, and then transfer over into that. Do you know of any reason why that might be the case?

Tarric Sookdeo:

Yeah, I can see the reason for that. If you have a more complex product, um, then it can be very useful to, to have the engineering experience on that product before going into a Devra role. Um, so I can see where that argument comes from as well.

Don Hansen:

Okay. So you think they're suggesting to get a developer position at that company and then transfer within to a dev role?

Tarric Sookdeo:

Yeah, I think that can be useful. Um, that could that's I know that's the traditional path to take. Um, so it's definitely a useful ones take for, for the reason of learning the product before you create content around the product.

Don Hansen:

Gotcha. Okay. So that's a traditional role, but it doesn't necessarily, but you could probably like be a user of the product and understand it pretty well as, you know, without going into the engineering,

Tarric Sookdeo:

right? Yeah. Um, that is something as well. We actually did recently hire somebody at Dola for, um, part of our devel team that used the product before. That's pretty cool, really good developer, but never was a developer on the team. . Okay.

Don Hansen:

Yeah, that's interesting. All right. So it sounds like there are a variety of different paths, but, um, you know, if you have a blend of essentially creating content, you care about the users, you care about the product and you wanna do some dev work, but not spend all day coding. It seems like a good blend. Um, I feel like I have a pretty good feel of it. I feel like you've given pretty good advice on even how to get into. and, um, because again, I think that reputation of dev relations, it, it does have some reputation of it's not entry level friendly and it clearly is because you weren't traditionally, um, a software engineer. I mean, you were a technical coach. Yeah. But, um, that's not traditional software engineering for sure. Yeah. So, okay.

Tarric Sookdeo:

Sounds promising. Yeah. I would also add that. If going into a company straight up as a developed relations engineer, just expect there is gonna be a learning curve. So like when I went into do it, wasn't just learning about do's products as a learning curve. It was also the whole landscape of account to account banking, payments and whatnot. So I went in. , they were really nice of me being useless for a couple of months. um, and yeah, allowing me the space and room to grow and answered my million and one questions, but definitely expect the learning curve if going directly into dev role into a company.

Don Hansen:

Okay. I like it. Um, that's really good. Yeah. That's really good advice. Before we wrap up, is there anything else you want to.

Tarric Sookdeo:

Um, you don't have to. Yeah, no, I'm

Don Hansen:

good. Awesome. All right. I like to make sure cuz sometimes I just keep, you know, firing off questions and they're like, oh, I wish you would've asked this. So I always give that chance at the end. Um, okay, cool. Yeah. Seriously, te I, I do appreciate this. Hopefully this is helpful. Um, you know, let me know what you think of the comments. If you're even considering this type of position, if you feel like it's your fit. um,

Tarric Sookdeo:

but if people wanted to reach out to

Don Hansen:

you and anything else you wanna shout out, what would you like to share?

Tarric Sookdeo:

Yeah. Um, if anyone wants to reach out to me, they can definitely reach out on LinkedIn. Um, and you can check out my blog as well, and I believe we can link them down

Don Hansen:

below. I can link the blog in the description for.

Tarric Sookdeo:

awesome.

Don Hansen:

All right, cool. Well, that's pretty much it. Um, let me know what you think of the episode. Seriously. I'm very curious. I wanna continue exploring these positions and I can tell you, um, out of. All at least outta most of the non-traditional software engineering positions. I've definitely, I used to have my eye on developer relations. I just didn't think it was accessible. Uh, but I do love creating content and I do love coding. So it's, it's a good blend for me, but let me know what you think about it for yourself. Um, seriously, Tara, thanks so

Tarric Sookdeo:

much for coming in. And so thanks for having.