DEV Community: Mandy Moore

Scaling the DevOps Career Ladder with Eran Bibi

Mandy Moore — Wed, 30 Mar 2022 12:56:35 +0000

Eran Bibi is is a Founder, CPO, and DevOps Engineer at Firefly, a Cloud Asset Management solution that enables DevOps and SRE teams to rediscover their entire cloud footprint, understand which parts of it are codified vs. unmanaged, detect drifts to prevent service failures, and manage a single inventory of all their cloud resources across Multi-cloud, and Kubernetes deployments.

In this episode, Eran talks with host Aaron Bassett about making the switch into DevOps, his career transitions from Individual Contributor (IC) to management and back to IC again, then taking a Director position, and eventually founding his own company.

Links:

Firefly (Twitter | LinkedIn)
Eran Bibi: Twitter | LinkedIn

Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!

Give us a follow: @PolyglotShow

Scaling the DevOps Career Ladder with Eran Bibi

Polyglot

Your browser does not support the audio element.

1x initializing... ×

Transcript:

Aaron Bassett: Hello, everyone, and welcome to another episode of the Polyglot Podcast. I'm joined this week by Eran Bibi. Eran is a Founder, CPO, and DevOps Engineer. Hello and welcome to the show, Eran.

Eran Bibi: Hi. Thank you for having me.

Aaron: No, thank you for joining us. I know we had a little conversation in the run-up to the show last week. And I was already really enjoying that and was trying not to have too many spoilers as we talked about what we were going to go through this episode. So I'm really excited to get stuck in and really get some of these answers out of you. So let's go right back to the start.

So for people who are just tuning in to Polyglot for the first time, we sometimes like to go through people's journeys in technology and how they got to where they are now. And obviously, Eran being very successful in the DevOps space and now founding his own company; we wanted to look at what that journey is like. And let's go back really to the start. So what got you interested in technology to begin with, Eran?

Eran: I think it was...like, I started to be curious about stuff that related to computers early in my life. So I think my first PC was when I was ten years old.

Aaron: Oh, wow. [chuckles]

Eran: Yes, it was like an old IBM kind of PC with Windows 3.11. I think it was the first operating system. One of the things that was very standout is that curiosity about how stuff is being built behind that screen. So I was finding myself trying to open that metal box and understand all of those pieces. And I think; basically, I fell in love with the concept that with a few pieces wiring together, I can get something in my screen, and I was just trying to understand how it works.

Aaron: Yeah, it's kind of a weird concept if you think about it. It's like we took a bunch of sand, electrocuted it, and now suddenly, it can think. Computing, in general, is just really odd. [laughs] But yeah, I'm much in the same boat; I think I started off with a Commodore 64. So I know that same feeling of being enamored from a very young age. But you started off in engineering and a little bit of system administration and things. But it looks to me like you made the switch pretty early on in your career into DevOps. What made you interested in that niche in particular?

Eran: So I was starting my career basically in the Israeli military. So my serve was being a system administrator of one of the units, and it was all based on the operating system, and configuration, and a bit of hardware. But then, when I completed the military service, I was very interested about stuff that is more complicated, more toward development. And I got a very good decision when I look back to get more knowledge about the Linux system. Specifically, in Israel, there was a very nice education around Red Hat operating system. So I did a deep dive course on that.

And then I was just trying to find some company that I can work doing Linux and sysadmin stuff that related to Linux. And so, this was the first step in my career toward what we call, right now, DevOps. But it will really change with the years. But I think the main portion was about trying to automate stuff and integration of pieces and integration of software. So that was the initial state of my career.

Aaron: You started off looking really then at operating system levels, and that's what got you interested in the DevOps space. I think what I probably should have done beforehand is let's give listeners a little synopsis on DevOps then. So when people say DevOps, what do you envision? What does that mean to you?

Eran: So right now, DevOps is really tied to cloud-native workloads and how you're supposed to manage your infrastructure and workloads in an automated way. But it was very changed if I'm looking back ten years ago when DevOps was started. It really was about that sysadmin skills with the programming capability, integrate. Most of the organization was a separation between operations and development.

So DevOps was the first step of having a sysadmin and integration capability into the development lifecycle, so that was DevOps like ten years ago. And right now, it's really about cloud engineering and doing stuff in an automated way and basically supporting the development team to work in high scale when pushing a lot of changes into the cloud and making sure nothing is breaking.

Aaron: Great. Yeah, I think that's a pretty good synopsis for everybody listening who has not come across that term before. It is a huge area in technology, which is something that we're very interested in at New Relic. There's a lot of crossover there between seeing what we would do in DevOps.

So let's move on then. Before we get into Firefly, which is the company that you co-founded and currently are Chief Product Officer, before we go into Firefly, there is another company you worked at for a substantial amount of time. And I think if I remember correctly, you told me you were employee number 20 there, and that's Aqua Security.

Eran: Yes. So Aqua Security was a very young startup when I joined them in early 2017. And I was employee number 20 and the eighth or seventh person in the R&D and in engineering. And for me, the decision to try to do a startup was because it was a very exciting period in time in terms of technology. So Docker container workloads was just introduced and becoming more popular. And I thought to myself; I would like to do something that is really related about technology.

So I did the shift of doing DevOps in a fintech company to do DevOps in a company that more related...like, the business of the company is more related to the stuff that interested me. And Aqua Security which is, in one sentence, a cloud-native workload security company, I thought was a very good fit for me to try to do the stuff that I love and also be more related to the business itself.

Aaron: And you joined Aqua Security as an IC. So you'd been kind of on a management track previously. And then whenever you made that move back to Aqua, you went back to being an IC. And for people listening, sorry, I keep using terminology here. IC is an individual contributor. So an IC is somebody who is not a manager, doesn't do any people management. So you'd been a people manager before in your previous role, I believe. And then you decided to move back to an individual contributor role at Aqua. What spurred that decision?

Eran: It was a counterintuitive decision because I was on my way up in the management skill and also with the stuff that I did in the previous company, and everything looked very promising. But I know that in that specific stage, I had to get the decision to go back and do an IC role again in order to achieve and fulfill my wishes in being in a startup company because I didn't have the option to come to Aqua Security as a senior manager.

So I basically bet that Aqua will grow, and I will grow with them. Again, I was betting, but I also really believed this is what will happen. I thought to myself, okay, I will go back and do hands-on without any people reporting to me and doing only stuff that's related to coding and pivot my career. But again, Aqua Security was growing so fast, so I found myself, after a few months recruiting the first member in my team.

Aaron: So you weren't an IC for very long then. You were very quickly back onto that management track.

Eran: Yes, and it basically was very natural for me because this is the bet that I took. I thought that Aqua was going to explode, again, from a very narrow perspective when I decided to join Aqua. I really believe in that kind of solution that Aqua is offering and also the trend that everything is going cloud-native and containerized, and this is the space that Aqua was born. So it was like a hard and stupid decision in one end, but when you look at it, it was very obvious that I will be going and expanding my team very, very soon after I joined Aqua.

Aaron: You were going back as an IC, but you always had it in mind that you wanted to go back into that management track eventually then.

Eran: Yes, because I had that passion for doing more business-related activities. So on one end, I really like engineering and hands-on. But that stuff that related to being a manager and being more close to the business, I was really attracted to that. When I had the opportunity to go with Aqua, this was like a no-brainer for me.

Aaron: It's interesting because I've done the switch myself as well. I went from being a very senior-level manager back to being an IC. But I went back to being an IC with no intention of ever being a manager again. It was a very conscious decision. I did not like management. I did not want to be a manager. I don't enjoy it, and I'm awful at it as well. Let's be honest; I am a really bad manager. I have a hard enough time keeping my own Jira tickets [laughs] in order, never mind managing other people's, and I just don't have that kind of --

Eran: There is some bad side for that for sure. [laughs]

Aaron: And I always feel I'm doing a disservice to people I manage as well by not giving them the attention that they require. I very much just want to go off and do my own thing. Whenever I made the switch back, (The switch was a little bit of time ago.) I know, at least at that time, there was honestly a bit of a negative connotation from my peers of, like, why would you give up this high title to go back to being an IC? Did you encounter any of that at all?

Eran: Yes. And that's why I also mentioned that decision like a stupid decision because people did not understand why it makes sense for me to go and be an IC after I was building myself, and I have a very bright future as a manager. But again, I did it with the state of mind that eventually, I will become a manager again in Aqua.

But if I'm looking back on those, I don't know, ten months when I was an IC in Aqua before even onboarding the first member, I was really, really enjoying that. It was reminding me how fun it is without handling priorities and other stuff that is related only to management kind of activities. But after ten months, [laughs] I thought to myself it's a good time to go back and try to build that management career.

Aaron: I just want to point out to anybody listening that this is obviously a very valid way and a way that people do go. But I just want to say for other people like me who may not want to go down the management track, there is, thankfully, these days, it seems to be a lot more common for there to be career progression and career ladders for pure ICs up to principal, and distinguished, and fellow. We have a lot of options now. But what was your ladder like going from IC to director then in Aqua?

Eran: It was related to the growth of Aqua and the importance of the function that I was managing. So I was starting as the one that's leading the DevOps. But because the company was growing so fast, there were a lot of opportunities to do much more than that. And because I had that hunger to be exploded with Aqua, I was trying to do more and more. And when I got that trust from the higher management, they were willing to give me more investment and more resources to do more stuff.

And then it was just natural. I was like a team leader. And then, I had a few teams under my court and eventually promoted to director with few teams reporting to myself and doing much more than DevOps. But again, it really depends on the macros. Aqua was looking for those individuals that have the capability to carry more and more and more function, and I was willing to do that. I really enjoyed that. The first two years and three years in Aqua were amazing for me.

Aaron: So you mentioned you had a couple of teams under you, and then that grew in size, and you progressed up to director, et cetera. Have you heard of the two pizzas for team size limit? Have you heard of that before?

Eran: Yes, of course. [laughs]

Aaron: Is that something that you prescribe to? What is your ideal team size before you think oh, we need to have additional managers here?

Eran: It's a good question. And there is a playbook for that. But eventually, there are much more constraints in real life, you know, the budgeting if you find someone that can lead that team. If I'm looking back on the Aqua scenario, everything changed really, really fast. And it was very hard to find appropriate candidates to do that step up and take a team lead position. And so it was very different than the typical playbook and pizza size kind of split.

Aaron: [laughs] Yeah.

Eran: I was in some cases with, I don't know, more than ten persons reporting directly to me, and it's not the ideal, let's say.

Aaron: That's a really large pizza you're going to need there.

Eran: [laughs] A lot of slices, right?

Aaron: Yeah. [laughs] Oh, for listeners who are not…I'm pretty sure it originated on Amazon. I don't know why I'm so sure about that, but I'm pretty sure it was Amazon.

Eran: Yeah, yeah. I heard about that too.

Aaron: The whole thing is that they say that the team should be no larger than you can comfortably feed with two large pizzas. That's kind of their rule of thumb for the size of a team. So yeah, if you're getting up to 10 people, those ten people need to not be very hungry, or it needs to be two very large pizzas. It is, as you said, you kind of make do with what you can. Sometimes budgets and recruitment make it difficult to get the team sized the way that you would want to.

Eran: But I think five or six people in a team can work very well. And also, here in Firefly, we were able to establish a very nice engineering group, and they are divided into something like five persons in a team. And again, from my perspective, it's working very well. There is also some reserved capacity for the team lead to do also hands-on and not just making sure everything is aligned.

Aaron: Yeah, I've been approached by companies in the past and you kind of look at the company makeup, and it's like they're so top-heavy sometimes. It seems like everybody is something in management. And there are only like three developers in the entire company, and you're like, okay, what are the rest of you doing all the time? But yeah, I think the five kind of in a pod for me is I feel also that's the most comfortable kind of position to be in.

You have enough people where you do have some slack if something should come up or something should arise, or somebody goes out on parental leave. It's a big enough teamwork, and everybody can pick up the slack for each other, but without it being too large that it gets to the point where even as an IC, you don't have visibility across what your colleagues are working on and where they maybe have bottlenecks or where you might be able to assist.

And yeah, leaving the management side out of it just as an IC, it's good to know what your colleagues are doing so that you know where you can chip in and give them some help as well. I've worked in much larger teams where you don't know what any of the rest of your team is working on. And that in itself becomes a bit of a blocker.

Eran: Even with work from home and hybrid mode, stuff is really changing even for that because right now, you are not very close to your teammates as was before. And there are a lot of unknowns and people trying to find the best way to communicate because it's a bit more complicated than before COVID started. But again, when I see here the teams with the size of four and five, it seems like a very good fit. More than that, I totally agree; stuff can be split away, like, you will not be on top of everything.

Aaron: Yeah. And also, once you get above that size, then your stand-ups get too long in the morning. I'm one of those people. I'm very strictly a stand-up is 15 minutes and no more. I'm really quite inflexible about that. I'm very rigid about it. One of the things I really like to maintain is keep stand-ups really short. So too many people, and either you will all have to go very quickly, or it's going to start running over the 15 minutes. And that's not something I'm willing to compromise on. [laughs]

Eran: You need to sit down during the stand-up, right?

Aaron: Yeah. [laughs]

Eran: [laughs] Take a break.

Aaron: You mentioned there a little bit about COVID and how it's changing team makeups. But talking about changes, you joined Aqua when there were 20 people, and you left when there were 500-plus. There must have been a lot of changes in that company, just in the culture of the company during that time. What things did you notice?

Eran: Yes. And by the way, I also see it here in Firefly. So I think it's something that is general for any startup that you need to be accepting changes and willing to adjust. And also, this is something that now I'm learning how to communicate. Like, I'm investing in that communication to the employees that changes are always welcome in that kind of atmosphere. And in Aqua, it was like I was replacing four jobs in that period of time. Because it's not just the company grows, you're also changing offices because the office that was built to host 30 employees is not the same office for 100, right?

Aaron: Sure, sure.

Eran: Even more members that are working from other places in the world, like, we started only in Tel Aviv development centers. And early on, we also started an office in Boston and later on in other places in the world. So you have more colleagues that are not sitting next to you. So it was very, I will say, challenging to understand that in each quarter that the business is growing, you are basically changing your workplace, and you need to accept it as something positive and not negative. And it's not always comfortable. It sometimes can be very frightening.

Aaron: Yeah. You got to 500 people at Aqua, and then in 2021, so really recently actually, you decided to found your own company, to found Firefly. Whenever you founded Firefly then, what were the things that you took from Aqua that you wanted to apply in your own company?

Eran: Wow, a lot. To be honest, I don't think I ever thought about doing that drastic move in the career of founding a company without having the specific experience that I had with Aqua. It basically was Aqua for me in that period of time that I established that idea that I can do something crazy [laughs] as creating a startup company.

So I learned a lot from the co-founders in Aqua, and I learned a lot of stuff that I think can be done differently. But eventually, this was a very fulfilling kind of experience for me. And everything that I'm doing here in Firefly, I'm always thinking about how stuff was being done in Aqua, and I'm doing a lot of reflection in that specific matter.

Aaron: So you mentioned there that there are some things you wanted to do differently in your own company. What are some examples of that?

Eran: So one of the examples is being more communicative with the employees that don't know how…like, a lot of employees here this is the first time that they are in a startup company. And it's very different between the usual corporate experience. And we are really putting the time and effort to explain to the guys about the stuff that are coming ahead. And again, think about it, there are tons of unknowns. It's not just specifically in Firefly. It's in every startup.

And by giving them that communication and to explaining them…the employees are more connected to the stuff that is happening and expecting less of surprises about stuff that's related to not their day-to-day but more business kind of related about fundings, and customers, and stuff that are really far from their day-to-day execution.

Aaron: So you also said it's kind of scary doing a startup, and you founded that in 2021. We're just coming out of 2020, which, as everybody listening knows, was a very difficult year for a lot of people around the world. So coming into 2021 and deciding you want to do the scary thing, you want to start your own company. What prompted that decision?

Eran: So in terms of starting a company and getting the initial funding, 2021 was a very good year because of all of the stuff that happened post-COVID with the technology companies and the interest rate and liquidity of cash in the markets. It was a very solid ground for having a very good investment, like seed investments. So, again, it's counterintuitive everything.

You think about COVID put a negative influence on the markets, but it's just the opposite. If you're talking about the technology sector, COVID and all the stuff that's related to the digital transformation was really putting more money and more VCs betting on technology during those years. So it was a very, let's say, relatively easy period of time for getting funded.

Aaron: Well, that's, I guess, one good thing to come out of everything that was going on in 2020. [laughs]

Eran: Yes, at least one.

Aaron: Yeah. Tell us a little bit about Firefly then. What's your elevator pitch for it?

Eran: So Firefly is a cloud asset management tool basically trying to give a better life for DevOps engineers and SRE, which is like site reliability engineers and basically all of those engineers that are handling cloud workloads. And we are giving you better visibility about the status of your cloud and whether you are managing it with Infrastructure as Code or not. And giving you that kind of automation that helps you to be more best in practice. So we took some few of the flows that are taking a lot of time for DevOps to accomplish, and we basically automate it.

Aaron: So it's really looking at your previous experience then from DevOps. And is it kind of like scratching an itch for you? Is it taking some of the pain points you had and creating a solution for them?

Eran: Yes, indeed. A lot of the solutions that we are providing were originating with the challenges that I faced in my previous role. Think about it; the cloud becomes very huge in scales in terms of the assets that you put there. And there are some trends like a multi-cloud and multi-account. Think about it, a few years ago, a company was with one AWS account, and it was sufficient. Right now, companies are running multiple AWS accounts.

And if I even put in Aqua as an example, we were a multi-cloud account. So I was having to deal with managing multiple AWS accounts but also multiple GCP projects and a few Azure subscriptions. And even if you think about the skill set of that specific DevOps engineer, you cannot master everything in alignment. So Firefly is trying to give that alignment of best practice across all of the clouds.

Aaron: Yeah, and it's something that's become more important, I guess. I remember the days of like, okay, you needed to be multi-region. You couldn't just have everything just hosted in one region. And now this idea of multi-cloud is definitely something I'm seeing mentioned a lot more. I remember when I was still at MongoDB, that was a big deal whenever we launched multi-cloud support for Atlas. So we could replicate your MongoDB databases across different client accounts.

And yeah, as much as they all try to say that it's just MongoDB or it's just whatever else, it's a whole different way of administrating some of them, and it's a different skill set. So yeah, expecting a single DevOps person to be an expert in every single cloud out there is just not reasonable. So, Firefly, I believe, is still in kind of a closed beta. Is that right?

Eran: Basically, the good news is that we are announcing GA next week.

Aaron: Oh wow. So for anybody listening to this episode, it's probably already in GA then. So that's great news.

Eran: Yes. So this is very, very exciting for us, and saying GA basically means that everyone that would like to experiment with Firefly will be able to do that with a self-service kind of flow. And we are also providing a free tier for small teams. So even if you have a small team and you don't have the budget to pay, you can enjoy Firefly and the value that we are providing.

Aaron: That's great. So tell me a little about your customer acquisition then for a product like Firefly. So, how did you get your very first customer?

Eran: One of the best advantages that we have here in Israel is that the ecosystem is very good. Like, there are a lot of technology companies that just recently become unicorn-level companies with tons of challenges with managing of cloud. So we started with a few design partners that were able to assist us with installing our software, our premature software on their cloud, and basically helped us to shape that use cases and flow and with a lot of feedback coming in.

We were able to build a GA-level product. And one of the benefits that eventually, if you are doing something very right and you're providing value, those design customers are being converted to paying customers. So I'm proud to say that we already have paying customers even before getting GA. And a few of them are some companies that went with Firefly very early in the game, like in the first months when we had a prototype with, let's say, tons of defects [laughter] and broken UI. But they helped us on that journey. And they have a very good place in our hearts, let's say.

Aaron: And I think that that is kind of it sometimes; it’s those companies that join you very early on that really kind of believe in the product and believe in your vision a little bit as well. I don't know if it's a little bit of Stockholm syndrome, but if you struggle through it together, then they can be very, very loyal and champions of your product, really.

So that's great that you managed to get some of these customers who've really helped you nail down the vision and get the product to GA here and now happily signed up as paying customers. What are your plans next? So you've got your first paying customers. How do you get your next 10,000 customers? Like, what's the plan there?

Eran: So right now, it's like the phase in the startup when we're trying to put more fuel in the marketing machine, let's say it like that. So we are planning to be in KubeCon Europe, which is in Valencia, in two months. And again, we are scaling up the team and also for those non-engineering functions like marketing and in sales, of course, and trying to create a really good business around a solution that we already proved that's giving a lot of value to DevOps engineers.

Aaron: Obviously, developer relations has to be featured in there somewhere as well.

Eran: Yes, of course.

Aaron: [laughs]

Eran: Yeah, it's a very good point. So we're basically outsourcing that at that moment, but this is super important. And being involved with the community and open source is something that is one of our strategic thinking. And we're all in love with open source. I'm saying that as a co-founder of Firefly but also as a DevOps. It's like I built my career around implementing open-source tools. So this is something that we're really aiming to invest a lot in.

Aaron: And you've just recently released your first, or Firefly has released its first open-source tool recently as well.

Eran: Right. So last week, we launched validiac.com, which is a free-to-use SaaS-based solution for getting validation for your Infrastructure as Code manifest. And it's, of course, open-source, and everybody can contribute. And of course, any star will be highly appreciated. But again, if you will browse to validiac.com, you will get a place that you can just copy-paste your Infrastructure as Code and get the output of whether it's valid, whether it's secured, and even a cost projection for the workload.

So it's a very nice tool and something that can be bookmarked in your browser. And it's really saving the effort of using four different tools. We just put in four different tools in one place and providing it as a SaaS service.

Aaron: Yeah, that's great. And that's available at validiac.com. We'll make sure that's linked in the show description as well. And anybody who's looking for the source of it, it's available on GitHub under the gofireflyio organization, so you've got sources up there. Also, the SaaS offering at validiac.com for people who want to just try it out, just give it a go. Does this represent Firefly's general philosophy around open source? Can we expect more of these open-source tools in the future from Firefly?

Eran: Yes, of course. We are already cooking something. And we are hopefully going to release the next open-source tool near the KubeCon timeframe. We are doing a lot of investment with our commercial offering and the Firefly product. And again, I mentioned there is also a three-tier, so you don't need to pay in order to experience with the commercial product. We're also going to have a lot of investment with the community and open-source tooling.

Aaron: That's great to hear. That's such an important thing as well. So I'll look forward to seeing what this new open-source tool you're cooking up. Is that at KubeCon, that would be when you announce it? Unfortunately, we are coming close to time. So I just want to give you just a little moment here, Eran, if there are any other projects or where can people find you online? What's the best way for them to contact you, or if they want to get started with Firefly, any of those kinds of things?

Eran: So our site is gofirefly.io. And from there, you can basically start your own tenant and connect your cloud account and just experiment with Firefly without talking with anybody. But if you would like to get a full demo and talk with me directly, you can just book something in our Calendly. There is a link on our site as well. And again, everybody can reach out on LinkedIn, Twitter. [laughs] Every usual kind of communication will be accepted from my side.

Aaron: [laughs] And you are on LinkedIn as just Eran-Bibi. And on Twitter, what's your Twitter account then, Eran?

Eran: It's @EranCloud.

Aaron: EranCloud. So there you go. Anybody if you're looking to get in contact with Eran, you can either message him on LinkedIn, get in touch via Twitter, or if you go to the Firefly website, that's gofirefly.io. You can also even book in via their Calendly to get a full demo of the system. Or if you're like me and you just like to play around with things, their GA is going to be hopefully launched by the time you're listening to this episode, fully self-service. Go sign up for the free tier and have a play and try it out for yourself.

Well, I think that's all we've got time for in this episode, unfortunately. It's been really enjoyable talking to you. I really enjoyed it. It's always interesting to hear from somebody else who's on that kind of management back to IC route. So that was a highlight of this episode for me was getting to talk about that a little bit. Thank you a lot again for joining us. I hope everybody listening gets a chance to check out Firefly, and we will see you all next time.

The Pull Request Paradox with Yishai Beeri

Mandy Moore — Wed, 23 Mar 2022 20:53:03 +0000

Yishai Beeri is the CTO of Software Delivery Intelligence startup, LinearB. Yishai likes to solve problems, and that's why he is so fascinated with programming when he first encountered Logo back in the 80s, where the possibilities seemed endless.

He made it a focus of his career to solve complex programming problems, both as a consultant and entrepreneur. In 2014, he joined the CTO office of a fast-moving cloud security startup, which was later acquired by a networking giant. At this startup, he also met Ori and Dan, now co-founders of LinearB. He joined them shortly after the company was established, in order to get back to what he loves most about engineering: solving exciting challenges.

In this episode, Yishai talks with host Ben Greenberg about the paradox of pull requests.

Links:

LinearB (Twitter | LinkedIn)
Yishai Beeri: Twitter | LinkedIn
The Pull Request Paradox: Merge Faster By Promoting Your PR

Give us a follow: @PolyglotShow

The Pull Request Paradox with Yishai Beeri

Polyglot

Your browser does not support the audio element.

1x initializing... ×

Transcript:

Ben Greenberg: Hello. Welcome to another episode of Polyglot. I am Ben Greenberg, Lead Developer Relations Engineer at New Relic. And today, I am joined by Yishai Beeri, CTO of Software Delivery Intelligence startup, LinearB. Welcome, Yishai, to Polyglot.

Yishai Beeri: Thank you. Pleasure to be here.

Ben: So let's start off by telling our listeners a little bit about who you are. Who are you, Yishai?

Yishai: So I'm a software developer at heart. I've spent most of my career writing code and then managing projects of writing code starting in the military days back in the '90s. And then spent most of my career as one of the owners of a small consulting shop like a boutique software for hire shop, which has worked with startups and larger companies here in Israel for about 18 years. Then my last contracting gig was for a cloud security startup called Cloudlock. And after about a year there, I was lured to join Cloudlock as a full-time employee for the first time in my life.

Ben: They made you an offer you could not refuse.

Yishai: It was the right time for me. And so I joined Cloudlock, worked for the co-founder and CTO there; after a couple of years, we got acquired by Cisco. I spent another three and a half years in Cisco, led the Tel Aviv site for Cisco. And then, almost two years ago, I left and joined LinearB, which is, as you said, a Software Delivery Intelligence startup. And here I'm, the CTO, and we focus on helping engineers and development teams improve and work better.

Ben: So you have been all over the gamut around the software industry, from startups to major corporations and back again, and now you're back at a startup. And from a software developer yourself to being CTO now, you have seen really the whole spectrum of conversation around software development, I imagine.

Yishai: Yeah, a lot of similarities across all that gamut but also a lot of differences. I don't think it's all attributable to size or stage. I've seen larger companies that are more agile than smaller companies and vice versa. But yes, very wide range of behaviors, technologies, ways to manage the coding process. I'm old enough to remember days way before Git and before Subversion.

Ben: There were things before Subversion, Yishai. [laughs]

Yishai: Yeah, like CVS and stuff like that.

Ben: Yeah, true, true.

Yishai: Or just plain old code with the whole versioning.

Ben: [laughs]

Yishai: That used to be a norm.

Ben: That used to be the norm. That is true. So you've seen so many different ways of managing software teams and building and coding together. And this is a big subject; how do we successfully get past the friction or help alleviate the friction in software teams that are building code and trying to push out changes in a reasonable timeframe?

I've read some interesting things you recommended to me from LinearB. And one of them that I would love to talk about a bit with you is what was termed in an article, and we'll share that article in the show notes for listeners, what was termed in the article The Pull Request Paradox, the paradox of pull requests. And I would love it if you shared with us a bit of what that means. What is the paradox of pull requests? And what did your research in that help discover?

Yishai: Pull requests have become the de facto standard for evolving a team or a company's codebase over time to add value, to fix bugs, to improve the product. Pull requests have evolved from mainly an open-source project artifact where very distributed teams on very lax timeframes and timelines with mostly people working on their spare time, volunteers that needed a way to coordinate how they are adding and changing code to a common codebase.

It slowly became how most companies do changes to the master codebase. It's not the only way. And there are various movements for trunk-based development and PR layers or various flavors. We can touch on those a bit later. But it's the de-facto standard. And it lets the organization or the team make sure that it's very clear how changes are getting added to the codebase, and it at least allows some form of code review or peer review process to those changes.

When you look at the different people involved or the typical cycle, is me as a developer, I'm writing a cool feature or fixing a horrible bug. My goal is to get this working and pushed to the main branch, merged back to the codebase, and eventually deployed as quickly as I can. I've already done the work. Part of my definition of done is to actually get it reviewed, merged, and eventually deployed. So my motivation is there. But I need to get help and collaboration from people who are working on their own items. And I need them to review my code just like I would review theirs.

It's a peer-based process or sometimes an expert-based process. I need someone else. And my priorities are different from their priorities. So I need to think about how do I get them to help me sooner while things are still fresh in my mind? How do we as a team reduce context switches and so on?

Ben: Well, your priority is getting your work done, and their priority is getting their work done.

Yishai: Yes. And so, by definition, we're at some clash. There is a, you know, some people like to call it a buyer-seller. I need to sell my PR. Their top priority is probably not my PR. They have their work. And also, once I have given away my PR for review, I'm typically starting a new thing. It's now my key priority.

And this older PR which is waiting for someone else, maybe they'll get back to me in a couple of hours or a couple of days, now is conflicting with my new toy or my new PR. So I have this internal conflict as well. It's very tempting to start new things, but I want to get my work finished. Or the team wants this existing work or work that is advanced and is almost done to get finished.

Ben: And the longer the review process takes on that pull request, the more diminished its importance is in your head as you moved on to something new and are building on your new pull request. So if it takes two, three, four, or five days to receive a review, those are two, three, four, five days that you have now started progressing forward on some new area of work. And this thing feels older and older and less relevant for you with each day and maybe even each hour that passes.

Yishai: Right. So it's both...like, there's a tax, a mental tax, a cognitive tax in reloading that context. Oh, I need to get back to this. What was I thinking? What was I doing? So that I can really read those review comments and react in the right way. And there's also the priority shift where my mind and my heart is now in this new thing. And I need to get back to that old thing and finish it. And people don't like to finish things as much as they'd like to start or do the fun, creative part of working on something new or a new piece; at least most people like that better.

So there are multiple conflicts of priorities and multiple people needing to get into the context of something and then drop it to work on something else and then go back. Understanding those dynamics is what we headed out in our research to understand better what's actually happening in actual teams, focusing on dev teams and companies that are building software for profit, not open source or loosely coupled teams.

We want to understand what's typically happening? When are people working or not working on PRs? How is that dynamic actually happening so that we can analyze those patterns and see okay, are there opportunities for improvement? What can we learn from that behavior? So studying close to a million PRs across our very varied customer base, we began to look at what can we say about the time when developers and reviewers are interacting or working on a specific PR, on a specific code change versus the time that it actually lies idle? No one is looking at it. No one is actually thinking about it.

And we discovered that a lot of the time is idle. More than half of the PRs are idle for half of the time; that's even when you discount the nights or the weekends. You just look at work hours. Most of the time, this PR is just waiting there, and no one is even looking at it, thinking about it. It's not fresh in anyone's mind. And for PRs that take a bit longer to review, the ones that are not happening within a single day, the idle time is even higher, up to 80% and sometimes more.

So if you think about it, all that time spent idle means two things: first, things that could progress and could move into done and actually bring value that doesn't happen, and it languishes. And then the longer things wait in idle, the more expensive the cognitive tax is going to be about reloading or getting back to this whenever someone does get back to it.

Ben: Right. And there are probably other roll-on effects as well. Like, the longer something is staying idle, perhaps the more work you need to bring it up to the main branch because other changes might have been merged into the main branch since that are raising conflicts in your existing work. And the longer it sits there, perhaps the more conflicts you're going to have, which is more cognitive tax on the developer. It just keeps on compounding the problems.

Yishai: Yes. So you have a higher width because you have items that are not done, and you still own them. And the team has a higher width. Like you said, the merge risk is higher. You are not learning anything as a team from this new code. No one is actually using it. So the customer or the world is typically a moving target. If you're not deploying something and letting the customers use this, you're getting further and further away from actually hitting something that someone cares about.

Ben: That's such an articulate formulation of it as well. The longer it's staying out of the production codebase, the more time before a user, your actual most important end result, is actually going to experience the code that you wrote. And it's just sitting there dormant, actually not being put to use at all.

Yishai: Right, so no value but also no learning. Typically in agile teams, you want to learn from the...you typically have...you're deploying an initial part of something. You're never deploying a whole product in one go. And you want to learn from how it's going to use or not use. Your learning cycle is longer. Does it actually work in production, or does it explode? That's also a learning curve. If it takes me two more weeks to learn it, that's much, much longer for me to fix it and get it right.

All of these things compound when your PRs are languishing and basically idle. No one is working on them. So everyone is busy. Everyone is working on something; not saying the team is idle, but the PR is idle.

Ben: So how do you address those things, Yishai? How do you come to find a solution that resolves all these issues given the constraints of a system, a methodology of operating within the context of pull requests?

Yishai: So I think the first step is realizing, first of all, having the data and understanding both from a broad perspective what we provide as research but also specific to my team. My team's PR is what is actually happening? What are the patterns? Are we waiting for people to pick up their PR to begin reviewing it? Are we waiting for reviews that have begun but are not closing fast enough and maybe spiraling out of control or just lying in some gutter waiting to be picked up? So having the data and the visibility is the first step, understanding what is actually happening in my team or in my org.

Second thing is also to understand the reasons why the PR cycle and the cycle time for code work is important, why that is a key metric, why that is something that is worth measuring, tracking, and setting goals against. Why this is a good way to measure the effectiveness of a dev team compared to lines of code or numbers of PRs and other metrics that are probably not the right things you want to measure. Those are the beginnings. You want to understand the motivations, how it hurts me when PRs get longer, and be able to measure it.

Then when you're drilling down and looking at the reasons, like, why is a PR waiting so long? When we look at that or when we analyze the idle time for PRs, we typically see two types. There is time when the PR is handed over from someone to someone else. I created a PR. This is basically handed over to a reviewer or a set of people that may review it.

When they have finished the review, it is getting handed over back to me. So this is what you call this transition idle time. And this is very much reliant on the way we communicate. Does the next person in the chain know that this is now waiting for them? So communication, awareness that there's some work that I can do here that someone is waiting on me for help. Sometimes there is congestion.

Ben: Do you find that automation helps with some of that, letting the reviewer know that they've been asked to review something? There are many ways to automate that.

Yishai: So on the communication side, looking back three years ago, we used to swivel in our chair and holler to someone, "Hey, I have a PR for you," because they were in the same room. Then came COVID, and also the world is changing, and we have much more remote and distributed work. So the chair has become Slack. We Slack each other, or we text each other. "Hey, here's a PR. Can you look at it for me?" "What's up with my PR?" "Oh, actually, I reviewed it yesterday. Didn't you see?"

So we have manual communication in various channels, back channels that try to make up for that communication or communication gap. And automation means there's going to be reliable communication that's going to reach the right person at the right time where they typically are, which is, newsflash, not email. It's probably Slack or Teams. Shocking news, it's not email.

Ben: [laughs]

Yishai: So having reliable communication channels with built-in capabilities for snoozing, for letting the person make this something that they can be reminded about. It's another incoming task for me now, or something is waiting on me. I need to be aware of it, and I need some management tools or capabilities so that I can manage this. It's typically not just one thing, so I have multiple things coming in. Plus, I'm actually working on something, my main priority, so even elementary tools to manage those.

And what we also found is in addition to the basic communication, if you can give me more context. If in the communication you're not just giving me a link to a PR, but you're telling me more about it, I can make better decisions. And this goes back to the other type of idle time, what we called intrusion idle time, which is where I start to work on something, a PR, and then I get drawn away to I have a meeting or something else of priority has interrupted me, and then I get back to this PR later. It's still in my hands. I'm not transitioning it to someone else. But there was some intervention, and I needed to start and then drop it and then go back.

And we've looked at both types of idle time. So how can we reduce that? How can we make sure that if I'm already working on something, I can finish that part hopefully in one sitting or minimize those jumps between tasks? So context is very helpful here, if you will give me more context about this PR.

Or looking at a PR review if I'm being asked to review a PR and I get context about what's in it? What's coming up? How many files are there in the PR? How large is it? How much time am I expected to spend reviewing this? Is this a two-minute thing or an hour that needs to be spent here? That will help me make the right decision. And maybe I won't start it now if I only have 10 minutes until my next meeting.

Ben: Within the context, including perhaps estimated amount of time this will take to review the pull request, giving an actual estimate of work time is essential as well, you're saying.

Yishai: Right. And we've seen estimated reading time is a very common add-on for many blogs and articles where you tell the person here's a nice thing for you. It's interesting. It's going to take you 10 minutes to read. And it's different the way people react to that. It's different from something that's going to take you 3 minutes or 30 minutes. So we've done the same for PRs. And we are also studying the response of this queue for how people react to those messages. Like, you have a review, and it's going to take you 2 minutes versus it's going to take you 15, or 30, or 60. And we see that, yeah, this actually shapes behavior.

When PRs are expected to take longer for the review, people time it differently, and people will do them when they have time rather than jumping right now to maybe remove something small out of the way. All of these things help to optimize the types of idle time, reduce them. They're not going to go away completely. And you also do not want people to jump around just because something came in or there's a task. Context switch should be deliberate rather than by interrupt.

But adding context helps make that decision. Choosing when to notify helps make that decision. So these are all ways where automation helps to reduce the idle time and helps eventually the team focus on finishing things sooner and giving that priority over starting new things, which is a good thing, less width, all the costs we have described before, and all the benefits of shorter PRs in a shorter timeframe.

Ben: So, based on your research, let me ask you the following theoretical question and probably a very common scenario. Let's say I've been assigned to work on a new feature. And I've built the feature, and I have my unit tests, my integration tests. I've done everything I need to do. When I'm submitting a pull request to somebody to review it, and it's a complete feature, and I'm going to provide estimated time to review of, let's say, an hour, an hour, and a half. It's a big feature.

Would you recommend, based on your research, that I take that feature and break it up into smaller component parts and have multiple pull requests that all are part of the larger picture? Or is it better to have a fully comprehensive one pull request, one feature but a larger chunk of work for the reviewer? Which one tends to reduce that cognitive load, that time between that we're talking about?

Yishai: So I'll start with a simpler version of that, which is easier to answer, and then I'll go to the harder version. So the easier question is, I have a feature, but I also found a bug somewhere, and I have this nice refactor. And I've bundled them all into this one big PR complete with all unit tests and whatnot. And I want you to review it. So here, the answer is simple. Yes, break it down. Don't do things that are not necessarily related in the same PR just because you happen to be touching that area of the code, or you saw an opportunity.

Larger PRs are harder to review and harder to merge. People will shy away from reviewing them because you're going to GitHub, and you see this wall of red and green. You're scared away. I don't have time for this. I don't have the mental capacity right now. So, by all means, smaller PRs that focus on just one thing are easier to grok, easier to review, less risks to merge. They will lead to shorter cycle time and much quicker review just by being smaller in addition to all of those automations and communication helpers I just discussed.

In some cases, it doesn't make sense, or you need to be thinking about how to split this, and hopefully, you've done this. You're not splitting an existing PR, but you're starting out by doing smaller slices. Just doing smaller slices that have no context or can only be understood with other sibling PRs that may be too complex. But if it's a well-defined piece of change to the codebase that can be justified on its own and hopefully deployed on its own, definitely chunk it down.

Ben: That will help reduce the barrier to entry for reviewers. They'll look at the pull requests and maybe only see a few lines of code to change, a few lines to review as opposed to an endless sea of changes that they need to --

Yishai: Right. And the complexity of understanding a large PR, the complexity is not linear. There are multiple files that you need to follow, multiple trains of thought as you try to decompose what's happening here. We all know, we all have experience with those huge PRs that are intractable. In extreme cases, we ask people, "Hey, break this down and give it to me in separate PRs." But ideally, this happens from the onset.

You begin by slicing your work in a way that can be reviewed, merged, deployed, and not just a technical big breakdown of the PR but also slicing the value. We're all in the business of building value through a series of code changes to our codebase. Having good atomic-sized changes that can be reviewed reasonably is key here.

And what tends to happen with huge PRs is they get delayed. People don't start reviewing them. And then when they start reviewing the actual review, quality is going to be very low. Because they say, "Okay, it's intractable. I'm just going to skim it," and say, "Okay, it looks good." It's very hard to get good feedback on a huge PR. So quality will go down as well.

Ben: Yeah, that makes a lot of sense. So, where do you think that culture comes from? Where does it start from? Is it something that's part of the onboarding for new engineers into a software team, how we do PRs? Is that something that should be not implicit but made explicit? And if so, how do you do that? How do you onboard people to that culture of more sustainable, I would say, more sustainable PR?

Yishai: Like most things, it's done to people at the beginning. Culture is about people and about agreements on how to work as a team. In some cases, these are soft things that you learn as you onboard or learn through seeing others do in the team. In some other cases, you could think of these as either written or unwritten tenets of the development process, like this is how we do things. We run these kinds of tests before we merge the PR, and we do QA here.

And for some of these behaviors, you can get help, or the team can get help, again, by using tools and automations to help anything between force or shape behavior. For example, if you want your PRs to be small, why not use a tool that will let you first of all track the size of your PRs? Take goals against that size if you want to make sure that it's small or reducing. You want to change existing behavior. Let developers know when their PRs are starting to be too large when they still have a chance to change it or to break it down.

So visibility into what's going on, making sure that it's part of what we describe as a team this is how we want to behave. This is how we should be doing things, measuring ourselves against that, using goals, KPIs, or whatever means. This is a retrospect kind of motion. What has happened? Do we like it? Do we want to change it? Here's our new goal or experiment or suggested way of changing behavior. And also, because this is all in code, this is all through tools. This is a very measurable and automatable process. Maybe get some alerts and heads up on specific PRs that are beginning to look different or behaviors on PRs that are different from what we want.

If we want people to begin reviewing a PR within a day, wait no longer than one day from issuing the PR until someone starts to review it. If that is a behavior we want to encourage, let's make sure we get a reminder when PRs are getting near that threshold. These are things that are very readily automated. There are tools to do that. And you integrate that in your work. And now your dev process and preferences become codified in how you measure things, in how you take goals, in how you automate alerts, communications, automations, workflow automations, all of that.

Ben: I think that makes a lot of sense. If what we're talking about is around quantifiable metrics, then quantify it, and let's measure it. And let's set ourselves goals and benchmarks and evaluate our progress towards them. I think that makes a ton of sense to me, and it's a really good way to actually start progressing and moving forward from where we are to where we want to be.

In the time we have left, I want to go into a subject which is a hot subject in our last few minutes, which is tell me about a world where there are no pull requests. Tell me about a developer environment software shop that is just merging right to main. Is that a doable thing? Is that recommended, and if so, when, and where, and how? And if it's not, should we put up a big, flashing warning sign, don't enter this space, never do this?

Yishai: [laughs]

Ben: Yishai, help us navigate these terrains.

Yishai: Yeah, so great question. And I think we are seeing a burgeoning desire to change something with the PR process. Like I said, it has evolved from the open-source world into much more tightly coupled teams. And it has drawbacks. It is slower than just putting code directly to main or not doing code reviews. So it has a lot of benefits. It also has some drawbacks.

It's definitely possible to drop PRs completely. Some teams are doing that, typically small teams, very high skilled developers. So it's a bit easier when everyone is very skilled, complete ownership of entire areas of the codebase, and ability to maintain high quality through that. So it's doable; it's hard. And it's probably not a great fit for most companies, most teams, which have diverse levels of skills and experience with the codebase, larger teams or larger organizations which have more moving parts, and so on.

What perhaps is more viable than dropping PRs completely are two things. First of all, code review process does not have to be async. PRs today are mostly async. I put the PR up, someone else picks it up, takes a review, writes comments, I read them later, and so on. So the ability to think about should we move this to a sync review? And making smart decisions about when to let's huddle together and spend some synchronous time together on the PR. Some teams do pair coding and other methods to even preempt that.

But some PRs are better reviewed in async mode rather than asynchronous. So identifying that, knowing when is a good time to do this, finding the communication methods to actually make that happen. That is one win and one change in the PR process that applies to some PRs in some teams some of the time.

Another thing which can help to get most of the value you get from PRs like better quality, a lot of bugs get caught in the PR's phase, better design, and so on but not pay all of the taxes, all of the cost of PRs, is by saying not all code changes require a PR. You can, as a team, decide on...there are models like Ship / Show / Ask, which some changes are small enough and gentle enough that the developer is given full autonomy to just push them. He owns it completely. No need to do anything. I'm just shipping code.

Other changes require that I can ship the code, but I need to also make people aware of it. That is the show option. And then ask is for larger changes, more complex ones, and more risky ones. Let's do a PR process for those changes. So now it becomes an art. How do I choose? Who gets to choose? Again, looking at our data, 90% of the PRs are very small and very simple. The PRs are not all...their distribution is far from normal. Most of the PRs are tiny. In many cases, the review process for those PRs is an overkill.

So finding the right methods and, again, tooling and automation can help a lot here. So maybe let's decide which PRs can skip that process and do not really need a review. And we can streamline those and focus our review efforts and all those cycles in the PRs that really matter and that really need them. So I think looking forward, we'll probably find ourselves with much more teams or organizations that use a combination approach and run a full review process for some of the code changes and a much easier or smaller or no process for a lot of the small changes, tiny PRs that do not really need a peer review and all that process.

Ben: It's a very happy medium I think negotiating between the two extremes and finding that right balance so when you need the pull requests and when you don't need the pull requests and determining and figuring out for your organizational complexity, and dynamics, and your team's strengths where to put it and where to not put it. I think that is a really, really good approach.

Yishai, thank you for joining us on this episode of Polyglot. Thank you to our listeners for joining us. It has been such a pleasure. You can find us wherever you find your podcasts. And again, you can find links to all the articles we mentioned in the show notes. Yishai, thank you so much for joining us.

Yishai: Thank you. It was a pleasure.

Ben: Have a great day, everyone.

Inside Scoop – What Companies Are Doing to Make The Interviewing Process Better with Spence Taylor

Mandy Moore — Thu, 17 Mar 2022 19:00:30 +0000

Spence Taylor is an Engineering Manager at New Relic who runs the Central Hiring Program.

Born in Compton, California, he had a very unorthodox journey to tech. Trying to find the right fit for his career, Spence has worked in the military, event management, hospitality, and finally found his place in tech. Working as an engineer, he experienced many issues with current hiring practices and has always been passionate about improving the hiring process.

Now with the Central Hiring Program at New Relic, he hopes to find ways to improve the hiring process for both interviewers and interviewees and implement effective diverse hiring practices.

This season, we’re helping you level up your interviewing skills! Each week Lauren Lee, Danny Ramos, and industry experts will offer advice on navigating career progression within tech.

👉 Give us a follow: @LaunchiesShow https://twitter.com/launchiesshow

Inside Scoop – What Companies Are Doing to Make The Interviewing Process Better with Spence Taylor

Launchies

Your browser does not support the audio element.

1x initializing... ×

Topics Covered On This Episode:

Common Hiring Practices and Interview Pipelines
Interviewing The Interviewer
Overcoming Unconcious Bias
Technical Take-Home Challenges
Asking For Interview Feedback
Cultivating Good Interviewing Skills
Combatting Interviewee Anxiety
Best Networking Practices

Links:

CTA (Call To Action): Join the New Relic Community Slack and…

In whatever language you prefer, write a function/method that accepts an object. The function should return a new object with the same data but with the keys and values swapped. Since the returned object might have multiple values for the same key, it should put the values in an array.

👉 Follow Launchies, Lauren, and Danny on Twitter!

🚨 FutureStack 2022 call for papers is now open! 🚨

Sign up to share your successes and learnings in a hands-on lab, workshop, or deep-dive session to help your peers advance their observability game.

Transcript:

Danny Ramos: What's up, everybody? Welcome to another episode of Launchies. At this point, you know you're...what are we? Four episodes in, my God, and you're still here. You're sticking around. We love you. We appreciate you.

Lauren Lee: We do. Hi. Hi, everyone. [laughs]

Danny: Oh yeah. Lauren is here too. [laughter]

Lauren: It's like, he is just going. He's driving right in. Why chit-chat when we can interview with an industry mentor and understand what companies are doing to make the space better? I get it.

Danny: Exactly, exactly. There's no time for chit-chat here.

Lauren: I would like a little bit of chit-chat in that I haven't seen you in a really long time. [laughter] Hi, how are you?

Danny: Yeah, we could chit-chat. [laughter] It's just like, these people want jobs. They're trying to learn.

Lauren: I know. We got to prioritize that.

Danny: I did just get back from Mexico, so we can talk about that. [laughs]

Lauren: Your trip looked great. We missed you. I hope you feel rested. [laughs]

Danny: No, and that's the problem. You know when you go on vacation, and you come back, and you're like I --

Lauren: Don't say it. You need a vacay from your vacay. [laughter]

Danny: Yes, people say that, and I always thought it was dumb. But now I'm that guy.

Lauren: Wow. Well, that's fun, ever-evolving.

Danny: I'm just loving my picture this. [laughs]

Lauren: Okay, sure. Take us there.

Danny: Listener, I am Mexican. I'm inside most of the day. But in Mexico, I got so tan that I walked into the coffee shop yesterday and the girl that I see every morning was like, "Oh my God, Danny, you are brown." And I was like...and I just did a little twirl. I was like, "Yes."

Lauren: Oh, you did?

Danny: [laughs] Yeah. I was like, well, I just was in Mexico. And she was like, "Is Danny short for Daniel?" And I was like, "Yeah, but I only hear Daniel when my mom's mad at me." And she's like, "Oh, haha." She was like, "I thought you were Mexican, but now I definitely can see you're Mexican." I was like, "I don't know what that means, but I'll take an iced coffee to go." [laughter]

Lauren: That coffee shop you have such...wow. Okay. I have nothing to say to that. I really missed you. [laughter] I, too, commented on your level of tanness, actually. When we were midway through our call, I think I looked over in the Zoom boxes, and I was like, "Whoa. Hey. Look at you, sunkissed."

Danny: Weren't you...you were somewhere.

Lauren: I live in South Florida. So I went on a babymoon, which is like a millennial's invention of a vacation holiday away.

Danny: Oh, babymoon. I was like, what the --

Lauren: [laughs] Yeah, it's a time before the baby comes. But we just went to the beach and stayed in a hotel.

Danny: Aww, that's cute.

Lauren: I live about a mile away from the beach. But it was nice to be away from responsibilities and have some time off from work and those sorts of things. So yeah, kind of just like time to be present in my relationship knowing that it's about to change a lot, I guess was the concept.

Danny: Oh wow. Actually, that's good that you did that. That's really good.

Lauren: Right?

Danny: Yeah.

Lauren: It was, dare I say, feel ready for what's coming? But I'm sure I will laugh at myself later on when like a baby [inaudible 3:52] lives in my house, and I am responsible for it. [laughs]

Danny: What have I done?

Lauren: Yes, exactly. But yeah, so we were both away. So we thank you, listeners, for allowing us to do a brief check-in with one another because, yeah, we haven't seen each other's faces for a while. But we did record this conversation a while ago, and we're really excited for you all to hear it. It's a really cool conversation with Spence, who is a colleague at New Relic. And I feel like I'm so proud about the conversation because what he talks about our company doing changing wise for the industry is really incredible.

Danny: Yeah, yeah, absolutely. I was really surprised because I was just talking to him because we're both in Relics of Color. And we were just chatting, and he's like, "Oh yeah, I'm like a boomerang employee," which I'd never heard the term because he was here then left and then came back. I was like, "Oh, did you get the same role?" And he's like, "Oh no, I'm doing this, this, and this helping with the interview process." And I was like, [laughs] oh, do I have a podcast for you. [laughter]

Lauren: Oh my gosh, I find myself if anyone brings up that they're interviewing or that they're searching for a job, I am just like shameless plugging left and right. "Sounds like you'd be a great guest." [laughter]

Danny: But you have to listen and download and subscribe to all the episodes first, and then we'll consider you. [laughter]

Lauren: Oh my gosh. Okay, well, I suppose shall we just dive right in and get to our conversation with Spence?

Danny: Let's go.

Lauren: Okay, cool.

Spence is an Engineering Manager at New Relic who runs the Central Hiring Program. Born in Compton, California, he had a very unorthodox journey to tech. Trying to find the right fit for his career, Spence has worked in the military, event management, hospitality, and finally found his place in tech. Working as an engineer, he experienced many issues with current hiring practices and has always been passionate about improving the hiring process. Now with the Central Hiring Program at New Relic, he hopes to find ways to improve the hiring process for both interviewers and interviewees and implement effective diverse hiring practices. Everyone, please welcome Spence Taylor to Launchies.

Danny: Yeah!

Spence Taylor: So happy to be here with you both.

Lauren: [laughs] We're so happy to be chatting with you. This is right up our alley. You're hitting all the buzzwords we're excited about. [laughter]

Spence: Yeah, once Danny told me about what you guys were doing this season on Launchies, I was like, that sounds amazing. I'd love to be on the show.

Lauren: It's so cool that your job is thinking about these things all day, every day. [laughs] I'm obsessed.

Spence: It's weird because my job title is engineering manager, but I don't have a set team. I literally just focus on discovering and hiring talent and then sending them off to go find their perfect fit within the company.

Lauren: That's so cool. Yeah, that's so interesting. I have so many questions. How do you even find yourself in this space? But I won't jump ahead. [laughter]

Danny: We'll get there. There's a story arc to this all.

Lauren: Okay. I understand. I see you cringing when I'm like, give me it. [laughter]

Spence: She's like, I want it, and I want it now. [laughter]

Lauren: My bad.

Danny: So anyway, Spence, can you give us a little bit more about your background? What even got you interested in software development in the first place? How did you even get to know the interview process as just a young, new person?

Spence: Like I said in the bio, my route to tech was very unorthodox. When I got out of high school, I didn't have any plans whatsoever. And it was a spur-of-the-moment decision to join the Navy. So I did that for...it was literally like me and my best friend were going to a party, and he was like, "Hey, I'm joining the Navy." And I was like, "Well, I'm not staying here, so I'm going too."

Lauren: "I guess I am also." Oh my God. [laughter]

Danny: I was expecting that you walk into the party, and the Navy is just there and like, okay, cool. [laughter]

Spence: But that's what's really funny is like, after that weekend, I'm walking to school on Monday, and this Navy recruiter just stops me. He's like, "Hey, you want to join the Navy?" And I was like, "Oh, okay. I guess this is the spot."

Lauren: Perfect timing. [laughter]

Danny: Oh my God.

Lauren: Oh my gosh.

Spence: Yeah, it was wild. So I did that for four years. And when I was in the Navy, I was what's called a cryptologic technician. And it's just a really fancy way to say that I listened to signals on the UHF VHF band for hours on end with headphones on.

Lauren: Wow.

Spence: But our system was in Unix, and we had to write these reports. So I basically wrote like a script in Bash in order to write my reports out.

Danny: Oh, what?

Spence: Yeah, so I did a little bit of programming, just a little tiny bit to make my job easier. So throughout my life, tech has always been a part of me at every step. But when I got out, I decided that I wanted to be a chef, so I did that for six years. I really loved that life. It's chaotic, and I thrive in chaos. I like when there are new challenges every day. So that really informs the type of jobs that I get excited about.

The only issue with working in the kitchen is there is a terrible work-life balance, and you don't get paid a lot. So like I told Danny before, most cooks or not most because I won't speak for everybody but at least me, I would go home and there'd be no food in my fridge. Because after paying all my bills, I really couldn't afford to have a bunch of stuff.

Lauren: Oh, the irony of being in a kitchen also, too.

Danny: That's exactly what I was going to say. [laughs]

Spence: Yeah, so you eat a lot at work, but honestly, at home, there's barely anything, so you try to make ends meet. And I lived in Los Angeles, which is like one of the most expensive cities in the U.S. I mean, it's no San Francisco, but it's pretty close. I was looking for work-life balance, and my roommate at the time was a game developer. He was like, "You should try writing code." He's like, "You're pretty smart. You can do it."

So I started taking online courses, and I was really interested. I was having the time of my life. But I just realized there was so much that I didn't really know what I should be studying in order to get a job.

Lauren: For sure. It's such a big...the advice of like, you should learn to code. And just where do you even get started with that? is a whole other conversation, right?

Spence: Right. You spend four or five hours like, which language should I start with?

Lauren: Literally. Yeah, exactly. And everyone has a different opinion. That's a nightmare.

Spence: So I decided I needed direction. So I found a bootcamp in San Francisco.

Lauren: Nice.

Spence: I moved there, did my program, and landed my first job seven months after starting.

Lauren: Wow.

Danny: Keep in mind that during his program, he was living in a hostel in the Mission; shared one room with three other people.

Spence: Yeah. It was at Tenderloin. And I shared a hotel room-sized room and not a normal hotel room, like, a San Francisco size hotel room with two other people.

Lauren: Noo. Oh my gosh.

Spence: So like three twin beds, and a tiny refrigerator, and a closet, and a bathroom, and that's it for nine months

Lauren: The dedication to code. [laughter] Wow, good for you. So landing that first gig must have felt like, yep, this is pivotal.

Spence: Yeah, it was awesome. It was really awesome. I felt like I made it. My life has been a lot different. I did that startup for six months, and then it wasn't really working out. But I got a recommendation to come join New Relic, and it's been amazing. I love New Relic. It changed my outlook on my tech career because I didn't really have the best working environment in my first job.

And I wasn't looking forward to interviewing again because my interviewing experiences were always terrible. It was like, oh, do these algorithms. But those algorithms that they would have me do weren't something that I was going to be doing for my job. So I was always like, is this the work that I'm expected to do, balancing this red-black tree? And if I never have to go back and read Cracking the Coding Interview again...anyone who has to read that book, it's torturous. There's nothing enjoyable about it.
Lauren: I use it as a doorstop in my house [laughter] because it's like, you are toxic. I do not need you in my life other than as a piece of furniture.

Danny: Why I mentioned Spence living in that room or working within that room and living in that space every single day and knowing that you're like, I just want a job. I just want to get this tech job and be able to change my life. And at that point, you probably didn't even care about any part of the interview process. You were like, I just want to get through it. I just want to get through it. So, was there a certain point where you were just like, wait a minute, other people experience different things, or you were like, this is not the same everywhere?

Spence: Actually, when I was in bootcamp, me and the group of people that I worked with every day the school wanted us to wait until the program was over before we started interviewing. San Francisco is a very expensive city, and we're not working. And this is a longer program than most. So me and my friends were like, "No, we're interviewing now. After three months, after we do the first portion, we need to figure out how to interview now."

Because everyone was telling us like, "Interviewing is a skill. It's very different from the work that you do," which is a weird thing to tell someone who's spending all this time and money trying to train to become an engineer. I'm learning these skills, and I can't even use them on the interview? Like, that's crazy.

Danny: [laughs]

Lauren: It's so backward.

Spence: But once I started interviewing, I realized they were right. It's different. I remember my first phone interview. I had to do a LeetCode exercise over the phone, and I'm sweating. The guy cannot even see me, but I'm super anxious and nervous because it's my first interview. And I just wasn't used to the format or what I was supposed to do. I would get flustered because I knew what to do just in the heat of the moment; it's like a shotgun interview. I get 15 minutes to do this exercise, and that’s really stressful. So yeah, this was the beginning of me realizing interviewing sucks. It really sucks.

Lauren: So that brings us to then what you're doing today at New Relic. What are the things that are really practices that we're trying to change? And what are the ones that you're hoping to take to the wayside? Or is that the analogy? I can't think of the phrase I'm trying to say here.

Danny: I think you're doing that thing where you're trying to think of another word.

Lauren: Move to the wayside?

Danny: Move to the wayside? I think lift up and put over -- [laughter]

Lauren: Like, get rid of, take to the trash.

Spence: To the left to the left. [laughter]

Lauren: Thank you. Thank you. That's it. That's exactly it. [laughs]

Spence: One, some interview processes are very long. I saw a tweet the other day this woman was applying at a FAANG company. And she went through 15 rounds of interviews only to be told that both of the teams that she was interviewing for went with someone else. So the first thing is being respectful of people's time.

Yeah, you're a company, and you're about to pay this person a lot of money, but that doesn't mean you get to waste people's time. So I think having a more, I don't want to call it short, but just a better content pace interviewing pipeline where you can easily discover if this person has the skills that you're looking for instead of making them jump through all these hoops.

So, for instance, in Central Hiring, our process is the recruiter screen, the hiring manager screen where I, as the hiring manager, interview you about your resume and then go through a small conversational exercise to get a feel for where your skill level is. So right now, I'm hiring a senior engineer, so I need to know if they can architect the system. So we do a small system design exercise for 30 minutes. And it's purely conversational, just like at a high level to see if you understand what you need to build a system. So it's just like a quick screen.

And then, after that, we do a take-home challenge. And that should take about two hours, again, being really respectful of time. We don't want you to be working on something for five to six hours. It should only take you about two hours. You send that back; I evaluate it. If that's done well, then I invite you in for your final interview, which is the panel and our panel interview for our process is three hours.

Lauren: And you're not spreading it out over many weeks of time either, hopefully.

Spence: So usually, a candidate, on average, is going through my pipeline in two to three weeks.

Lauren: Oh, wow.

Spence: And that depends on scheduling, so just making sure you can put that time aside. And being respectful that you have a job that you're currently working at, and I can't just tell you that you need to be here today.

Lauren: Right. But being flexible on when does this work for you? And trying to make sure that you prioritize that. I love that. Wow.

Danny: That brings up a good point because two to three weeks, I'm imagining you're trying to narrow it down as small as you can. But there are probably things happening on the interviewer's side that complicate things that maybe the interviewee doesn't really know. Is there anything that you could talk to us about, like what are some aspects in the interview process that is difficult for the interviewer?

Spence: A lot of interviewers walk into some interviews...or in general, as humans, we have this unconscious bias. It's really hard for interviewers to stay objective. It depends on the disposition that day. Is that person having a great day or a bad day? All of that informs their process. So we make it a huge point when all of my interviewers are volunteers from other teams, so they go through training, and we make it a huge point to talk about unconscious bias, making sure that you're being objective when you're evaluating.

I have an Excel spreadsheet that I use for all of the feedback during our interviews, and they're sent to the interviewer separately so that way, they're not affected by our earlier interview and reading those comments. So making sure that they interview in a vacuum, just being aware, we very specifically set out what they should be looking for.

Even though they're doing a technical interview, we're not judging you on your ability to finish the technical; we're judging you on your decision-making and how you go about solving the problem. So you are doing a technical interview, but we're more focused on how you work as opposed to did you get this thing done? Where's your knowledge at? How do you work? Those things are important.

Danny: That's such a good thing to hear from someone who is deeply involved in the interview process for a company because you can hear that from an instructor. Like, "They're not going to hire you if you finish it. So they want to see how you work and what decisions you can make." But you'd be like, okay, well, I don't know, it always ends up where you don't finish the technical challenge, and then you feel like crap afterwards because you're like --

Lauren: It's the first thing you hear, everyone..."How'd it go?" They say, "I finished it," or "I didn't finish it." That is the thing that they're evaluating in their head. But it's cool. I don't know; it's tough. We want to perform our best. We want to get the perfect answer. But I think if we just say it enough times that no, modeling what it's like to work with you and have you on the team is really what we're trying to see. What will it be like to have you added on in the group to process how we're solving these problems or approaching the problems?

Spence: Yeah, 100%, and to also help with that for the panel. So I also help out with Ignite, which is our early in career program for people who are coming out of bootcamps or college to become associate software engineers.

Lauren: Awesome.

Spence: For the process in both programs, we use the take-home challenge in the final interview. So the Ignite Program is usually adding features to the code you've already written. It's actually the same in both programs. So when you're walking into the technical, you're not walking in blind because you know it's what you've already worked on. So you're just expanding upon that.

So it kind of gives you a little bit more confidence because this is your code, and you're not starting from fresh. And all you have to do is add another feature. And there are levels. Like in Ignite, there are easier features to implement, and then there are advanced features to implement. So there's a wide range. And you don't have to get pigeonholed in something that you don't know how to do.

Lauren: You're being so thoughtful about challenging what is the traditional whiteboard interview, like, stand in front of us and tackle this algorithm problem. So first off, I really appreciate that you're doing that work. But for the listeners that do have to whiteboard interview and do that algorithm, is your advice just to not work there? [laughter] What do we say to them? I don't know.

Danny: I was going to ask, does that still happen?

Spence: It does still happen.

Danny: Oh my God.

Lauren: And places pride themselves on still doing that, especially in the FAANG space.

Spence: Yeah, Cracking the Coding Interview still has a purpose.

Lauren: LeetCode, like all of that 100%.

Spence: I think in those instances, it all depends on is this company that you're interviewing for. Is this a company that you really want to work for? I think you got to gauge that interest. Although you are being interviewed by a company, you are also interviewing that company. So if there is something in the interviewing process that doesn't sit right with you, then that's a sign. So I've gotten to a point where if I go to an interview and it's like an algorithmic whiteboarding interview in a cold environment, I don't want to work here.

[laughter]

Because my first interview at New Relic, when I went to the onsite, I didn't even feel like I was being interviewed. I really felt like I was a part of the team, and that's what really made me want to work at New Relic. The interview process was probably the most enjoyable, and it was the first time that I had gone through one where I didn't have any complaints. And it was an enjoyable experience. And another thing that I think should be spoken about is even if someone doesn't pass your interview process, if they find your interviewing process enjoyable, they're going to talk about it. They're going to say, "Yeah, I didn't get this job."

And we make it a point to tell you why you didn't get the job. I think a lot of companies ghost people after they don't pass their interviews. And in my program, I've made it a point to provide feedback for the candidate if they don't pass. So that's why I have the Excel spreadsheet where my interviewers take notes. So then, if a person doesn't pass my interview process, then we give them that spreadsheet so they can know why. There's no; I don't know what happened.

Danny: So they know what to work on.

Spence: Exactly.

Danny: Like you said, getting ghosted, which is funny because we have described this process as dating. [laughs]

Lauren: So many different times.

Danny: Yeah, so many times.

Lauren: And we should say that we have an episode coming up on the art of interviewing back the company and what to look for in those moments. So we will drill into that for sure.

Danny: It's just funny to me that yeah, you'll put in all this work like a couple of weeks, and then you get the email like, oh, I'm sorry, but we decided to move on with someone else. And you're like, but why? [laughs]

Lauren: Or they say, "We found someone who's more experienced than you." And it's like, wait, but you recruited me. You came after me. You knew my experience level. I don't know. There's been a lot of frustrating moments where coming from the education industry; I wasn't familiar with recruiting emails. I felt so glamorous when recruiters started reaching out to me. [laughs] But that doesn't guarantee that you're going to get the role either. I did not put those two together until I experienced it.

Danny: Would you always suggest, Spence, that for anyone who's going through the interview process, whether you get the role or not to always ask for feedback afterwards? Even if you do get it, you're like, "Can I actually get feedback on my technical interview? What are some great points that I did, or what were some things I need to work on?" I think that's always nerve-wracking to be like, okay, well, you don't like me, so our relationship here is over.

Spence: I think it's important to ask for feedback. You're not going to always get it from every company. But I think it's important to ask because, for me, I want to grow. If I don't succeed, I still want to know why so I can improve on that process. You should be always striving to improve yourself, and that's just a personal mantra.

If I've gotten the job, I think my manager is going to tell me the things that...or I would hope that my manager would work with me on the things that I need to improve on. And I think that's where one on ones with your manager come into play. So you could have an open discussion about where you want to go as an engineer and also what you should work on.

Lauren: I'm curious about the advice you have for folks that are listening that might be gearing up to go through their first round of interviews or people that are in the industry and are looking to pivot and find a new role or maybe brushing up on their skills. It sounds like you see a lot of interviewees on the day to day basis. [laughs] Are there major missteps that you see people taking or advice that you could share for them?

Spence: Cultivating good interviewing skills. And that can look like doing mock interviews. I think there are a number of websites where people are willing to volunteer their time to do mock interviews with you. Because the moment you walk into your first interview, no matter how prepared you think you are, you are not prepared, [laughs] and your anxiety will rise. It is inevitable.

And it doesn't matter as hard...I've tried many ways of lowering my interviewees' anxiety before we start the interview, and nothing that I do works. I've tried in Ignite. For the coffee screen, we let them Google. They can use whatever tools they want, whatever language they want. They don't have to share their screen with us if they don't want. We try to get them to create the environment that they work best in to lower their anxiety levels as much as possible. And even then, sometimes, you can't beat your initial anxiety, and that's just from lack of experience interviewing.

Lauren: The only way to overcome that is repetition in theory.

Spence: 100%

Lauren: I've received the advice before. Let's say you're about to do a bunch of interview rounds, or you're declaring to the internet on Twitter that you're looking for a new role. And so you're about to just start taking a ton of screens or recruiter calls. So to set them up so that the first interview is the one you want the least or think you want the least and to save the one that is your Northstar dream job for a little bit later in the process if you have the privilege of being able to orchestrate something like that.

Spence: That's the method that I would recommend as a person who's starting out interviewing, and that's the advice that I received when I first joined. So when I first started looking at jobs, I just applied to everything on earth because it's a numbers game, especially for that first one, that first job, it is a complete numbers game. And you have to just apply for everything.

Especially coming out of a bootcamp, I try to tell people coming out of bootcamps your only goal right now is to get that first job, not to get your dream job on the first go. It's just to get the first job. Get your foot in the door, and then everything else after that becomes a lot easier.

A lot of finding new jobs later on in your career is through the relationships that you make with the people you work with, the events you go to. And I think after my first startup interview, all my jobs came through referrals. I would say, "I'm thinking about finding a new job." And all of my friends were like, "Hey, my company's hiring. You should come try this out." And referrals get looked at before people who apply cold to interviews as well.

Danny: You had talked about how you would go to meetups. I was wondering if you could talk about how that is like an interview process in itself in the way that you would go and introduce yourself to these companies. But what was your process?

Spence: [laughs] I'm not sure how it works in this new world that we live in. But in the before times, in San Francisco, there were literally 5 to 10 meetups every day. And they're at different companies, companies-sponsored meetups. And so, when I was in San Francisco, my original goal for going to meetups was I was hungry, and the food was free.

Lauren: I did the exact same thing when I was in Seattle. [laughter] And it was always pizza usually, but I was like, fine, I will take it.

Spence: Pizza and beer, so free food and drinks. That was my original motivation for going to meetups.

Danny: Damn.

Spence: Once I started going for the free food and drinks, random people would just start talking at the meetups. And they're like, "Oh, what do you do?" and I had like this spiel prepared, "Oh, I go to this bootcamp, and I'm almost done. And I am thinking about looking for jobs. So I'm just going to meetups to meet people and expand my network, so when I'm ready to look for jobs, I have people that I can reach out to."

And then, nine times out of 10, half of the people that were talking to me at these events were the recruiters for the company that sponsored the event. So it didn't matter if it was an AI meetup or a Python meetup, or an IoT meetup. I was just going to all of them. And there are companies who are at the meetup that are recruiting. But the reason why companies sponsor meetups is because they're looking for talent. If you go to meet up at, I don't know, Twitter, there will likely be a Twitter recruiter in the crowd. So I would usually just mingle around until I found that person and got their card.

Lauren: That's brilliant. It's a great way then to build that network of folks, even if not that round of interviews too. They will just forever then be connected on LinkedIn or just a great way just to have that first initial conversation and have your foot in the door somewhere.

Spence: Yeah, definitely.

Danny: I wonder do you know what that process looks like now? Do you have any connection to that and what New Relic...specifically I guess with New Relic because it's --

Lauren: We work for...[laughter] It's important to clarify that. I'm like, should we be transparent here? [laughs] It's like us giving stock advice or something.

Danny: I think it's obvious that we work --

Spence: Just insider information.

Lauren: I know. What are we doing? [laughter]

Danny: Are there recruiters in Zoom breakout rooms? [laughs]

Spence: That I don't know. I haven't really attended a meetup in this new world. So I'm unsure because my strategy made sense for being at an in-person event.

Lauren: We should get a recruiter on the show. We always try to find a call to action for the audience. That is mine and Danny's call to action homework, to find a recruiter to come talk about COVID times. What is the advice to like...I don't know. I felt like I was being pretty sneaky about it when I would go to the meetups and be like, well, I'm a bootcamper, but I'm really excited. I was probably barely transparent about what I was doing, but it worked. [laughs]

Spence: No, actually, I think it is a secret because even when I would tell people at my bootcamp what I was doing, they still wouldn't do it.

Lauren: There's a fear. There's a fear of going blind to a meetup. I'm pretty extroverted.

Spence: Same.

Lauren: So it played into I wasn't super fearful of that. But yeah, sometimes I would show up, and it was lame. And I'd be like, oh, this is not the space, or this is not the company I want to work for. And so it gave me a good gut check too on places, or just they weren't my people I guess is a way to see it, I don't know.

Spence: That makes sense.

Lauren: Like, I was the only woman in the group. And so I would be like, okay, I don't think I'm going to come here.

Spence: Yeah, it was not a vibe.

Lauren: Yes, exactly. So that's what I was trying to say.

Danny: I will take my pizza to go. [laughs]

Lauren: But I am sure there are tips and tricks to be able to navigate it now also.

Spence: Yeah, I'd be really curious to hear how you have to adjust your strategy in a Zoom meetup environment.

Lauren: And it maybe could be more welcoming and inclusive to folks who don't identify as extroverted and are fearful of the networking concept. And I felt really privileged in that way that I was like, yeah, I'm going to go to this meetup tonight after class. And, I don't know, I want to acknowledge that that was comfortable for me and not a super safe feeling for everyone.

Spence: That's very true.

Lauren: So hopefully, there are some cool new ways to build those relationships.

Spence: A lot of this new work world is very strange, but it's also presented itself in a number of positive ways. We're discovering talent that we would not have been able to interview before because New Relic is now Flex First, so we're fully remote if that's your flavor. So some people that I've been discovering, like in the Midwest, that I would have never been able to interview before. There's amazing talent all over the country. But now I have free rein to go and find those talents in those under...basically looking under rocks that we haven't looked under before.

Lauren: That's awesome. And it allows people to stay where they are comfortable or can afford or whatever it is and not have to move or relocate for a new role, which could then set them up for just maybe not positive work-life balance experience or whatever it is. But yeah, I love that it's allowing us to spread our net wider and get a better pool of candidates too.

Spence: 100%.

Danny: You had talked about how nerves are always going to be coming into play within the interview process. And I wanted to see if we could expand on that a little bit. What are some dos and don'ts that you notice in the interview process? Is there anything that you are just like, don't do this anymore, people?

Lauren: I want to know what you think is a don't Danny. [laughs]

Danny: I would say I think in the technical interview, don't not talk, for instance.

Spence: To expand on that, Danny, and this is something that I've been discovering for the interviews I've been doing lately because I do a number of different kinds. So there's like, we do a 15-minute interview, which is just for early in career like a knowledge check. And it's just to see if they can solve the problem, which is something really simple like transforming an array into an object and manipulating the data. And that's very different from a one-hour technical interview.

So basically, what I'm saying is in this 15-minute interview, if it is more comfortable for you not to talk to me and just whatever you need to do to get it done. So like in a 15-minute interview, the goal is just to get the challenge completed as opposed to like an hour-long interview where it's like, okay, now I want to hear how you think.

So you got to look at how much time you have because a lot of people in the 15-minute interview want to talk to you every step. So then halfway through, I'm like, "You could just focus on finishing the challenge." You don't want to tell them that it's a pass or fail type thing. But that's what it is.

Lauren: So do you tell them that? Like, if you notice that they're tiptoeing towards the end of it, you're like, "I just want to see this." [laughs]

Spence: It's different when it's part of their process. And then you can tell after a while if it's a process of how they work or if they're just trying to explain everything that they're doing. So in the first few minutes, I'm not saying anything, but after a while, it becomes apparent that they're just trying to showcase how they think in 15 minutes. And it's hindering them because they're not getting work done. So then I'll say, "Hey, you don't have to explain every step. I can get an idea of where you're going. Just work on the challenge."

Danny: See, that level of communication is good because there'd always be times in an interview where they would tell me like, "Okay, now we've done the behavioral. So next week, can we schedule a technical?" I'm like, "Oh yeah, what will I be doing?" And they're like, "Oh, it's just going to be like a little fun little algorithm thing." And I'm like, "What does that mean?" [laughs]

Spence: Yeah, that's the other thing that I don't like about interviewing, walking in blind. Because when you're at work, you're never walking into work blind.

Lauren: No.

Spence: If you're just walking into work and you don't have to look anything up, you are an engineering god, and you're unstoppable. [laughter] But for us mere mortals, we all have to look up the documentation to figure out how to do the thing that we're supposed to do. So for my technical interviews, I give you an idea of what you're going to be working on. Like, you will be working on a continuation of your take-home challenge. I don't do algorithm things. But I did interview at Facebook once, and they gave me a packet of things that I could have been interviewed on, which was very helpful.

Lauren: To be prepared for.

Spence: Yeah, to be prepared for. Like, these are the sort of questions that we might ask you, at least some examples. Because walking into a final interview blind and then asking someone to do something highly algorithmic is insane. [laughter]

Lauren: And yet, it's still like...every time we talk about this, I get so triggered back to those moments where you're like [gasps]

Spence: Well, I actually didn't study that last night. [laughs]

Danny: The one thing I didn't look up.

Lauren: Yeah, exactly, or the thing you were about to work on. [laughs]

Spence: As an interviewer, like, what are you evaluating me on? What does this prove to you that I'm capable of doing? And I think that's why we have to look at it from both sides because sometimes it's just some guy who got voluntold to do this interview. They don't really care either way. So it's not like they're looking for you to crash and burn, but also, are they looking for you to succeed? Are they setting you up for success?

I want people to feel like they can do their best work when they come in for an interview. And a large part of that is creating an environment where they know that they're supported, or they at least feel they have the tools necessary to be successful instead of just walking in blind one day and being like, Oh God, I don't know what's going to happen next, but I hope it's something that I actually know how to do.

Lauren: Well, I mean, I just have to say this. I'm so impressed with the thoughtfulness and conscientious preparedness that you're hoping to help interviewees be equipped with when they come in to interview with New Relic. So thank you. It's a deep level of empathy that you're showing people too. I think maybe because you experienced it trying to find a role also that it allows you to be a good advocate for them, I guess.

Spence: My entire goal is I'm trying to find talent. I'm not hiring for experience. Most of the time, I'm hiring for potential, especially because a large part of what I'm trying to do here is develop more diverse hiring practices so that we can improve diversity in tech because it's skewed one way. And in order to unearth that potential, you can't keep using these outdated hiring practices because people who go to bootcamps didn't sit in computer science classes to learn all of the advanced, I don't know, principles of software development. But what they can do is put together applications there.

Lauren: Hell yeah.

Spence: They can put together applications. They know how to implement APIs. They know how to do the physical work, but it's not they're being architects from the jump. You're hiring engineers to build applications, build features.

Lauren: Right. Demonstrate grit. Can you learn something really quickly and not have a ton of guidance on how to get that done? I love it.

Spence: Looking for these intangible skills. So I don't need a potential employee to have every skill set that I need for this particular role. But do they have the potential to learn that? Have they been tenacious? We can't keep doing the same things and expecting different results. If you want a different tech landscape, then we have to change the way that we've been hiring.

Lauren: I couldn't agree more. I could not agree more.

Danny: So, Spence, every episode, we have a call to action. Previous ones have been like, oh, what would your hook for your cover letter be? or things like that. And I think it would be actually really cool and interesting if...do you have any old 15-minute challenges that you would give to people that are being interviewed?

Lauren: Oh, you don't want him to give away the secret, the one that he asks now. [laughs]

Danny: Yeah, I don't want you to give away the one that you do now, but we could say it's old. [laughter]

Lauren: And then, by the time this episode comes out, he has a new one because we shared it with everyone. [laughter]

Spence: So you want me to explain like an old challenge?

Danny: Oh, no, no. You can maybe send the challenge to me. We can put it in the blog post or in the show notes. And then we just ask the listeners, "Solve this and give us your answer on Twitter or maybe the community Slack."

Spence: Okay. I can give you an old one.

Lauren: That sounds fun.

Danny: There we go. There we go.

Lauren: We should try to do it too.

Spence: Yeah, it won't be too hard.

Danny: I run the show, Lauren, and I don't want to be doing challenges. [laughter]

Lauren: Well, we can all compare our answers. It will be fun. [laughs]

Spence: Yeah, it will be fun.

Lauren: I'm that annoying student that's like, "Um, teacher, you didn't give us homework yet." [laughter]

Spence: Wait, that was you? [laughter]

Danny: That's when everyone will be like, "Oh, my God." Everyone turns around like, Lauren.

Spence: How dare you.

Lauren: I can't help it. It's a fatal flaw. [laughs]

Spence: I was not a fan of homework growing up. I thought homework was like...I was like, but I understand the subject. Why do I have to do homework? I was like, this is practice, right? So if I understand how to do it, do I need that --

Lauren: I'm good.

Spence: Isn't that what tests are for? Tests are for --

Lauren: Evaluate me while I'm in the classroom, yeah. [laughs]

Danny: That's what I'm going to say in the next interview. I'm going to be like, "Is this a test, or is this practice?" Because I'm not going to be doing a practice. [laughter]

Lauren: Well, it'll be fun. So those of you listening that want to do the homework with us, join us. It's going to be fun.

Spence: Yeah, it'll be good.

Lauren: Cool. Well, thank you so much for chatting with us today, Spence, and sharing your journey, too, to this role. It's so incredible the work you're doing, and I'm so happy to hear...Well, first off, to be an employee of a company that's putting in this thoughtful work but also to hear that companies, in general, are doing this. I love it.

Spence: Yeah, it's exciting. I'm glad that the landscape is changing, and people are adapting to this new world of differences. But thank you so much for having me. It was so great to hang out with you, Danny and Lauren.

Danny: Where can people find you if they wanted to reach out?

Spence: They can find me on Twitter @thespencetaylor. You can also find me on LinkedIn, but I probably...I don't know; I don't really respond well on LinkedIn. Twitter is probably the best place.

Lauren: Okay. [laughs] We'll be sure to include it in the show notes, but yeah, thank you again.

Danny: But you can also find him in the Ain't Nuthin' but a "G" Thang music video as a little baby. [laughs]

Spence: That's very true. You can find me there. [laughs]

Danny: He's wearing a little green polo. That's another call to action: go watch that music video. [laughs]

Spence: Go watch Ain't Nuthin' but a "G" Thang video. Look for the baby in the green shirt. He appears twice, and that's me.

Danny: [laughs] And that's how you end an episode.

Lauren: And that's a wrap, folks. [laughter] Oh my gosh, we'll get everyone putting the little screenshot in the response to the algorithm assignment. [laughter] It's like a two-part did you stay till the end of the episode? Oh my gosh. That's hilarious. [laughter] Well, this has been such a pleasure, and I hope you have a great rest of your day. Oh, well, that was a lovely conversation.

Danny: Absolutely lovely. Spence is such a cool guy.

Lauren: Yeah, I feel like I learned a lot, and I'm just so, so happy to hear that there are folks in the industry making this happen and doing the work.

Danny: That and I just had to throw in that he was in the Ain't Nuthin' but a "G" Thang music video as a baby.

Lauren: Yeah, I am really glad to know that.

Danny: [laughs] We're like, okay, what a great episode of learning, but also, hey, Spence, can you tell us about this music video that you were in as a baby? [laughter]

Lauren: We'll, again, link that in the show notes so you all can go check it out also. Go show him some love. He's @thespencetaylor on socials, so go say, "Thanks for joining us today as an expert on the pod." But yeah, I suppose without further ado, should we share the challenge?

Danny: Yes. [laughs]

Lauren: Okay, this is our first call to action where we're...maybe share a gist, a GitHub gist maybe, or come up with however you want to give us the solution. But here's the challenge. We'll give it in written form also on Twitter. But in whatever language you prefer, write a function or a method that accepts an object. The function should return a new object with the same data but with the keys and values swapped. Since the returned object might have multiple values for the same key, it should put the values into an array. And that's the challenge.

So we can also provide some sample outputs for you. We'll put that in-text also on Twitter but give it a go. Imagine how you might solve that and share it with us. It'd be fun to see it, and we'll be sure to make sure we give you some cool Launchies swag.

Danny: Yeah, no one has taken me up on selfies of me. So I will be sure to --

Lauren: As the reward.

Danny: Yeah. [laughs]

Lauren: Shocking.

Danny: I think that was episode one or two. Well, I'm still waiting. If you do this challenge, we're going to have some Launchies swag or maybe some New Relic swag.

Lauren: Well, if we say there's going to be Launchies swag, then we have to make it, right?

Danny: Oh, that is true. That is true.

Lauren: So I was trying to be subtle there, and then we go to our bosses and be like, "Oh my gosh, we need Launchies hoodies and hats." [laughter]

Danny: Baby onesies, I don't know why. [laughter]

Lauren: And then they'll be like, "Oh, well, we can't." We'll be like, "Oh, it's already on the podcast, and everyone submitted their answers to the challenge." We want to reward the top...let's not do the top three best answers. That feels a little...maybe the first three answers.

Danny: First three. Yeah, I'm imagining it now. It's your face, my face.

Lauren: Oh. [laughs]

Danny: Small, small print Launchies.

Lauren: Launchies [laughter] on the label on the inside part. [laughter] That's great. Or I guess another call to action could be tell us what swag item you would like to see. And then we'll bring that to our bosses and be like, "We already promised them that we would make that."

Danny: They want boomerangs.

Lauren: The thing, the throw thing?

Danny: Yeah. [laughs]

Lauren: This will be fun. Let's just watch Danny come up with swag ideas right now. [laughter]

Danny: I have a mirror next to me, and I looked at the mirror, and I saw my own face. I was like, ugh, just shut up.

Lauren: Just stop. Improv in the morning. [laughs]

Danny: Yeah, on a Friday. Work's already over.

Lauren: Oh my gosh, can you stop acting as though Fridays we don't work? [laughter]

Danny: Don't say that. Don't say that out loud. [laughs]

Lauren: Every time I schedule a recording with him, he's like, "Ah, Friday." [laughter]

Danny: It's my focus time.

Lauren: Oh, sure. [laughs] Oh gosh, that's funny.

Danny: You ratted me out. I hope no one listens to this. [laughter]

Lauren: I love that we keep talking to our bosses in it. [laughter] So they're going to start listening and be like, um.

Danny: Like, yo, what is this? What is this? Are you guys mad at us?

Lauren: Who are you helping? [laughter]

Danny: Are you mad at us?

Lauren: No, we love you. [laughter] Speaking of, go give us a follow on Twitter @newrelic. That's where you should share your answer to the challenge that would be the place or Launchies, both, I guess.

Danny: @LaunchiesShow.

Lauren: Gosh, that's not descriptive. That is not good. I should give you one handle to respond to. I'm like, whatever.

Danny: We love the chaos. Listeners live for the chaos.

Lauren: Do they?

Danny: And if you don't, and you prefer not to be on Twitter, join our community Slack at bit.ly/nrslack.

Lauren: That was subtle. That was smooth.

Danny: It's episode four.

Lauren: You’re getting the hang of this.

Danny: It's episode four.

Lauren: No, totally. And yeah, our personal handles are @muydanny, @lolocoding, and again, @thespencetaylor, our guest today, so go give them a follow.

Danny: And and and FutureStack CFP is still open.

Lauren: Yes.

Danny: And it is May 17th through the 19th.

Lauren: In Vegas.

Danny: Vegas.

Lauren: Registration is open too.

Danny: And it's at The Cosmopolitan.

Lauren: Fancy.

Danny: We love that.

Lauren: Are you going to be there?

Danny: I am.

Lauren: What? The chance to meet Danny Ramos in person.

Danny: Oh God, yeah. I can sign the swag that you get. [laughter]

Lauren: Will you sign it for me too?

Danny: Yeah.

Lauren: I'll give you a stamp of my signature.

Danny: Just like that. I'm only going to be there for, I think, a day or two because I have to fly out because my brother's graduation is the next day.

Lauren: Oh, that's so nice that you'll be there for both, I suppose but more for your brother. [laughs]

Danny: I even asked. I was like, "Do you care that I'm there?" And he's like, "Um, noo." And I was like, that means he does.

Lauren: Why did I ask?

Danny: [laughs] Yeah.

Lauren: What am I doing?

Danny: You're 17. You don't know what you're talking about.

Lauren: Oh, that's so sweet. That'll be fun. That's great. I will not be at FutureStack. But I've been very involved in the programming for it, and it's going to be incredible. I'm very bummed to be missing. But it is a hybrid event and so, folks, if you want to register, watch the talks online. Yeah, that is definitely an option also. It's going to be jam-packed with great talks and content for SRE and DevOps, and developers.

Danny: Yeah, absolutely. And there's a hackathon happening, FutureHack.

High Stakes and High Stacks with Or Weis

Mandy Moore — Wed, 16 Mar 2022 14:46:23 +0000

Or Weis is a Founder, CEO, and serial entrepreneur. His latest venture Permit.io has just raised a $6 million seed funding round.

In this episode, Or talks with host, Aaron Bassett about working in Intelligence Corps in the military and focusing on development around cybersecurity, how when building anything significant in the world, if it has actual impact, it requires a lot of effort, and how as an entrepreneur, it's always great to create products in which you have empathy for your users. Understand your users.

Links:

Permit.io (Twitter | LinkedIn)
Or Weis: Twitter | LinkedIn

Give us a follow: @PolyglotShow

High Stakes and High Stacks with Or Weis

Polyglot

Your browser does not support the audio element.

1x initializing... ×

Transcript:

Aaron Bassett: Hello, everyone, and welcome to another episode of the Polyglot Podcast. I'm joined this week by Or Weis. Or is a Founder and CEO, and serial entrepreneur. And his latest venture Permit.io has just raised a $6 million seed funding round. Hello and welcome to the show, Or.

Or Weis: Hi, Aaron, it's great to be here. I'm excited to talk with you.

Aaron: Hi, good to have you. I know we were just chatting a little bit there before we actually started recording. And we were already starting to get into some of the answers to these questions. So I can tell even before we probably get into it, it's going to be a really fun conversation. Was that a fair intro for me to call you a serial entrepreneur?

Or: Yeah, if I like it or not, that's kind of the situation I'm in. I find myself constantly starting new projects, starting new companies. I do think I bring them to a significant level of growth. But I should probably start to focus more on the growth stage than starting new things stage. But it's just so fun starting new stuff.

Aaron: Oh, I am 100% there with you. Yeah, it's a bit of an issue of mine as well. I really enjoy that ideation and that excitement you get from starting something new. But yeah, I don't mean to say serial entrepreneur in a negative way. The companies that you've founded they have gone to be very successful, like Permit.io with the seed funding round.

Or: I'm obviously a bit tongue in cheek with that statement.

Aaron: [laughs]

Or: But yeah, still, I think I can do more. That's kind of the mindset I'm in now. I want to reach the stars or, as Steve Jobs said, leave my mark on the universe. But we'll have to wait and see.

Aaron: [laughs] Okay, we can go into the different companies you started in a second. But let's go right way back to the beginning then. So what got you interested initially in tech?

Or: Well, I basically got interested in tech without actually being interested or aware that I'm going into tech. Very early on, my parents and my sister, my older sister, kind of got me working with computers. I basically had been almost writing code at the age of five.

Aaron: Oh wow.

Or: In elementary school. And then, in junior high, I started getting into building websites and small applications and playing with Visual Basic. And without really knowing it, it became a key part of things that I do, a big passion of mine. So I can barely remember myself not working on tech and software.

Aaron: [laughs] So what was the first computer you had then?

Or: An IBM computer, I think it was like a 386.

Aaron: Wow. It is going back a while.

Or: Yeah, it's not like a Commodore or anything like that but still pretty, pretty basic. It only had DOS. And the first things that I learned to do were like DOS commands because there were games I wanted to play. So I had to know how to insert the floppy disk run and install. And I barely knew how to talk or to communicate fluently. [laughs] But I already knew how to type the commands and that I guess was a good kick-start.

Aaron: It's such a common kind of way people get into programming. It seems to be either they wanted to run games off of floppy disks, or they wanted to customize their Myspace page. That's the two ways when I talk to people in my generation [laughs] about how they got into programming. That comes up a lot.

Or: Yeah, the next big step, if we can call it that, was starting to build websites on GeoCities. Remember that?

Aaron: Yeah. [laughs]

Or: So that's even before MySpace. And there was no drag and drop. You had to write code to make any of that work. And I remember working with Visual Basic then. JavaScript wasn't even mature enough at that point in time. It's an interesting flashback to think how premature and how unorganized the entire web was, but it was still fun and things kind of worked. And we had that thing tracking your cursor on the website and all these kinds of silly things that I just found fun as a child.

And from there, I kind of got deeper into coding. I learned C and C++ and started building more games and stuff like that. Again, it was still more of a hobby. I can only say that I really got serious about tech and really just started to understand technology when I got drafted into the military and served in the Intelligence Corps. That was really, I think, a really significant milestone in my career, turning me from like a snot-nosed kid that plays…and does a bit of hacking into a full-blown developer.

Aaron: Sure. And so your time in the military then was your focus then on application development, or was it the tools you interacted with? What really sparked that change then from a hobbyist to a --

Or: I actually can't say too much. Well, I can tell you, but I'll have to kill you.

Aaron: [laughs]

Or: But what I can say is I worked in the Intelligence Corps. So the Intelligence Corps is obviously responsible for collecting intelligence. And I focused a lot on development around cybersecurity. I had the good fortune of working on significant projects that had, at the end of the day, amazing impact on lives, on the geopolitical situation. And in all cases, things that I look back in retrospect, I was like, that's part of a science fiction novel or a movie or something. And that really opened up my eyes to what is possible, what you realize is possible, and what actually is possible.

There's a talk I gave a few years ago back in San Francisco in ObservabilityCON. I talked about high stakes and high stacks. And there, I covered a project that I worked on where we had a limited set of opportunities to deploy to production, which is really where when you think about the cloud nowadays, everything is CI/CD. You constantly end up deploying again and again. It's almost transparent. So think about a project where people come and tell you, "You only have four opportunities, that's it. If you don't get it by the fourth time, it's done; people are going to die."

And we ended up having obviously bugs and errors in our code and having to debug those with bits and glimpses of information. For people looking, you can find this talk on YouTube if you want the full story. But again, experiences like that both kind of enabled me to see how deep you can go with software, the big impact that it can have. And also working with really challenging stuff like basically putting your head to the wall; you either get this right now, or you never will, and there are significant consequences, on average tends to get the best out of people. So it really changed the way I'm able to work with software.

Aaron: I've never been in that situation military-wise. I have worked in the public sector before. And it is a completely different way of working as you said. There's so much siloed information. There's so much you have access to and don't have access to and deployment and things. It's just so, so different to anywhere else, any other situation I've ever had to work in.

It does, whenever you come out of that, at least for me, whenever I came out of that kind of environment, we'd be very grateful for the almost free-flowing CI and CD that we would have in the public sector. But yeah, it's different stakes involved. And that's why the checks and balances they have are there, I guess. So once you came out of the military...how long was your military service? I'm sorry, I don't know anything about the drafting.

Or: So it's a mandatory three-year service. Now it's like two years, almost three years. But when I was there, it was exactly three years. And I did an additional three years. So I did a bit over six actually, so six years in total. Some of them is just a grunt worker or a junior developer in some cases, if you want to describe it that way.

Aaron: [laughs]

Or: And other parts of it as an officer and a team lead and kind of more senior developer, I guess. And also, I find it hard to convey to an American audience often because they don't really have similar experiences. So this is the age where in the United States you go to college, and it's like college is obviously a much more relaxed environment, usually more relaxed than high school. So for us, it's vice versa. They take you out of high school and just throw you directly into bootcamp, and bootcamp is very strict.

Aaron: [laughs]

Or: The purpose of bootcamp is to basically break you as a person and reshape you into something that the military can actually work with, and it's a generic grinder. No matter who you are, you go through the same steps, the same yells, the same exercises, the same everything, the same using a rifle kind of practice. And when I did my service, I had occasions where I was doing very advanced software work.

But at the same time, they will tell me, "Oh, the Prime Minister is waiting on the result of this project. This is the highest priority." And with the same breath, another person, another officer would come into the room and say, "We need another person for guard duty. So you're off this project for two weeks. Go stand on top of a hill with a rifle and guard something," in the middle of nowhere. So it's very weird. It's not something that I find easy to convey or give examples to. But it's a unique experience, and I think it's, to say the least, it's kind of character building, I think.

Aaron: Sure. And did you find then whenever you left the military, transferring that knowledge and that experience into the private sector was that easy for you to do? Was it difficult?

Or: Oh, well, it's definitely difficult. Building anything significant in the world, no matter why you do if it has actual impact, requires a lot of effort. It's not a walk in the park. But I think a lot of the experience I gained there aside from giving me really significant skills and tools that I can work with it gave me and other people that served with me in 8200 and similar units that unique perspective on what is feasible and what you can do if you set your hearts and mind to it.

And maybe I can give you another example here. So I had the good fortune of, during my service, to also work with some American counterparts. And we were working essentially on the same project from two different sides initially without knowing it and then ending up through relations talking about the project. And it was very apparent the different perspective each organization has. So most intelligence, I won't name specific names, but most intelligence American organizations have impressive budgets.

Aaron: [laughs]

Or: The Intelligence Corps in the IDF has a decent budget, but it doesn't compare, to say the least. And so we were like, "Yeah, we were trying to get that piece of software. So we were hacking their..." hacking like building software. "And we were inventing new protocols and stuff just trying to replicate that element." And our counterpart on the American side said, "Oh, we just bought the company that produces that."

Aaron: [laughs]

Or: But that mentality of no matter what, we'll be able to fashion a solution for a technical problem with the least amount of resources really paints a picture of you can do anything if you set your heart and mind to it. And I think, as I said before, so it's hard no matter if you are going to work in a startup or you're going to start your own company. It's going to be hard.

But if you have that basic belief that you can do it and you have the realization that there are bigger challenges and you might have already solved them in the past, it gives you the perspective and alignment I think to get down to it and be to some degree fearless and just jump in and get the job done.

Aaron: I used to get asked a lot when I worked in agencies if, you know, "Is this possible? Can we do this?" And so it was like, yeah, you give me unlimited time and unlimited budget, and I can do whatever you need me to do, [laughs] which seems to be a very American response from what you're saying. But you came out of the military back into the private sector. Did you immediately jump into running your own companies then, or how did that get started?

Or: So I joined a startup as the first employee. I knew that I wanted to start my own company. I knew it even before I got drafted. It was, for some reason, kind of engraved into my mind that that's something that I should do. And the service in the military only strengthened that. But I was cognizant enough of the challenge and how different of a world it is that I said, oh, I should probably join a company first, a startup, and see how this kind of thing even looks like before just going running blindly into the battlefield.

And so I joined a young company as the first employee, as the first developer, along with another friend. So we were both two first engineers there, a company called Intigua. It kind of pivoted and changed to a different company called JetPatch. But anyways, back in the day, we were essentially building containers before containers were a thing but with a really bad go-to-market as compared to Docker, for example, that ended up eating the market.

So I joined that company, and we built some really crazy technology there. So we basically implemented containers through RPC to other virtual machines. There weren't jails or containers in the Linux kernel at that point in time. So we just used another machine as kind of the encapsulation there for that. So the tech was pretty amazing. We were doing RPC hooks and RPC calls and re-compiling applications on the fly to basically produce that, but it was definitely an overkill.

And in the end, the far simpler solution won. And I think that's one of the downsides I think coming from...so I gave a bit of praise for the advantages of Israeli tech perspective. I think a downside of that perspective is overdoing it. A lot of times, a good, simple product with good marketing can take you a far longer way than a very advanced product with capabilities with poor marketing. So that was an important lesson.

But I worked with some really great people in that company. That other employee that I mentioned ended up co-founding Solo.io, which is a significant player in the service mesh space today. And the CTO of that company ended up founding another company called Logz.io which is also a significant player in the space. And there are a bunch of other good people that worked with me in that company. I won't mention all of them just for the sake of time.

Aaron: [laughs]

Or: And after that, I started a startup called Reactful that is still ongoing, but it's kind of small. And I don't feel passionate about it enough to go into it, but it's still live. People can go to reactful.com and see it. And afterwards, I got back to the industry. And I worked as a freelancer and then as a VP of R&D in a cybersecurity company called Netline, where I reminisced back to my days in the army and worked on security projects for governments and like-minded agencies.

I'm really happy to say that I only worked on defensive projects as opposed to offensive ones, especially with today's news. I always felt that offensive cyber capabilities are essentially weapons, and they shouldn't be commercialized, at least not without very significant regulation. And I think we're starting to see the outcome of that regulation missing. We're starting to see it in the public space now.

Aaron: Yeah, they are weapons. So it's good, as you said, that we're seeing some of the regulation come through for them.

Or: It's not quite there yet, though.

Aaron: Yeah, yeah, it's not. It's very much...and there's still a lot of work to be done there. But it's good to see it's starting and being recognized for what it is. Before we get into the actual projects themselves at the companies you started, which I do want to expand upon, looking at them, they all sit in this Platform as a Service kind of sphere. Was that intentional or accidental?

Or: Maybe that lesson I learned with Intigua, that first company that had great tech but poor go-to-market. I think that really kind of encouraged me, especially looking at how go-to-market evolves today, to really go for models that give you an advantage in how you interact with your customers, especially coming out of Israel. The more you need to depend on complex sales cycles; you're in a disadvantage compared to other players that are closer to the market.

Aaron: Sure.

Or: So adopting things that can remove friction, that can speed up the sales cycle, that can speed up the adoption cycle are something that just makes a lot of sense to me. And I think especially combining that with modern trends like product-led growth, PLG, I think it's just the way to go. This is where all the market funnels are aiming towards. And the other side of that is the audience that I decided to cater to.

I feel as an entrepreneur; it's always great to create products that you have empathy for their users, that you understand their users. Ideally, you are the user. So I find myself mostly catering to our developers. And developers love infrastructure platforms, software platforms that they can build on. So that's what I ended up building. And the combination of giving quick access to that and enabling developers on that that's just my sweet spot.

Aaron: Yeah, there is that old advice of you write what you know. I think that applies here as well as it does for authorship, even for myself. I've been in developer relations for quite some time now. And I tend to go towards companies that are CPaaS or Platform as a Service type companies because that's what I know and what I enjoy working with. And if I'm going to be an advocate for something, it's going to have to be something that I enjoy. So yeah, I can definitely see how that would work as well for founding your companies. So let's talk about one of your first companies, then, Rookout. What was your elevator pitch for it?

Or: Working at Netline as a VP of R&D, I was really frustrated when we started to adopt more cloud development, and more containers, and Kubernetes, and flows like that. I was really frustrated with developers coming back to me and saying, "Really, I had my heart set on finishing the task you assigned to me today, but I ended up just not being able to debug it because it's running in a container in the cloud. And it was too complicated to get a glimpse of what's going on there. And so I wasn't able to finish the task today."

And I was like, why is this so complicated? It used to be so easy. I had the code running on my machine. I could set a breakpoint and see exactly what's going on, but now I can't, and that's super frustrating. We got all that power, but we lost that basic intimacy with our software. So that was like the basic aha moment or pain moment for myself that I was experiencing. I was like, I want to get rid of this. I want to get the ability to debug software in the cloud as if it's running locally. And that was kind of the basic idea for Rookout.

And the pitch there was like production debugging in observability. So you're getting all of these alerts from great solutions like New Relic and your log solutions. But at the end of the day, you need to get to how the code is behaving, not just the alert that just happened. You need to see what the code is doing in order to fix it. And so you can reiterate and add more logs, but that's both a risky process and a time-consuming process.

So what we offer you instead is non-breaking breakpoints, and as an experienced developer, you already know how to set a breakpoint. So it's the same thing, same interference only now it's running in production but in a way that doesn't stop. It doesn't hinder your production. It doesn't slow it down. But it gives you whichever values or variables, new log lines, traces, whatever you want, instantly on your screen without having to restart, redeploy, or write any more code. So that's kind of the offering there with Rookout.

And it essentially created a new category, the production debugging space. There are like maybe four, maybe even five companies now in that space. I'm kind of happy to say that Rookout was a significant element in starting that space, maybe even THE company that started that space. And that's, to some degree, an impact that I had on the world, which I'm excited about, like being a category. Who knew?

Aaron: [laughs] Yeah, it sounds like the cloud equivalent of moving from console.logs to using a debugger. You're moving from log messages to having an interactive debugger that you can use in production, which I'm sure any developer who's gone through that journey is as you level up your own development skills, you start off just putting alerts for your code, and then you discover a debugger. And you can look at any variable you want in the context of what's going on. It's a shift really in the entire way that you debug and that you write code.

Or: Yeah. And also, once you get used to it, once you get used to having advanced debugging capabilities, having them being taken away from you is just a horrible pain. And the problem is still increasing. More and more companies are moving to more microservices and to serverless and to more distributed architectures and more velocity in scale of software.

So now it's not just debugging one instance. You have ten different instances behind the load balancer using other microservices. And you need to be able to slide through all of them, and tracing helps to some degree. But again, tracing gives you a sample, and a lot of times, you want to go deep into this specific problem and solve it. That's what Rookout does.

I'm still a board director there, still a stakeholder but not that actively involved today. And the company is still growing and doing well, which is awesome to see. I actually had a pitch from another entrepreneur today. And they told me...they kind of described...I won't go into this, what they're working on, because it's their thing. But they described it as Rookout for something, and that was a very cool experience.

Aaron: But yeah, as you're saying, once you get used to those kinds of things, it's very hard to let them go. I know whenever transpolation first was taking off, oh, you write your code in this one language, and it gets transpiled into another language.

The tooling around a lot of them was very difficult. And you would lose a lot of the...your stack traces would be inaccurate, and the lines that it pointed to would be wrong. Or your stack trace would just be within the transpiler rather than in your actual source code. If you don't have accurate debugging tools, it makes your life as a developer so much more difficult.

Or: Completely. Totally. That's so true. And it actually reminds me of one of the unique challenges that we had with building Rookout. So you would think that the biggest challenge would be the one where you're able to inject those debug points like the ability to...what we essentially do is recreate hooks in memory to grab execution for a moment and then additional purpose code to extract specific variables so you'd think that that's the...So that element of the ability to insert a breakpoint on the fly that's what people mostly perceived as the magic part. Even advanced engineers looking at it they're like, how the hell does that even work?

Aaron: [laughs]

Or: But in retrospect, that was the easiest part about it, getting the hooks into it. The more challenging part was actually around the area you described with transpiling code. And the challenge there was actually the human-machine interface. So you know when you're clicking on your code what line you want. But you don't necessarily know which version of the code is running.

And you don't necessarily know how you transpiled it specifically to run in production, not because you're not proficient or anything like that but just because there are a lot of elements in the way that you don't necessarily control like your build process or some other elements that other engineers worked on. So getting the people using the product to be able to understand those many differences and select that right version of code that was one of the most and I think still is one of the most difficult parts of getting that experience right, I'd say, which is ironic to some.

Aaron: Yeah, it kind of harks back to what you were talking about right at the very start of this episode, where you were talking about how you first got interested in technology, and you're writing little HTML pages, and JavaScript is just there for mouse cursors. And I know for myself and a lot of other people that's how we got started as well.

And a lot of it was you viewed source on a page because you're interested in how did they do that? And you could go look at the code. And then to run your own code, you FTP-ed it to up to GeoCities or whatever site or Angel hosts or whatever other free hosts you'd find or other FTPs that you'd find.

Or: It's all nostalgia.

[laughter]

Aaron: Yeah, and it just worked. There was no build process. There was no transpolation.

Or: It was simpler back in my day.

Aaron: [laughs] Yeah. I do feel bad sometimes for developers coming into the industry these days that it's so powerful what we can do, but it seems that the barrier to entry has been raised so much as well.

Or: That's true. The complexity like the stack itself, building the most basic thing, that stack is constantly growing all the time just looking at the package.json like the requirements for a Common Node.js or even front-end application. That's increasing in volume by the minute without any advanced capabilities being added. It's just like a natural trajectory. And that, at least I think, blinds the engineers to the fundamentals of how these things work because they have so much things on the top of the stack that they need to understand that it's harder for them to get a glimpse into the underlying components.

And there's a joke that goes like, real developers program directly to the compiler. And then another engineer goes, no, real developers write in Assembly. And another one goes, no, real developers take a piece of wire to their tongue and create beats directly according to that.

Aaron: [laughs]

Or: And so the stack, like the baseline, is maybe still the same. But it got so many layers on top that you basically you can't see it anymore. And yeah, I think that, on one hand, that adds a lot of challenges for people to get started just to wrap their heads around what's actually happening when you're building software. On the other hand, you can build really amazing things. Like recently, I started working more with Next.js, and Netlify, and Vercel.

The concept of just writing code and pushing it to a Git repository, and it magically pops up on a website with a CDN, and everything is running smoothly, and you get a quick build process. That's mind-blowing for me. Thinking about that FTP process, you mentioned with GeoCities and getting every line correct because, otherwise, that thing is not going to run, and it's going to work only on a specific browser and not the other ones.

So it got more complex, but we got more power. And I think we are going to see that trend continuing. And the thing that I'm kind of hopeful about, maybe in general for humanity, if I can be so grandiose, is things like low-code/no-code. I think what's happening is we're all becoming developers, even those of us that don't want to. [laughs] But more jobs are going to be replaced by automation, machine learning agents, et cetera, et cetera.

And more jobs are already kind of turning into some kind of development work with simplified interfaces like low-code/no-code interfaces, and I think we'll be seeing a lot more of those. And I think that's a significant thing, a trajectory where we'll see impacting a lot of more industries and a lot more applications. So I'm excited about that, and I'm excited how that's going to change our society where we're basically all developers to some degree. But I'm also kind of saddened about losing that basic touch with the fundamentals of technology, like the nostalgia we just covered.

Aaron: [laughs] But they'll have nostalgia.

Or: Sure thing.

Aaron: We're expecting our first child just in a few weeks, so we're really gearing up for that.

Or: Congratulations.

Aaron: Thank you very much. And a lot of other fathers would be really excited about getting them their first baseball mitt or their first football. And it's like, well, I'm not American, so I know neither of those sports anyway. I'm like, at what point can I introduce them to Scratch or EduBlocks? [laughs] So hopefully, they'll have nostalgia for that whenever they get older. We'll see. But yeah, so you're still on the board there. But you've now moved on to your latest venture Permit.io which, as we mentioned at the very start, has just received a seed funding round of $6 million. So congratulations, by the way, on that.

Or: Thank you.

Aaron: I'm sure that has been an awful lot of work as it was only just announced very recently. Wasn't it?

Or: Yeah, it was announced just last week. We actually raised the round slightly earlier. But now, when we launched our self-service and people can enjoy the product without too much hassle, we felt it's a good time to kind of come out of stealth and announce the round and announce the company. And yeah, actually, the fundraising wasn't that hard. I did that...and I don't want to sound show-off-ish, but it was basically like two weeks.

Aaron: Oh, wow.

Or: For young entrepreneurs getting started, the average is three months to half a year. But like with everything else, once you're familiar with how it works, it's easier to go about doing it.

Aaron: Yeah. You have, as you said, the serial entrepreneur; you have that background as well. You kind of know how it works and hopefully the connections and things. That's all, like anything else, experience.

Or: Yeah, and it's still a lot of work and still a lot of tension and juggling a lot of things that you need to get right in a critical amount of time. So there's a lot of pressure, but you can do it quicker, I guess is the bottom line of what I'm saying. Anyhow, so Permit.io is another developer tools company. Again, that's my passion. And we kind of started with our own pain points as well here. And it's actually a pain that I experienced in Rookout.

So at Rookout, building our product, like any other product, we had to build access control for it. We had to build permission and role so people can use a product. And we ended up building and rebuilding this five times. And doing so, I was like, this is probably four times if not five times too much.

Aaron: [laughs]

Or: This is not something I care about as part of my product. I want to build my product, not these kinds of peripheral things that are mandatory but are not unique to this product or any other. So it was very apparent to us that it shouldn't be this way. Developers shouldn't be building access control and permissions from scratch over and over. And they shouldn't be struggling with this topic that can actually be very misleading. I thought, when I was building the first version of our access control, that oh, I'm just going to do this once, and I'm done.

But the rabbit hole often goes deeper than you think. And a lot of demands and requirements come from customers, and regulations, and security, from angles you don't necessarily expect. And they often, if you don't build it right, don't use the right best practices. You often find yourself starting from scratch. And we found that there are these experiences that repeat for every product. So think about user management, the ability to assign roles. Think about API key management and secrets management; think about audit logs.

So you're seeing what your customers did, and each of your customers paired their tenant, being able to see what they did within your product. Approval flow is like the ability to ask permissions from another fellow user, emergency access, and the list just goes on and on. Every time you've seen one of these experiences, and you've seen them a billion times, every each and one of those times, some poor schlep of a developer had to build them from scratch.

Aaron: [laughs]

Or: So our offering is very straightforward in that sense. So we call it full-stack authorization, and it's the idea that you don't have to build any of those elements unless you want to. And it's comprised of three parts, the infrastructure, so the basic components basically a Sidecar container and an SDK that you can bake into your software to enable authorization into them.

A back-office where the different stakeholders can come in and work with you on this also with low-code interfaces so, for example, you can delegate and enable security to write their policies and roles on their own without having to require you as a developer to deploy a new version.

And lastly, those interfaces that I mentioned for the customers themselves. Every customer is going to need those. There's no reason that you have to rebuild them from scratch. So it all comes ready out of the box. You plug it in, and you can focus on actually building your product.

Aaron: And I'm sure any of our developers has built many of those things many times or tried to work with some of the tools that come into some of the frameworks as well. And yeah, none of them cover all of the use cases. And you do find yourself kind of iterating over them again and again. So that sounds really useful. Can you tell us a little bit about what's in the future for Permit.io? What do you hope to achieve now that you've done this latest fundraising round?

Or: So maybe I should start with maybe where we're at now and then build to the future.

Aaron: Of course.

Or: So we started with an open-source project. We, first of all, adopted an open-source project called OPA, which is Open Policy Agent, essentially a decision-making engine that's very performant. We brought it to the application layer, made it event-driven using our own resource project called OPAL, which stands for Open Policy Administration Layer. It essentially enables you to track changes in the application and dependent data sources and sync them into your authorization there into OPA.

I'll give an example of why you need that. Let's say you want even a basic policy like only users that have paid for a product to be able to use it. That information and who has paid that doesn't sit in your database anymore. That's a third-party service like Stripe or PayPal. And you want when someone swipes a credit card, you want them to have access at that moment, not next deployment or next polling interval.

Aaron: [laughs] Yeah.

Or: So getting that event from Stripe, for example, to immediately propagate into your software that's where OPAL comes in. That's what OPAL does. And we launched OPAL half a year ago, but we had the good fortune of having a significant community grow about it. It's already being used in dozens of companies also in production in amazing companies like Tesla, Accenture, Zapier. And I don't even know about all the companies because it's open source. So I know about those companies because they came in and asked for more features and capabilities. But there are a bunch of others I don't even know about.

On top of that, we're offering our SaaS service that takes OPAL and OPA and not only offers them as a service but also gives more capabilities on top, all those interfaces, and management, and hosted key and hosted flow that just makes it all streamlined. So you don't have to build anything, again, unless you want to. And the next steps there are a couple, so you already heard that we're very open-source, connected, and driven. So we're planning to release more open source. Our SDKs are going to be more open-source and add more capabilities in them.

Aaron: That's great.

Or: We're planning on additional experiences that you'll be able to use as part of the open-source offering. We want to make this accessible to as many people as possible so people can build software with the right best practices even if they're not taking the full service. Because at least if you build it on the right fundamentals, if you use those best practices we baked in, when you want to upgrade, if it's on your own or us, you will be able to without going back to the drawing board, which can be a very painful process like several months on average. So that's one part of it. And the other part...I don't want to give too much away.

Aaron: [laughs]

Or: But I will describe what I'm seeing coming in the future, and it also kind of connects to what we talked about in how software is changing. So more and more people are going to be driving more and more software. But that software is going to be interacting more and more with other software rather than with people. So nowadays, when you're building applications, you're thinking your main users are human users. But more and more, its applications being managed by applications working with your application. And that change is only going to increase, and I'll give a quick example just to illustrate that.

So let's say I'm using my phone to turn on or off the lights, my smart lights. So it would be Siri or the Google Assistant talking to IFTTT, for example, which is another cloud talking to let's say I have a light from Xiaomi to Xiaomi's cloud talking to what's actually running on the light bulb. So we have four to five different applications interacting with one another. And they're rapidly becoming more intelligent. If you just do a quick Google search on any buzzword, you'll find that buzzword combined with machine learning.

So in three to five years from now, we'll be seeing machine learning agents all over the space. And controlling what access we have to those agents to change them, what they're allowed to do on our behalf, and what they're allowed to do in our applications is going to be critical for just being able to keep track of what's going on with all these crazy elements running around.

Aaron: Yeah, it seems like there's never a week that goes by where I don't have to re-off some app so I can turn on my lanai lights or adjust the temperature in my house. It's like everyone has their own portal, and their own authorization, and their own logins, and their own phone app.

Or: They're not enough standards. So we need better standards. We need better building blocks that are shared. That's why we're focusing on open source. And that's why we are working with a lot of players in the authentication space, also to be announced soon. We don't know exactly how the future is going to be. We know it's going to be more interconnected, and we know controlling that connectivity is going to be critical. And we want to focus on getting that right so we can keep connecting things and enjoy amazing solutions.

Aaron: [laughs] Yeah. It's no benefit to us if we've got all these wonderful devices to make our lives easier if all we do is spend our days authorizing them against each other.

Or: Exactly. And also, if they're misused, they could become vulnerable as part of that or if we can't express how we want them to actually be used.

Aaron: That's definitely a big vector as well that we're just finding out more and more about the misuse of these smart home devices and the vulnerabilities that they can bring into our home networks and things. So yeah, any movement around the security there is obviously very welcome.

Or: Yeah. So that's also why I feel like this is a good sweet spot for me and my co-founder, who comes from a very similar background. He was a student of mine back in the Intelligence Core 16 years ago. So we both are passionate about developers. We're passionate about developer tools. So our staff used to build developer tools internally within Facebook. And I already created a previous developer tools company and obviously worked a lot around security. So it's kind of in the intersection of a lot of things we care about.

Aaron: It sounds great. But unfortunately, we're at the end of our time for this episode. So I just wanted to, before we go. Obviously, Permit.io everybody should go check that out. We'll make sure it's linked and things, but it is Permit P-E-R-M–I-T.io. Go have a look. As you said, it's kind of self-serve. People can sign up, give it a try.

Or: Right.

Aaron: It looks like a fantastic service. And yeah, as we've talked about there, it really does answer a need. A lot of developers are probably building undertime. So go check it out and see if it can help you in your next project. Is there anything else you want to shout out? Any of your recent talks or anything like that that you think people should go see?

Or: Yeah. So if you go to permit.io, there's a video page. You'll find a lot of engagements where I had a talk. But I think even better; if you want just to talk to me directly, you're more than welcome to do so. I'm very open, and I always love talking to fellow engineers. You can find me as @orweis, O-R-W-E-I-S on Twitter, LinkedIn, everywhere else, GitHub. And I guess most easily is our Slack community. If you go into permit.io, there's a community on top. You can click that and just message me on Slack. And you'll find me very responsive and always happy to talk to fellow engineers working on your problems, just chatting about tech like we did here.

Aaron: [laughs] Sounds wonderful. Well, thank you so much. I will make sure that all of those different resources there, your community Slack, et cetera, are linked in the description for this podcast. So please do go check them out and pop in and say hello to Or. Give him some thoughts and feedback on Permit.io once you get a chance to try it out. This has been a really interesting conversation. Both of these things are examples of them and the many projects before. So I will definitely be trying them out myself on my own projects.

Or: Awesome.

Aaron: They look like they're going to be super useful. So thank you very much for that. And I just genuinely enjoyed our conversation. So thank you so much for joining us on the podcast.

Or: Thank you. It was a lot of fun and really my pleasure.

An Interview with Interview Expert Ian Douglas

Mandy Moore — Thu, 10 Mar 2022 13:57:29 +0000

Ian Douglas is a Senior Developer Advocate at Postman and is live-streaming his learning in public on Twitch. He loves developer education in all forms and is a strong proponent of accessible content and diversity in tech. He has about 26 years of professional experience in the industry as a developer, manager, director, DevOps engineer, business owner, freelance developer.

This season, we’re helping you level up your interviewing skills! Each week Lauren Lee, Danny Ramos, and industry experts will offer advice on navigating career progression within tech.

👉 Give us a follow: @LaunchiesShow

An Interview with Interview Expert Ian Douglas

Launchies

Your browser does not support the audio element.

1x initializing... ×

Topics Covered On This Episode:

Ian’s Background & Expertise
Progression From Coding To Teaching
The Tech Interview Guide
Tech Interview Accessibility
Common Interview Questions
Demand For Specific Languages/Tech Stacks
Tech Interviewing Resources
Working For Mitch Hedberg

Links:

techinterview.guide: Free Technical Interview Advice from Ian Douglas
Streams - Thursday and Sunday - Twitch/LinkedIn/Facebook
Vets Who Code
Pramp
HackerPen
Interviewing.io
Free Daily Email from Ian Re: Interview Prep
Ian’s Interview Prep Discord Server

CTA (Call To Action): Join the New Relic Community Slack and…

Build your board of people. Find three people in your network, friends that are also interested in tech, or people who are in tech now, and have them give you feedback or schedule one or two mock interviews. Tell us how it went!

👉 Follow Launchies, Lauren, and Danny on Twitter!

🚨 FutureStack 2022 call for papers is now open! 🚨

Sign up to share your successes and learnings in a hands-on lab, workshop, or deep-dive session to help your peers advance their observability game.

Transcript:

Danny Ramos: Launchies is a tech podcast dedicated to helping early-career developers or soon-to-be devs.

Lauren Lee: We'll share insights on how to navigate these early opportunities and bring on experts from the tech industry to give advice on general career progression.

Danny: In the first season of our show, we focused on how people launched into their tech careers.

Lauren: And now, in Season Two, we want to offer advice on your career progression.

Danny: The next 12 episodes will be all about the interview and landing your first job.

Lauren: What's up, everyone, and welcome to another episode of Launchies. I am so excited to be here today with my co-host, Danny.

Danny: I feel like we always say we're excited. Let's say something new.

Lauren: You want a better adjective?

Danny: Yeah. I'm, for one, nervous.

Lauren: Are you lying? [laughter] I'd rather be authentic. Like, here's the thing, I'm a pretty enthusiastic human. And sometimes people...like, I'm going to push back on that. I am excited. And you know what? Fine, maybe I need a better vocabulary. You're right. I could find some thesaurus.com moments. But let me be stoked about this interview that we have coming up.

Danny: No, no, absolutely. You know what? Please be stoked. I'm just nervous. Can you please let me be nervous?

Lauren: Sure. [laughter] I'm [inaudible 1:32]

Danny: Because our next guest was actually my instructor when I was learning to code.

Lauren: Okay, so that actually was something that, I mean, I was so thrilled to do this interview because I think that dynamic is fascinating for me to watch. [laughs] There's something really wonderful about teacher-student relationship. And it was fun to be a fly on the wall to watch the two of you reconnect now that you are in industry. You've landed the job that you wanted to get and that he helped you find. It was just very full circle to hear you two swapping stories and also reminiscing and just sharing. I mean, he is a treasure trove of resources.

Danny: A super, super smart guy. And yeah, I was really happy to be able to get his information, just really just hear from him again. Not only that, but also just for him to agree to be on the show and share his resources and share his knowledge was really cool. And I honestly was going back into school mode. I was just sitting and listening. I was like, should I be taking notes? [laughter]

Lauren: I can understand that. I think that's a fair...it's almost like a muscle, that memory that you're like, "Oh, wait, you're the expert here. And he is; he's an absolute expert in it. And yeah, I'm really --

Danny: Excited?

Lauren: Nope.

Danny: [laughs]

Lauren: I am happy that the audience gets to listen to this conversation today. It was, for me personally, pretty fascinating to think about his trajectory into the role that he's in today, having done the opposite. I went from teacher to coder, and he went from coder to teacher. And so when we were talking about the guilt that one feels leaving the classroom, too, my first couple of years in the industry was plagued with that.

And it was why I needed to find developer relations because I needed to feel like...I wanted to feel like I was giving back to people and making a difference in people's lives. Being an engineer at Amazon, I was not making an impact [laughter] Tell you what? I didn't move the needle there. And so yeah, it felt really cathartic almost for me to hear that he struggled with that also because, I don't know, once again, that message of you're not alone that he talks to really, really hit home for me.

Danny: I love that. I love that. I was going to say I completely understand but in a different way. I understand those feelings. I wasn't going to say that I completely understand because I've never been a teacher. [laughter] I guess I've taught improv one time, but that's not one and the same.

Lauren: Hey, I can appreciate a moment where someone feels empathy, though. So thanks. [laughs]

Danny: Look at us. We started getting angry at each other in the beginning. We laugh together.

Lauren: I know.

Danny: Now we're going through the emotions of maybe sadness right now.

Lauren: Is this friendship? Is this what it is? [laughter]

Danny: I don't know. I think that's what this is. My God. All right. Well, you know what? I think that's the perfect segue.

Lauren: Without further ado.

Danny: That's a perfect segue into this friendly interview that we have with our friend.

Lauren: Enjoy.

Danny: Enjoy. [laughter]

Our guest is a Senior Developer Advocate at Postman and is live-streaming his learning in public on Twitch. He loves developer education in all forms and is a strong proponent of accessible content and diversity in tech. He has about 26 years of professional experience in the industry as a developer, manager, director, DevOps engineer, business owner, freelance developer. This guy has done just about everything. And he loves a good dad joke. [laughs]

He also livestreams twice a week to give people free career advice for getting into the tech industry. He also said maybe throw in software teacher in there in the list of jobs because he was actually, in fact, my instructor while I was learning to code. Everyone, please welcome Ian Douglas.

[applause]

Ian Douglas: Because of love.

Lauren: When you're listing it, I'm like another one, another one. That's a lot of jobs, Ian.

Ian: He's done this, he's done this. Yeah, cue the Jurassic Park music too. It's like, this guy has been around for how long now? [laughter]

Lauren: I love it. It's a great suite of things. And I think that's going to make you just the perfect expert to be talking with today.

Ian: I guess, yeah. [laughter] Thanks for having me. I've been looking forward to this chat for a while. So thanks, I appreciate it.

Danny: Mainly because it's us, right?

Lauren: Sure.

Ian: Yeah, of course.

Danny: [laughs]

Lauren: I mean, student-teacher dynamic. I love that we get to play into that today.

Ian: For sure. I'll give you all the dirt on Danny.

Danny: [laughs]

Lauren: Exactly. Thank you for...yeah, I mean, that's the goal for me. That's what I'm here for. [laughs]

Danny: Please, Ian, give us an introduction. We've always been starting with tell us a little bit about yourself because that's the most amazing question to hear in the interview process. But who are you? Who is Ian Douglas?

Lauren: [laughs] Maybe your background?

Ian: I was born at a young age. So I'm originally from Canada. I grew up in Canada and, went to high school and college around The Great Lakes, lived in Ottawa for a couple of years. And I started out in a little town that was literally 1000 People, moved to a town that was like 100,000 people, moved to a city of like a million people. I'm like, this is too many people. I can't handle this many people.

Danny: [laughs]

Ian: So, of course, I moved to Los Angeles, which is just a ridiculous amount of people. And within six months, I'm like, I hate California. I'm moving back to Canada. And that was right around early 2001 when the first .com bust happened. But I ended up in a job at a startup where we were processing credit reports. And our business went through the roof as everybody else's businesses were collapsing because people were buying houses with stock options that were suddenly worthless.

And so our business took off as everybody had to refinance house loans and car loans and everything else. So I'm like, I guess I got job security. I'll stay in California for a while. I met a fantastic young lady who ended up becoming my wife, and we started having kids. And it's like, I guess I'm going to stay in the States for a while. So I got my citizenship. And yeah, I've been here ever since. It's been great.

Lauren: I love it. I'm so curious to learn about how you navigated the switch from being a software engineer in that space to teaching. Tell us about that, how you navigated that, I guess.

Ian: I think at a certain point as a software developer, as you gain the ranks within a company and become a senior level developer, you're really leaned on not just hey, can you write better code? But also, how do you mentor the other people around you to level them up to where you are?

And so one thing that I learned is becoming a software teacher just having experience doesn't make you a good teacher. You still have to know how to teach people. You still have to know how to mentor people and how to make it engaging for them. When you're working with someone on your team, and you're doing something like pair programming, it's easy to stay engaged one on one because you're like, this is how I do the thing. This is my process. You get into kind of that driver and navigator kind of workflow.

But when you're getting into a classroom environment where suddenly I've got to teach 30 people or more, it's a lot different story of how do I keep everybody engaged? Because everybody's got different skill levels. Some people are coming into a coding bootcamp where they've got a little bit of experience, and some people have never touched a computer before. And how do you keep all of those people working on things where one group of people is not zoning out because you're way too advanced or another group is not zoning out because they feel like you're condescending your knowledge to cater to the people that need to get caught up? How do you differentiate those?

And so there was actually quite a lot of learning curve for me to become a teacher. My first six months at the Turing School of Software & Design were actually pretty rough around, like, I'm coming in, and I'm so excited to be their teacher.

Danny: Same here, actually. [laughter]

Ian: Of the seven-month program, six months were rough for you?

Danny: For six months, I was like, wow, this is not going well. [laughter]

Ian: And then the last month, I'm like, "Danny, you're graduating." He's like, "Phew."

Danny: Yeah. I was like, wow, weird.

Lauren: I've made it.

Ian: But yeah, I think getting to that point as a senior developer where you're mentoring other people around you and then moving into a management role where you have to learn to find joy in the success of others I think helped prepare me to be a teacher of now I've got this classroom of students and just being super excited about oh, they get the thing. They're going to go do something awesome with that.

And so that really led well into a developer relations kind of role or developer advocacy kind of role where now you get to teach things on a much larger scale and much bigger audience, perhaps global impact, where you can share some kind of idea. And you watch those light bulbs go off and go, oh, they're going to go do something really cool with that. And so to get to work at a company like Postman, where we got 17,18 million users or something like that on the platform now, is pretty fantastic because the tool is well-known, and I actually taught it at Turing.

Lauren: That's cool.

Ian: It felt like a bit of a cheat code going through their job interview process where it's like, "Tell us about yourself." I'm like, "Well, here's a video of me teaching your product to students. I taught API design." And they're like, "Would you like a job here?" I'm like, "Yes, I would."

Danny: Immediately, they're like, "We'll take you."

Lauren: Yes, please. [laughs] That's so cool.

Danny: Yeah. Was there a part of your life where you were like, okay, you know what? I just want to be a teacher now. You had been teaching as a senior software developer and had been doing that mentorship within a company. But was there a certain point in your life where you were like, maybe I just want to take a step away from working within companies and just focus more primarily on students?

Ian: That's a great question. I think I got to a point where I had been in the industry for so long, and I had been in management and been back as a contributor and was dabbling with getting back into full-time management again. Then someone that I worked with at SendGrid reached out one day, and they're like, "Hey, you like running these meetups, and you like helping people, and you like making sure other people around you can learn and grow. There's this coding school down the road called Turing. You should go talk to them about being a mentor."

And I think that's really where I picked up from an external point of view of like now, and I'm not just doing it within a company, but now I'm impacting other people. My dad was a college professor for a little while.

Lauren: Oh, get out.

Ian: Yeah, he actually taught industrial woodworking. And my mom was always big into helping teach people things. And so I had a lot of good influence just within my family around help other people out in some way. And it was usually behind the scenes like, didn't want a lot of spotlight. And so just learning that humble nature of like, I'm just here to help. I'm not doing this for recognition, prestige, anything like that. I'm just here to help people. And so that really rubbed off on me.

And that's something that I've still held to very closely today where it's like, I got this website techinterview.guide, and I do live streaming around that, around interview prep, and how to get into the job industry. And it's like, I don't do this to make money. I'm not doing this to be world-famous. I'm not expecting thousands of followers or anything like that. I don't monetize anything I do. I'm just here to help people. And honestly, just hearing stories of like, "Hey, I followed some of your advice, and I got a job." It's like, that's all I need to hear, right?

Danny: Yeah.

Lauren: Oh my gosh, it's the best feeling. But I also think that that's what establishes trust, and it allows people to feel like that they can really learn from you. And it's this authentic relationship that people can build. And, as you mentioned, with Postman, you're impacting so many developers now versus in a classroom. I can certainly relate to that as a prior teacher. It's like, okay, I have my 30 students in this space, and that one-to-one is so impactful. But now, this one-to-many relationship that you have going you could have massive ripple effect and in a positive way, which just feels really exciting. So I'm stoked for you.

Ian: I would often tell the students at Turing it’s like, the chances that I'm going to go invent something that changes the world are super tiny, but I can change the world by changing your world. Like, I taught Danny, and so now I get to watch Danny impact his world and the realm around him and watch the ripple effect of that and know that I had a small piece in that and all of the waves that happened because of Danny and what Danny is doing. It's like, I helped that a tiny bit. It's a team effort. It takes a village.

Danny: I can tell you right now, you definitely got me my job. You were obviously my instructor for Mod 3? Was it Mod 3?

Ian: Yeah.

Lauren: What does that mean as a non-Turing listener?

Danny: So the seven months are broken up into Four Mods, and each mod is five weeks, if I'm remembering correctly.

Ian: Each module was six weeks, and then there was usually a week or two in between, usually one week in between.

Danny: Where you would cry and rest.

Ian: [laughs]

Danny: Well, actually, no, less crying. You would just look outside. You would go outside and see sunlight for once, and you'd be like oh --

Ian: Catch up on your laundry. Remind your family what you look like. [laughter]

Danny: Maybe try to get a haircut. I don't know and then --

Ian: Find some new music that we can play on your birthday, you know? [laughs]

Danny: Yeah. Oh my gosh. That was so fun. Lauren, just inside story, Lovisa was very active in Turing Slack. So she had reached out to Ian, and there was a song I was obsessed with that I would listen to all the time that's a Cumbia song. It was my birthday, and Louisa had reached out to Ian and got someone else within the Mod. I think maybe it was Madeleine to photoshop pictures of me, and everyone made it their background.

Lauren: Oh my gosh.

Danny: And then Ian played the song in the morning, and everyone's saying, "Happy birthday to me."

Lauren: Aww.

Danny: It was really great and then in the middle --

Lauren: Is that our call to action is that everyone listens to that song? [laughter] Can we put a link to it in the show notes?

Danny: It's El Dipy.I guess I got to find out what it's actually called. I can't remember.

Lauren: Okay, we'll put it in. I love it. That's so sweet.

Danny: Yeah, it was very sweet. In the middle of COVID and everything, that was so special.

Lauren: Yeah, when you're feeling isolated, that feels really good. I don't know; I think coding bootcamps that can establish, yeah, that sense of community during it that's an indicator of a powerful cohort. And just that support is so necessary when you're in that. It can be tough, yeah.

Danny: Was it difficult to leave Turing, Ian? Or were you just like, this is my time I got to go?

Ian: Oh, that's a good question. It was -- [laughs]

Lauren: That's a tough question.

Danny: Turing is so strong. The community there it's like --

Ian: The community is huge.

Danny: It's huge.

Ian: It was tough going remote, to be honest. I had a hard time going remote. I really thrived on that classroom energy of just being in the room with people, not because I'm at the front of the room talking and people are paying attention to me. It was never about that. But it was just you get to really engage with the people in the room.

And you can spot the person that's maybe having that off day. And while you're taking a break, you can reach out to them and be like, "Hey, I noticed..." you're like, "What's going on?" And just have more of that one on one connection. As soon as we went remote, we kind of lost that. There's nothing impromptu anymore around, "Hey, let's just have a quick chat." We got to schedule everything, like, hey, let's get on Zoom, or let's get on Google Meet or whatever and have a meeting. And now it's like, oh no, my instructor wants to meet with me. What happened?

Danny: [laughs]

Ian: And it's like, "No, I just want to check in with you, see how you're doing kind of thing." And so that actually became really hard. And when Turing announced, like, hey, we're going to stay remote 100, that was when I started thinking like ah, I really wanted to be back in person someday. And so that that got me thinking a little bit about do I want to stay teaching remote? And yes, I did want to keep teaching.

And there were also, like; I had my own ambitions about I want to teach deeper engineering principles. I want to get more into scalability and security and deeper API design things like that. And Turing just wasn't the place for that. It's meant to be a beginner-level school, and it's meant to teach the basics and get you out into the job. I was happy to play that role and play that part, but I wanted to go deeper. I realized that to have that opportunity; I was going to have to kind of pursue something else instead. And so it was a tough choice, for sure.

Danny: Was the techinterview.guide was that always...because I don't remember that when I was at Turing. Did leaving Turing inspire you to create that website?

Ian: So the content of that I had actually had around since I started mentoring at Turing. So I started mentoring there in 2014, and within a month of like, hey, come be a mentor to our students on the back-end program and teach them about Rails and APIs and things like that, it quickly became like, hey, do any of our mentors know anything about resumes and tech interviews? And I'm like, yeah, I've been a manager. I've looked over tons of resumes and know all about interviews.

Lauren: Let me help. [laughs] Cool.

Ian: Yeah, and so I became the resume guy for a while. And then I realized, okay, well, that's what students were coming to me for is like, how do I get a job? What kind of advice do I have? Can we talk about negotiations? And so I started running just evening classes on this is what the tech interview process is going to be like. This is what you're going to face. This is what you should be studying. This is the general sort of what the interview flow is going to feel like, and here's how you can navigate each part. And I wanted that to be more scalable.

And so I started writing it out as a whole bunch of Google Docs. And it turns out when you give somebody like a 50-page Google Doc, that can be a little overwhelming for them to go find specific information. But I was basically compiling FAQs and stuff and just building up this big document. So while I was at Turing, now I got to teach it live, which helped with the scalability to some degree. But I'd say about halfway through my time, at Turing, I actually started building it as a website.

I thought about actually publishing it as a book, and then I'm like, well, but then as soon as you publish it and it goes on the shelf, it starts to become out of date because things are just constantly changing in tech. And so, I wanted some way of putting it online where I could continually update the content and get feedback and continue to learn and grow myself in the tech industry and what's going on.

And I just went through a job hunt to get this job at Postman, so being able to kind of relay more modern kind of stuff. I wanted a way to update it, and so I built it as a website. I went through a couple of different domain names and then decided on techinterview.guide. I've got a little changelog on there so people can go in and see when I'm updating content or adding new content and things like that.

And then, when I left Turing, I realized I still really like the idea of teaching and sharing that knowledge. And verbally, I can get a lot more content out there. And so I started with live streaming. And Jonan Scheffler from New Relic was really instrumental in getting me set up with that and helping with audio, and how not to do it on a Mac. [laughter] My poor little MacBook at the time sounded like a jet engine wanting to take off every time I tried to stream. [laughter]

So he helped me navigate into a Windows system and get all that stuff set up. And so, I really appreciate Jonan's time to help me out with that. And now I do that twice a week. And just this last session I did...so I stream on Sundays and Thursdays. I'm like, all right, I'm going to keep it to 90 minutes. It’s like, over two hours later, [laughter] I'm like, I guess I'll wrap up for the night.

Because there's such good engagement in chat, people coming by, and they're like, "Well, what about this scenario? What about that scenario?" And just getting to share my thoughts and perspectives has been really helpful. But I also love having people on the stream. They can share their perspectives, especially those that don't agree with the same thing that I say on the stream.

Danny: Like a healthy debate or something.

Ian: Yeah, and it's really helpful for people. And the number one thing I tell people is don't ever just listen to my advice. You have to listen to advice from lots of people in order to gain the perspectives to make decisions on this is how I'm going to approach things. So don't ever just listen to my advice on how to build a resume. If I'm hiring for a job and you're sending me the resume, then yeah, by all means, follow my advice on building a resume. But how I build a resume is not how Lauren is going to build a resume. It's not how Danny is going to resume.

Lauren: 100%

Ian: And everybody's going to look at and go, "Oh, you should do this differently. You should do that differently. Everyone's going to have an opinion." And you have to listen to a lot of those opinions in order to form your own and say, "This is how I'm going to build my resume and go forward from there."

Lauren: Build out like a board of people that you can go to to get that feedback from and then know that not one is more important than the other but just collect it all and then see what fits for you. Also, total side note, Danny, are you having massive imposter syndrome right now that Ian should be hosting this podcast in general?

Danny: [laughs]

Lauren: Because I think he should [laughter]. I mean, the techinterview.guide, we’ll, of course, include that resource in the show notes and your Twitch stream as well so that folks can come and listen in on those nuanced debates. I think that's a really important thing to shout out. I'm curious, actually, what are the hot topics in the world of interviewing that people are getting polarized over these days? Is it like on the whiteboard interview? Is it that sort of stuff?

Ian: To some degree. Some people are like, oh yeah, LeetCode is fine. Go grind on LeetCode.

Lauren: Got it. Got it. Got it.

Ian: And a big proponent of LeetCode needs to burn in fire.

Lauren: Hell yeah. [laughter] Bye.

Ian: But also, how do you put a resume together? How do you negotiate on things? And why do companies hire junior devs or not hire junior devs? How do we change their minds? I just ran a great panel last week on why companies don't hire junior devs and how they need to. They need to get them shaped and molded up because as other people leave the company and take that domain knowledge with them, you got to fill that gap with somebody. And there's a finite number of senior-level devs. And if we don't train up the juniors, there's going to be no senior devs, right. So it was a really good panel on that.

But I had a guy on my stream a couple of weeks back named Jerome Hardaway from Vets Who Code. And he and I didn't agree on everything that we were talking about. It's like, someone would raise a question, and we'd have different answers. And we'd both say, "Hey, it's okay for us to disagree here. It's totally all right that we have opposing views." That's why I have people like that on my show, not show, on my stream just to show you can have healthy debate. You can have disagreements and not be really hateful toward each other or whatever. We can have friendly conversation and disagree. And it's okay.

Lauren: I love that. We should do a quick shout-out. If you're a veteran or have served at some point and are interested in learning to code, Jerome has an incredible community, Vets Who Code, so we'll put that also in the show notes.

Danny: And you said that you stream on Thursdays and Sundays, you said. Is that on Twitch? Or I've seen you be on LinkedIn recently?

Ian: Yeah. So I started streaming on multiple platforms. So I stream primarily on Twitch. But I started in February I started...or actually in January, I started streaming on LinkedIn and Facebook simultaneously. And so it actually goes out to all three platforms partly just to try it out to see what it's like to stream to multiple platforms but also just to reach more people. And so, I don't get a lot of engagement on Facebook right now. But I've started getting a little more traction on LinkedIn. So my idea is I'm just here to help people. But I don't necessarily need them to come to me. I want to go where they are.

Lauren: Exist where they exist online.

Ian: Yeah. And so, just this week, I've started looking into Twitter Space because that seems to be a really popular spot for just going and giving advice. And it's more audio content like we're doing here.

Lauren: For sure.

Ian: Where it doesn't have to be a visual where you see all my blinky flashy lights in the background and stuff like that.

Lauren: We love those. [laughter]

Ian: But I mean, the blinky flashy lights are fun. You can write Python, and you could like --

Lauren: Oh my gosh.

Danny: Whoa. [laughs]

Lauren: Dear listener, he just turned on really fun lights in the background that were very eye-capturing. Oh, thank you. That was fun.

Ian: Having that kind of stuff on the live stream is really fun for engagement, but I want to go where the people are. And I just want to be there and offer my ideas and perspectives. So whether that's joining someone else's Twitter Space, or hosting my own, or going to LinkedIn, or Facebook, or wherever people are hanging out, wherever the kids are these days, that's where I want to be [laughter] and just be there to offer support and offer advice.

Not that I just want to be like another white guy in tech muscling in to shove my opinion in anybody's face. That's not why I'm doing it. I'm genuinely here to help people out. And I really appreciate the diversity of the folks that have agreed to be on my stream just to hear their stories and hear about their journeys and things like that. A little shout out to both of you; you're going to be on my stream in a couple of weeks. So I'm looking forward to that.

But just having differing perspectives and differing viewpoints and hearing other people's journeys, I think, is a lot of what helps the most when it comes to how do we get through this scary job interview navigating all the stuff and juggling all the things? I think it's important just to show people that you're not alone in this. It's a hard struggle, especially for that first job in tech. And there are people out there that want to help you.

Lauren: Absolutely. Yeah, the community is everything, and you just got to find your people. And we want to help. [laughs]

Ian: For sure.

Lauren: No, I think that's awesome. And I'm so excited that you're a resource for our listeners because, as you said, it is really scary. And I think the more that we acknowledge that and empathize with folks, it's just a reminder for everyone listening that we're going to get through this. You're going to get this job. We are going to figure this out.

Danny: Oh yeah, like an example of being scared little young Danny when I was in school...Ian, if you remember this, I scheduled a time with you. You were like, "Hey, I'm just hanging out in Zoom if anyone wants to come hang out," and I was like, "Okay, I'm going to ask Ian some questions." And I logged in, and it was just you and me. And I think you were just eating seeds or something. You had just kicked back, sitting back and just eating seeds, just chilling. [laughs]

Ian: I always have a giant bag of sunflower seeds on my desk. It's a horrible habit.

Danny: Ian just picked up a giant bag of seeds, everyone.

Lauren: And this is what Danny loves to do is paint the picture for the listener so that we can be there while he's storytelling.

Ian: For sure.

Danny: Oh wow. I've been complaining about how bad my memory is. And I just literally remembered exactly what Ian looked like.

Lauren: Unlocked. [laughs]

Danny: Yeah, unlocked a core memory. And I was like, "I think I really want to get into DevRel." And you're just eating your seeds. You're like, "Hmm." And you just sat there for a moment. And you're like, "DevRel is kind of a hot topic right now. Yeah, there are some new people going in." And then you're like, "There are some young people, but usually it's people who have a lot of experience."

And I was like, "So do you think I could go in as a junior?" And you're like, "Hmm, you probably could. You probably could. It's going to be really hard, but it's possible." And I was like, "Okay, cool. Do you think I should do that?" And you're like, "Yeah, just whatever makes you happy, man." [laughter]

And I was like, "Okay, okay. Yeah, I think I'm going to do that." You're like, okay, "It's going to be hard, but yeah, I think you could do it. Just find a company you like and just get to know their software." And I was like, "Okay, cool. Well, I need to still learn how to code, but I'll do that."

Lauren: [laughs]

Danny: And you're like, "All right, sweet." And then that was that. And I remember thinking, and I was like, okay, I just needed to hear one person tell me.

Lauren: Encourage.

Danny: Yeah, just be like, yeah, you could do it. It's a lot different than what we were focusing on at Turing. The interview was so, so different. It was so different.

Ian: Absolutely.

Danny: But it was luckily something that involved a lot of things that I had previous experience there. But yeah, I guess my question to you is just when you get people who come to you for that seems a little bit out of their realm or comfort zone, do you have any immediate words of wisdom that you could provide? For you, you're like, well, just be aware that this might be out of your skillset. This might be out of your skill level or your knowledge. But just focus on what you want and what they're looking for. Is there anything else that you try to suggest?

Ian: That's really the heart of it. When they get into that interview, and they say, "Tell me about yourself," or "Why do you want this job?" or "Why should we hire you?" They're really all asking the exact same thing. They're asking you to explain how your background and your skillset is going to make them better. What are you bringing to the team? That's really what they're asking. And the subtext of that is and convince us to hire you as part of that.

Lauren: [laughs]

Ian: And so when I was having a chat with you, it's like, okay, well, what is it about your background that's going to help in developer relations? Like, yes, you're learning how to code. That's going to be an important part of the job. But the fact that you did stand up and you're used to being up in front of people, and just being vulnerable, and knowing your jokes may kill, they may bomb.

Danny: [laughs] Yeah.

Ian: And being okay with that. Like, just get up there and be yourself. And I think that that can really play a big part as far as that authenticity and just being genuine. That buys you a lot of credibility in developer relations, in developer advocacy of just knowing like, hey, I'm human. I'm going through this too. I may not have all the answers, but I'm going to help you find them. And so it's really about how do you talk about your background and your experience in a way that shows the company the value that you bring to them?

Lauren: Yes, yes. How do you spin it so that they see it as an asset versus a detriment and that they are stoked to have you on the team? And that you're going to be diversifying whether it's how you approach a problem that the team is trying to solve with the software? Just that new perspective of like, hey, I know you all with your CS degrees may be looking at it from this lens. Have we considered from this perspective?

And being a stand-up comedian would allow you for that unique POV, if you will. And just really owning that in the interview, I think, is awesome advice because companies are wanting that. We just also have to help make sense of it because it's a little different than what they're traditionally seeing when they're doing these interviews, I guess.

Ian: Yeah, for sure.

Lauren: I'm curious because, Ian, I know you've done a bunch of interviews recently. What are trends that you're seeing? A key demo for who we want to really connect with for this show are folks that are in the interview process or wanting to level up and get skills and tips and tricks when they're about to go into the tech interview. Are there things that you can share with our listeners after having gone through all of this yourself?

Ian: Yeah. My number one tip is really showing them the value that you bring. Whether you're communicating it verbally or putting a resume together, you need to just be quick and concise and to the point. Don't beat around the bush. Don't add a lot of fluff. Just get down to it. Companies really want the hiring process to be over. It's a long-drawn-out process. It's expensive to hire people. Don't spend more time than you need to. Just get to the point.

So I usually tell people build a resume with everything on it, put every project, every skill, every library or framework, or whatever you've ever used. Just make it a massive resume. Give me lots of bullet points about your job. But when you go apply for a job, go reduce that down to one page by trimming out everything that that company doesn't care about for that role.

And it goes back to a riddle that I learned as a kid of how do you make a sculpture of an elephant? You start with a giant block of stone, and you chip away everything that doesn't look like an elephant. And you want to do the same thing with your resume. You want to start with a really big resume and then trim away everything that doesn't make you look like the best candidate for that job at that company. So trim out the languages they don't ask for, trim out the libraries they don't care about.

If you need to fill up room on the page later, you can fill in that other stuff. But you want to start with just the minimum of like, this is what I bring as value to this company for that role. And then again, when they say, "Tell me about yourself," you want to do the same thing. You want to tell them, "This is me in a nutshell. This is the value that I bring to the company." And don't highlight what you don't know. Don't highlight that you're new at this, don't. Don't level yourself. Let them level you.

Lauren: Don't give them that self-deprecation, exactly.

Ian: Yeah, don't do that for them. Let them figure that out as part of the interview process. And then just be your authentic self. Just bring your best self to that. And it does come down to practice. And so I often tell people if you're doing mock interviews, that can be fantastic, but make sure you're doing mock interviews with people that can give you valuable feedback.

Doing a mock interview with a parent or a roommate or something like that that can be fine. But it'll be better if they're in the tech industry, and they can actually tell you what was good or not good about specific answers. And so finding somebody that you can mock interview with that's actually going to make you better at interviewing is the way that you get better at interviewing.

You can also just go do interviews to practice interviews, not that I really recommend like, oh yeah, just go find some company and get their hopes up and interview you and think that they're going to hire you. But it is the best way to actually practice interviewing is to go do a real interview and see what companies are asking and things like that.

So when it comes to trending, yeah, the LeetCode problems are not going away anytime soon. I really wish they would, or at the very least, I wish companies would pick LeetCode problems that are at least on par with what they do as a business.

Lauren: Applicable to what you would be doing or to simulate that a bit. Gosh, retweet totally.

Ian: Yeah, some of the best interviews that I did over the month of December and January were very in line with this is what you're going to do on a day-to-day job. Go use whatever language, whatever library you want. Go pull this API and go build some stats on the data that you get back or something like that because that's what you're going to do day-to-day. As opposed to oh, go build this recursive depth-first search backtracking algorithm. It's like, but you don't do anything like that here at this job. Why do I need to know this?

And I get it. The company needs to see you demonstrate your skill, but I think that there are better ways of doing it. And I think that companies need to do a better job at how they present those kinds of technical challenges and how to get you to demonstrate your skill that is more indicative of the day-to-day job.

Lauren: Yeah. Google, are you listening? [laughter]

Ian: All the FAANG companies?

Lauren: Yeah, all of them. I guess I'm thinking of my Google interview where I passed out because we were traversing a tree, and I couldn't. [laughs]

Danny: You actually passed out?

Lauren: That's a story for another day. [laughter]

Danny: Oh no.

Ian: I want to be there for that story.

Danny: Yeah, that's actually another call to action. Right the ending of that story, everyone, please. [laughter]

Lauren: There is a resource that you unlocked memory-wise for me that I just Googled while you were speaking about it; it's on Pramp. Did either of you ever use that? It's you get peer matched with…some of it is you self-select what level of interview you're doing. And then they send you each a question, and you can become a bit of an expert on it. And then you ask each other it. It's like you're paired for maybe an hour or so.

Danny: Oh, cool.

Lauren: And I really loved stuff like that because it gave me that human-to-human interaction. And you could also then talk through how to approach this problem. And they're strangers on the internet, but I think they do a pretty good job of protecting you, I think. That was an interesting resource when I was navigating that particular...mock interviews it's a muscle you have to learn to flex, and yeah, you just got to do it a lot.

Ian: Yeah, Pramp is a good platform. The downside of Pramp is you don't know who you're getting paired up with. And so you don't know the quality of the feedback that you're going to get. So it's better than nothing. It's better than just grinding on LeetCode by yourself because you're not going to get feedback. So it's better than nothing.

There's another resource that I'll shout out called hackerpen.io. And it's an up-and-coming mock interview platform where you can actually sign up as a mock interviewer. And you can set up a calendar of, like, letting other people sort of book your time as a mock interviewer.

And then interviewing.io, where, for transparency, I'm a paid interviewer on their platform, but you know the quality of the feedback you're going to get from them because you're paying for it. And they're getting actual industry experts and industry interviewers to actually give you a mock interview. And they're going to give you quality feedback. And you can also book like FAANG-level. Like, I want to get a job at Google so you can book an interview with somebody at Google kind of thing so that you get Google-level feedback.

Lauren: That's cool. I was just feeling nervous that...because it's great advice of make sure you're doing these mock interviews with folks that can give you the real feedback and resources. And I was feeling nervous that a listener might feel like I don't know anyone like that. Because I was in that camp that was...at my bootcamp, they called me technically unadjacent, meaning I didn't have anyone in my world that was a software engineer that I could go home and ask questions to at night.

Or I was always just really envious of the people that had partners sitting nearby them in the evening when we were doing our homework that we could say, "I don't get this. Can you help explain this concept to me?" [laughter] So you know what, Danny? You would have been my nemesis. I would have been like, oh--

Danny: I had straight up just like a cheat code the entire time. There would be times when Lovisa would be like, "Go ask someone in your class." [laughter] And I was like --

Lauren: Because it is a good practice to get help from other people too, right?

Ian: True.

Lauren: But I think I realized, too, that all of us are available as resources for people if they wanted, and you just provided some great other ones. So we'll link all of that. But yeah, reach out, folks. That particular part is really, really hard to get even the courage to do the mock interview, I think. And so let us be a resource for it, and let's do that together. Because I hear you, it's scary.

Ian: Yeah, it is hard to ask questions too. And one thing I really encourage on my live stream is people can reach out to me to ask anonymously. You can DM me on Twitter. You can DM me on LinkedIn. So you don't have to be on Twitch and put your name next to that question where you're feeling particularly vulnerable.

Lauren: Oh, I love that.

Danny: That's cool.

Ian: So I really encourage people; if you want to ask anonymously, I will give you a means to do so. And I've actually had a number of questions come in that way that I get to address on the stream and be like, "Hey, by the way, I got this anonymous question that I want to address." And that way, they know they're getting an answer, but they don't have to be as vulnerable. They had to be vulnerable in the first place to ask the question. But hopefully, I've built up enough credibility and trust that they know that if they ask anonymously, I'm not going to say, "Hey, Danny sent me this DM on LinkedIn with this dumb question."

Lauren: He doesn't know how to do this. [laughs]

Ian: They know that I'm not going to do that because I genuinely care about helping them out. And so it's like just trying to find as many avenues as possible to let people ask a question to where it helps their comfort level and know that they're going to get an answer.

Lauren: I mean, just gold star of a human all around, Ian, geez.

Ian: Thanks.

Danny: Gold star. Gold star. I already knew you had gold stars but more gold stars. Is there a common theme regarding these questions that people struggle to ask or just want to ask more anonymously? Have you noticed any type of questions that come up again and again, again?

Ian: Not in an anonymous level, no. I would say the biggest trend that I see in the live stream is just how do I get that first job in tech? How do I stand out? How do I differentiate myself from hundreds or thousands of other entry-level devs trying to apply for that job? And a lot of that comes down to networking, and being discoverable, and finding a way to set yourself apart, that's meaningful to that company. And again, it comes down to showing them your value.

And so I often tell people if there's a company that you're interested in and they have an API, or a library, or framework, or a product, find some way of using that in a project. And then, if you can network with them over time, when you reach out, you can say, "Hey, I'm not just some random person with technical skills. I'm actually a user of your platform. And this is why I love the platform. And this is why I want a job there, please."

It completely changes that introduction from just some random person with technical skills to oh, this is actually a customer of ours that wants to come work here. It makes a big, big difference to the company to know that you're that passionate about it, that you want to be a part of the team to help with that experience for others.

So if they've got any kind of tooling, library, API, anything like that, go build some kind of project about it. It's not going to be like, go spend an afternoon, and then they're going to hire you. It'll have to be something that you build over time. But it makes a big, big difference when you can apply there and say, "Hey, I've been a user of your product for a long time," or "I've been getting to know people on the support team through asking them questions," or "I've been contributing GitHub issues," or something like that. It makes a huge difference when they know your name.

Lauren: Oh, absolutely. Or to see that you've opened pull requests. Like, oh, I recognize this person from GitHub. And it's the same example you gave for Postman. Like, oh, yeah. Hi, y'all, want to see a video of me being wildly enthusiastic about your tool and teaching other people on it? [laughter] I just think that passion can really help you stand apart from other applicants. I appreciate that advice for sure. Wow, this has been such a joy, Ian. Thank you so much.

Danny: I was going to ask one more thing.

Lauren: I know. Go ahead. Go ahead.

Danny: All right. Okay, sorry. [laughs] Ian, please tell us...because I love the story, hearing about it all the time. Tell us about working for Mitch Hedberg.

Ian: [laughs]

Lauren: So related completely. [laughter]

Danny: Completely off track. This is just for me, everyone. You can log off.

Ian: It's all good.

Danny: I'm @muydanny,@lolocoding, and iandouglas736 on Twitter.

Lauren: Stop. Stop. Stop. Stop it. [laughter]

Lauren: The show is not done. There's more.

Ian: So after Mitch Hedberg died, I was a fan of his, and I just went to his tribute website just to kind of pay respect as a fan. I actually got to see him live in Southern California. At the end of the show, I'm walking down the hallway, and he's standing right there, and I'm like a total fanboy. And I was like, "Hey, great show." And I just kept walking. I wish I'd stopped and got an autograph or something.

After he passed away, I went to his fansite. And it was a PHP-based forum, and it was just littered with spam. And so I reached out to the person running the website and said, "Hey, I'm a developer. I work in PHP. I know this forum's software. Can I help clean up the spam and put a little spam bot detector kind of thing in place?" And they're like, "Oh my gosh, that would be amazing."

Well, next thing I know, Mitch Hedberg's wife, Lynn Shawcroft, reaches out to me via email to give me access and permissions and get me in touch with the sysadmin actually running the site. So yeah, I just got to stay in touch with Lynn and then just working on the site doing some site updates.

And they came out with an album after the fact. I think it was Do You Believe in Gosh? album, just working on the website with that. And she reached out, and she's like, "Hey, we're going to do an album release party. Do you want a couple of tickets?" I'm like, "I would love tickets."

Danny: [laughs]

Ian: So I'm sitting at this table. I brought a bunch of friends. And while I'm sitting there, I have to rotate 90 degrees to look at the stage to my left and 90 degrees to my right at the other end of the table. This elderly couple sits down with Lynn. And I'm like, "Oh, hey, Lynn, what's going on?" Well, turns out it was Mitch Hedberg's parents.

They had traveled to Los Angeles to attend this release show where it was like, Tig Notaro and Chris Porter, and I want to say Norm Macdonald was there. A ton of people showed up to pay tribute to Mitch. And I got to meet Mitch Hedberg's parents. And over the course of getting to know them, we had our first kid. And Mitch's moms sent us a care package of onesies and like all kinds of stuff for our kid.

Danny: [laughs] What?

Ian: And I'm like, what? This is amazing. So yeah, it was really fantastic to work on the site.

Danny: That's so cool. And I think there's something to be learned here is that go to comedians’ websites because they don't know how to update their website and offer to work on it, learn something. And then when they become famous, you will be their right-hand person.

Ian: The subtext of this is Danny is looking for somebody to maintain his website. [laughs]

Lauren: I was like, is this a call to action for Danny?

Danny: The call to action is DM me. I need someone to work on my website.

Lauren: Should we look at his website? [laughter] Do you have some URL like dannyramoscomedian?

Danny: Spam. It's full of spam. It's just spam.com [laughs]

Ian: Hey, Danny. What's the difference between a well-dressed man on a unicycle and a poorly dressed man on a bicycle?

Danny: I don't know.

Ian: A tire. [laughter]

Danny: You heard it in the beginning. Ian does love dad jokes.

Lauren: Did we count that as a dad joke? [laughs]

Danny: Oh, well, Ian is a dad. And that was a good one. [laughs]

Ian: You know when a joke becomes a dad joke, right?

Danny: When?

Ian: When it's apparent. [laughter]

Lauren: Okay, I like it. I like it.

Danny: Well, I think that's it. I think that is--

Lauren: We end with that.

Danny: That's our show, the big punchline at the end. [laughs]

Lauren: I mean, genuinely, Ian, what a perfect person to have come share their experiences and their insights. And I think it's so neat that you will continue to be a resource in the future for our listeners as well. So I'm excited to equip them with you [laughs] and all the things that you're creating that exist out there on the internet.

Danny: Even if they have to put up with my bad jokes, right?

Lauren: Yeah.

Danny: [laughs] Trust me, everyone. Ian is such a great resource. And I just want to tell you, thank you so much, Ian. I have a job because of you, and like you were saying, the impact that you have just for teaching students this is one example. And I'm sure there are hundreds and hundreds of other examples. But I just wanted to tell you I really appreciate you and thank you for --

Ian: Oh, thanks. I appreciate that.

Danny: Dealing with me as a student. [laughter] We didn't get into our time at Turing.

Ian: You weren't that bad as a student.

Danny: No, I was pretty chill. I just would ask questions. [laughs]

Lauren: That makes for a good student.

Ian: It does. It does. And honestly, to segue back into the live stream, it's the same way like having people show up and ask questions helps people that want to show up and want to ask a question, but they're scared to, or they don't know how to ask, how to frame the question. Having other people come by and ask questions shows them like, hey, I can ask questions too. And so I love having people come by, and the chat just blows up with question after question after question.

Lauren: That's so great.

Ian: I've got this huge backlog of questions that people submit privately that I don't even get to on the stream because people show up in chat, and it's full of people that I want to help out. So I do have to be better about my time management on the stream for sure. But it's so fun just getting to share my perspectives and ideas and stuff like that.

Lauren: Oh, I love it. I love it so much. Well, I suppose then listeners will see you on a future Ian's Twitch stream. [laughs]

Danny: If people wanted to reach out to you, Ian, where would be the best places for that?

Ian: So I use the same username on Twitch, Twitter, and LinkedIn. And it's my name iandouglas736. So the 736 is just a shout-out to my wife. It's how we met online.

Danny: Aww.

Ian: And so I use that username as much as possible. I've also got a link tree under the same name where I link to the techinterview.guide website, a Discord server that I have where people can come in and ask questions and do resume reviews and things like that.

Lauren: Love it.

Ian: So yeah, you can reach out to me as iandouglas736. DM me anytime. I love taking questions and helping people out. And if I can't answer right away, know that it's going to get on the stream at some point for me to answer as a question. And any questions submitted to me that way is going to be kept anonymous. It won't have your name attached unless you want it to be. But yeah, I love just being available to help people.

Lauren: You're incredible. We are so lucky to be able to speak with you today. Thank you.

Ian: Well, thanks for having me.

Danny: Thanks, Ian. Appreciate you.

Ian: No problem. What do you call a beehive that has no exit?

Lauren: What?

Ian: Unbelievable. [laughter]

Danny: I hate that.

Lauren: Oh well. That was a wonderful conversation.

Danny: That was amazing.

Lauren: Holy cow.

Danny: I love that guy. I love him.

Lauren: I'm feeling emotions of love.

Danny: [laughs] I can't say it. But I don't know if I want to say it, but I feel --

Lauren: Well, I don't know. It's the IRL versus –

Danny: You've only met him online.

Lauren: Right. Have you also...he was your teacher. Oh, because you did your program.

Danny: Oh my God. I've never met him in person either. [laughs]

Lauren: Stop.

Danny: I spent every day with this guy, and I've never even seen him walk around.

Lauren: You've never even given him a hug.

Danny: No, you're right. But I knew he ate seeds. I knew he ate seeds. That was unreal, the giant gallon bag of seeds.

Lauren: Honestly, I missed it because I was cringing over the fact that you were telling the story again the way that you were, and so I --

Danny: I'm a storyteller.

Lauren: I think our audience is...here's the thing, I think they'll either love us, or they’ll hate us. We'll check the reviews this week, but keep your fingers crossed.

Danny: Seems like they hate us, but we have so many other schedules. We got to keep going. [laughter]

Lauren: We should be open to feedback. We'll check out the reviews, see where we can have some constructive criticism moments.

Danny: Absolutely. Absolutely.

Lauren: And learn and grow from them. But yeah, okay. Let's see. Thanks, everyone, again, for listening to another week, another episode of Launchies. Be sure to go give us a follow @newrelic over on Twitter to engage in the discourse there.

Danny: Yes. And be sure to follow us or join our New Relic community Slack at bit.ly/nrslack.

Lauren: Yeah, come have a chat, and we'll help you get started if you're feeling curious about all the tech that we have at New Relic. It could be kind of fun. I don't know, sounds enjoyable to me. I would love to have you there. That's where I spend a lot of my time, but yeah. And then our personal handles on the interwebs it's @muydanny. I'm @lolocoding. And Ian, as he said, is @iandouglas736, which we didn't get the story to. He said it's a tribute to his wife but --

Danny: Right. Is that 736 like an old chat room or something?

Lauren: I don't know what the 736 is.

Danny: We'll get that info and share it with the resources. [laughs]

Lauren: In the show notes? You want to put that in the show notes? [laughter]

Danny: Just a cute little story. By the way --

Lauren: It's like a deep, intimate story that he would never share. We'd blow up his spot. [laughter] Oh my gosh. But go give us a follow. Go say hi. Our DMs, all of us, are, as we've mentioned on the show, our DMs are open. And we want to be a resource. We want to help you on your journey of interviewing and applying, and finding your job in tech.

Danny: Yes, and if you're currently looking for a cool, fun conference to submit --

Lauren: Exciting.

Danny: Exciting, happy, nervous, [laughs] these are words we used. You can submit a CFP to FutureStack, which is currently open right now. And FutureStack is planned to be May 17th through the 19th, so submit that CFP.

Lauren: Yeah, in Vegas.

Danny: In Las Vegas.

Lauren: CFP is a call for papers just in case we're using an acronym that you don't know. It's when you submit a talk idea, and you get on stage, and you tell other developers about cool stuff that you do.

Danny: Actually, thank you for sharing that because I didn't know what CFP was for the longest time. And did we even mention a call to action?

Lauren: What's our CTA? [laughter]

Danny: Our CTA. We just speak in acronyms only.

Lauren: Shoot. That's funny. Write a sentence in acronyms. That's not the call to action. Do we have one?

Danny: I really liked the idea of when Ian said to have a...it might have been a combination of what Ian said and what you said to have a board of people that will give you feedback and have mock interviews. So I would say our call to action could be build that board of people, find three people in your network, friends that are also interested in tech, or people who are in tech now, and have them give you feedback or at least schedule one or two mock interviews and tell us how it went.

Lauren: Yeah, and tell us and tell us who your board is. I think it's always fun to give that kind of public appreciation to these people that are helping you navigate this space. And so I think it's important to pause and say thank you to people, and it was really cool to see you do that with Ian today also, by the way. That was really lovely to watch.

And I use my board personally. I know what each of them will help me with. So that is kind of my tip for the day. I know I can go to my friend when I have a specific question about negotiation. I know I can go to him and be like, "All right, how are we getting this offer to the next level? What do we do? How do we phrase that?"

And then I have another person in the Rolodex that I go to that is always, always my person that helps me tackle the cover letter and what are we particularly pulling from the job advert within the cover letter and resume? Because I think when you go and ask for help from people and from mentors specifically, it's important to have asks like their time box there. Can you help me with XYZ? Versus hey, can you help me? You know what I mean?

Danny: Yeah, actually, okay --

Lauren: It looks big. Yes. Oh my gosh, I just got pasta delivered to me in bed. I love being pregnant. [laughter]

AARON: I love you too. [laughter]

Danny: Aaron's like, oh okay.

Lauren: Thank you.

Lauren: I will not eat this while we are recording. But how delicious does that look?

Danny: I didn't see it at all. Oh, wow. That does look good. Dang.

Lauren: I know, no kidding.

Danny: Okay, Aaron. Wow.

Lauren: Okay, wait. Whatever, I think I made my point.

Danny: Asking for help.

Lauren: Specific. Yeah, being really, you know, it can be not overwhelming, but when someone's like, "Can you be my mentor?" Often we will say yes, but what does that really mean to you? Do you need help with the resume? Do you need help doing a mock interview? If you can really allocate that to people, it likens the chance that people will say yes to those requests. I don't know.

Danny: Exactly. Yeah. I totally agree. Yeah, so build that board of people, do some mock interviews, share who they are, thank them. Tell us how the mock interviews went. And yeah, just do that on Twitter or our community Slack or really, wherever you feel comfortable.

Lauren: In our reviews. I'm telling you, I think that that is the place. So give us those five stars and respond to the call to action there because that could just skyrocket; I mean, y'all realize that we have a boss that we have to report things to. [laughter]

Danny: Metrics.

Lauren: We exist in reality. Metrics.

Danny: Metrics.

Lauren: Help us keep this show going. That would be so helpful. We love you so much.

Danny: I got to feed my family.

Lauren: Help me; I'm poor.

Danny: [laughs]

Lauren: Whatever. We appreciate you all so much for listening, and thanks for being a part of this community.

Danny: Take it easy, everyone.

Lauren: Yeah, I'm going to go eat this pasta.

Minimum Viable Security – Start Small, Then Iterate with David Melamed

Mandy Moore — Wed, 09 Mar 2022 13:16:16 +0000

David Melamed is one of five co-founders and the CTO at Jit, the continuous security platform for developers. He was born in France and holds a Ph.D. in bioinformatics.

Professionally, he has been working for the past 20 years as a full-stack engineer, as a CTO, and as a technical evangelist mostly in cloud and, in particular, in cloud security. He is very curious and likes knowledge-sharing and empowering other people.

In this episode, David talks with host, Kirk Haines, about frictions between developers and security engineers because security is mostly an afterthought, the concept of minimum viable security (MVS), and really common things that people forget to think about when they are building their applications but that are very easy things to fix.

Links:

Jit (Twitter | LinkedIn | Facebook)
David Melamed: Twitter | LinkedIn | GitHub

Give us a follow: @PolyglotShow

Minimum Viable Security – Start Small, Then Iterate with David Melamed

Polyglot

Your browser does not support the audio element.

1x initializing... ×

Transcript:

Kirk Haines: Welcome to Polyglot. My name is Kirk Haines. You can find me @wyhaines on Twitter and pretty much anywhere else on the internet. And today, I'd like to welcome my guest, David Melamed.

David Melamed: Thank you, Kirk, for inviting me. So hi, everyone. I'm David Melamed. I'm one of the five co-founders and the CTO at Jit, the continuous security platform for developers. And a little bit about me maybe, I was born in France almost 44 years ago. I hold a Ph.D. in bioinformatics. I moved from France to Israel about 13 years ago, got married, and I have now four kids.

Professionally, I've been working for the past 20 years as a full-stack engineer, as a CTO, a technical evangelist mostly in cloud and, in particular, in cloud security for a couple of leading companies like MyHeritage, CloudLock, which was then acquired by Cisco where I led some strategical and technological project for the CTO office of the cloud security business unit. I'm usually very curious and like sharing my knowledge and also empower other people. And as part of this, I've been involved in a few local communities around Python and AWS throughout the last couple of years.

Kirk: Fantastic. Why don't we just start at the beginning? And we'll just work up to what you're doing right now and then talk a little bit about what you're doing right now. So you were born in France, and you have a Ph.D. in bioinformatics, correct?

David: Yes, exactly.

Kirk: How did you go from the Ph.D. in bioinformatics to working as a full-stack engineer? What was that transition like?

When I finished high school, I didn't know what to do. I was always very curious, so I didn't want to choose between different domains. And so I decided to do studies where I shouldn't have to pick. And so I found at the beginning of my career path where I had a little bit of a mix of mathematics and biology, and a little bit of all the sciences together. But I was interested in biology, actually, and most of my studies were in biology because I think it was interesting.

But I have a hobby, and my hobby was computers. And so, at some point, I actually mixed both, and that's how I ended up doing a Ph.D. in bioinformatics. After I got my Ph.D., I started to look for a job. And so it was natural to start to work in a company where they were building software for hospitals. And so I started to work there for a couple of years and then I moved to Israel.

And gradually, I moved from being only a back-end engineer at the beginning at MyHeritage, and then after a few years, I actually moved to my second position in Israel, and I was a CTO for a couple of months. And there, because I was CTO, I had to deal with a lot of different stuff, so naturally, I became full-stack. That's how I ended up being full stack from starting in biology field, actually.

Kirk: [laughs] I love how the evolution of careers works that way sometimes. We just go in directions that if you could go back in time and ask us back then, we'd have no idea where we're going to end up.

David: Yeah, definitely. I like to do so many stuff, so writing a book or writing poems. So I could do really different kinds of stuff, and I ended up just being a software engineer.

Kirk: That's fantastic. So I assume, you know, when we were talking earlier, you mentioned Python. I assume, because of the bioinformatics and the fact that Python is used a lot in that field, Python was probably one of your early heavy influencers as far as the languages that you use.

David: So actually, not at all. When I worked in the bioinformatics field for my Ph.D., I actually ended up writing a software to visualize DNA in 3D, and I wrote it in Visual C++. And actually, most of the popular tools in bioinformatics back then were in Perl, so I learned Perl. And then, I worked in a company that used Java, so I learned Java. And then moved to Israel and got to MyHeritage, and they were using PHP, so I learned PHP. And then, as a CTO, they used Node, so I learned Node.

Kirk: [laughs]

David: Then I entered in the cybersecurity field in CloudLock, and there was Python, so I learned Python. So every time I'll learn something new, and that was really exciting, actually.

Kirk: Yeah, that's awesome. I always love it when I'm talking to people, and they mention Perl because Perl was the first language that I was, I guess you'd say, I was really, really good at. There are a lot of languages that you get exposed to in your career. But Perl was the first one where it was like, I know this language inside and out. And yet I don't think I've written a line of Perl in 10 years.

David: Yeah, me neither. [laughs]

Kirk: Yeah, that's fascinating.

David: Same thing for PHP. Every time I moved around to another language, I just wrote something. I learned something new and then moved on.

Kirk: Yep, it's fun that way. So, what are you doing now?

David: So right now, I am a co-founder and CTO in a small startup in early-stage called Jit. And what we do there is that we're trying to solve a very hard problem that nowadays seems more and more critical to solve, and that's how to deal with delivering secure cloud applications. And it's a hard problem because security engineers are not the ones that are owning the cloud application. That's the engineers. That's the engineers that are living in the engineering organizations.

But the problem is that if you're looking at today's world and trends, you'll see things like microservices and CI/CD. All those different trends are all in favor of making sure that you can deliver fast, and you can have a small feedback cycle with the market. And the problem is that if you're looking at engineers, they would say, "Yes, we're owning our microservice. We're building them; we're testing them; we're deploying them. We're supporting them." But one thing they're not doing is securing them because most of the ownership of security is not within the realm of the engineering organizations.

And so, there are a lot of frictions between developers and security engineers because security is mostly an afterthought. And it's not built-in inside the process of writing the software. And you cannot blame really engineers because most of them are not super experts in security. Most of them are not even measured upon their technical knowledge of security and how secure is their code. They're mostly measured by how many bugs maybe they're writing, the performance of the application, but not so much about security. That's a real problem.

And there are a lot of organizations that are progressive today that are trying to solve this problem. And they're saying the following, like in the past where QA was actually a separate function, and there was actually friction between test engineers, QA engineers, and developers, and so the way organizations actually ended up fixing the problem is by incorporating QA inside the microservice teams.

Well, the same way security should work, meaning that the engineering organization should own the risk. They should not depend on some external team in order to be able to secure the microservice they're building. And so more and more, you see those trends how to be able to make security not an afterthought but something that is really part of the whole process of building the application.

Kirk: That makes sense. You mentioned when we were chatting earlier about the concept of minimum viable security. Do I have that right? MVS?

David: Yes.

Kirk: What is that?

David: The thing is, if now you're asking engineers and the engineering organization to own the risk and to be able to deal with security, there are a few challenges they need to overcome. One of the challenges is that they don't know what to do. If you're asking any startup at the beginning if their product is secure or what did they do in terms of security, everyone will tell you something different because there's no real standard. And so, the first thing they need to actually know is what to do.

The second thing is that if you're talking with engineers, you definitely do not want to disrupt them and make them do something that is outside of their normal flow. And so, if you want them to own security, it should be part of agile processes. And so the way agile is working is that you're starting with something, and then you iterate.

The concept of MVS of the minimal viable security is to say the following: you don't want to take a whole list of security requirements like you can find online. This is actually the first thing that any CTO would do. They will check online for some security checklist. What do I need to do? Most of the lists are actually big, and so that's scary.

But basically, the MVS concept says that if you can start with something that is minimal, only the critical stuff, the baseline, the thing that without it, you would actually be ashamed to release your application to production. And then, like in any agile process, you would iterate. You would iterate, and you would add more and more security. And that's what the concept is actually trying to express. You will start small, and then you iterate.

And so, of course, when you're hearing of something like minimum and security in the same sentence, it seems weird because usually, you want as much security as you can. The problem is that in many startups, they don't have enough focus on security, and so they end up doing whatever they believe is critical, but it's not all the time the best thing or the minimal thing to do.

And so what we're doing at Jit, for example, is that we want to provide this list of minimal thing. And so this security plan is this list of requirements that are tailored to your environment. And basically, you start with it. It's not the end of the journey; it's only the beginning because security is always a journey. There's no really end. You can always add more. And so you iterate every time, and you add more. But the thing is to do that continuously.

Like in agile, you have CI. You have continuous integration. Every time you add something new, you don't want to break other stuff, so you have sanity test, regression test, the same thing here. Every time you add new security, you still want to be able to monitor the things that you already did. And so that's why we're talking here about also the concept of continuous security, which is another paradigm on top of CI/CD we can think of CS.

I can actually give a few examples of things that are minimal because there are a lot of different interesting items or controls that we can talk about. And there are different areas actually that are involved here when you're talking about product security. For example, you can, of course, take a look at the code. In the code, you can look at things like vulnerability in the code and add some SAST scanner static analysis. That should be very basic.

You can also take a look at dependencies, and you can add some SCA control. So you're checking the dependencies to see if there are some vulnerabilities that are known there. And we're talking a lot about it in the media right now with Log4j and all the other vulnerabilities because that's a critical problem.

But there are things beyond code, of course, because you can secure your code as much as you want. If, for example, you're not securing your GitHub accounts with, let's say, something like MFA, then you actually leave a door and a hole wide open for any attacker to insert malicious code in your pipeline. So you also need to take care of the pipeline.

You need to take care also about the runtime of your application. And there is something minimal that you can do. For example, if you're using AWS, you need to make sure that, of course, you use MFA for your accounts. You need to make sure you're not using your root accounts. There are a lot of things that are really minimal. And if you do some automation there, it can be really done with a simple click of a button. But beyond that, I'll only talk here about the technical controls.

There is another category of controls that are also very interesting, and most of the time, they're kind of overlooked, for example, all the things that are related to processes. If you think of an employee leaving a company, you have a whole process of onboarding. And so making sure that you remove access from the employee that's something that's usually overlooked because it's hard to maintain the list of all the services that employees have access to.

And so I think that if you want really to take care of your product security, you need to have a combination, a mix between technical controls and actually human processes. And both need to be managed in a way that you know exactly what you have done so far and what you need to do.

When I look at most of the cybersecurity companies, every company is giving a different product, and each one is actually focusing in a different area. But the problem I see in the current industry is that you can buy, I don't know, maybe ten different products, and you know what you'll get because each product will focus on a specific area.

What you won't know is actually what are the spots that you're missing? What are your hidden spots? And that's why it's important to have a list so that you can have a frame, and you can see the big picture, the map of all the different areas that you need to take care of and all the risks, and then you can buy all the products that you want in order to cover those risks.

Kirk: So does Jit then…do you focus on helping people to understand what that list is for their particular environment? Is that what you do or?

David: Yeah, exactly. So at Jit, we believe that tomorrow every cloud application should start by adding security from the zero. And the problem is that it's hard because there are a lot of things to do. So what we want to provide is the list of the minimal stuff that you need to do when you're starting your project. And then we can talk about more advanced plans in the future, something like, I don't know, you want compliance because you have a business need for that. That's afterwards.

But the principle is that you will start with something minimal. The list will be entirely automated, so that's by applying your list, you would be able to see all the integrations in your environment, whether it's in the CI/CD, whether it's in your runtime, in your pipeline, all the different areas that are relevant to your product security. And of course, we also provide this list, and it's displaying as code. Because we believe that we're dealing with engineers, and so they probably want to do some customization because every organization is working in a different way. So the processes that they have may be different. That's one reason.

And the other reason is that basically, if you're looking at the risks, when you're looking at, and you're trying to analyze a cloud application, most of the risks are the same between all the applications that's based on the architecture, 80% are the same. But there are still 20% that are really specific to your organization. And because we don't know that by advance, by expressing the plan as code, it allows you to actually add your own risks or an item in the plan.

And so, first of all, we're developing everything as code because we also are thinking that the communities that we want to build will help us add all the different controls. We don't want to reinvent cybersecurity. And so we're not writing our own tools, or we're not starting there, at least. We want to be able to leverage all the awesome open-source tools that are existing already in the industry. And then we want to be able to add to that companies and commercials that also are doing great products.

And so, we want to orchestrate all these different tools in a way that you have a list with different options for different controls. If you want something free...and we believe MVS should be free for everyone because this is our vision. We believe in a world where every cloud application should be secured from the zero, and that's why MVS should be free. But then you have some more advanced business needs. And for that, we think that integrating with some commercial product will certainly be required.

Kirk: Okay, let me pose a hypothetical to you then because I'm curious how this actually works. So let's say that I have an application, a Ruby on Rails application with a very standard typical Ruby on Rails architecture. We're hosted on AWS, and we've got a Postgres database. And maybe there are a couple of other services that we hit for pieces of data. But it's nothing terribly sophisticated because it's a fairly young application. And we want to start concentrating on security, and we want to apply the MVS principle to it. So we come to Jit. And what do we do? How does this work?

David: So basically, right now, you're just installing a GitHub application. And once you install the application, you automatically get the basic plan, so the MVS plan. And we add this MVS plan to your GitHub in a specific repo to your GitHub organization so that you can see the plan as code. And you can also see it in the UI, and you can review the plan. The plan is actually grouped in different layers. So you have the code, you have the architecture, the infrastructure, you have third-party services. You have a list of different layers.

And in each layer, you have a list of items, the things that Jit will do. And so, by just committing the plan as you would do for some code that you would commit to Git, you're committing the plan. The plan is getting sent to your GitHub organization. And also, automatically, we're adding integrations. So let's say, for example, integrations with the code that would be in the CI. And so what we're doing is that we're generating from the plan a list of...let's say in the CI you're using GitHub Actions. Then we generate a GitHub workflow file that would include all the different tools that we believe you need because each one is tied to a different item in the plan.

And that's how we automatically monitor your code in a central way because we actually built some nice innovation here that you don't need to touch all your repos. We actually built something central. So we have only one repo that you define the security. And we're listening to all the PRs, all the pull requests in your environment. And basically, for each PR, we're triggering those tools in a central way. And then you have a very great experience as the developer because you see everything into the PR itself. So we would do a security review like a peer review of your code. That's the experience in the code.

In other areas, for example, we have also integration with AWS. So there, we have a role that is trusting your organization. Basically, you're giving us read access to AWS, and we can make sure that you have CloudTrail enabled. So we can do that either as code if you're using Infrastructure as Code like Terraform, or we can actually check that in your environment. And let's say one of the basic stuff that you need to do when you're using AWS is, for example, making sure you have audit logs using CloudTrail.

So we would actually show you the list of the tests that we're doing. The test would be here that you have CloudTrail enabled, and you would fail for that because you don't have CloudTrail enabled. And then you can remediate to that by just clicking on a button. You would be able to enable CloudTrail either by adding a PR in your code, or if we had write access, we would be able to trigger it through API.

Kirk: Very neat. So the MVS plan, you said it's expressed in code. What is that implemented in?

David: So here, it's interesting because we had a lot of thoughts how we express something like that because it would look like to the list. But on the other hand, we wanted really a powerful language. So we went with something that isn't really code; it's actually declarative code. So it's actually a bunch of YAML files that are defining the different concepts. So we have the concept of items, and items can actually be part of multiple plans. So you can have a plan that is MVS. But the same item can also be part of a bigger plan like SOC 2.

And so if you're actually implementing and applying the MVS plan, and let's say you're adding an incident response plan in your environment, you're automatically also making progress towards SOC 2 because it's the same item that is also present in a second plan. So we can think of a grid when you have all the different plans mapped with all the controls mapped from different plans one to each other. And basically, when you're applying some of the items in plan A, you're also making progress in plan B, C, and D because they share the same items.

Kirk: Okay, so you have a bunch of YAML files that define portions of your plan. And then you have some sort of a central engine then that interprets those YAML files and applies the plans. Am I understanding that correctly?

David: Yes. So the plan right now is expressed in YAML. And for each item, you have a list of workflows that are implemented. And those workflows can run in different, let's say, runners. One runner can be GitHub Action. One runner can be our cloud; one runner can be your cloud. That's the way the engine is actually translating the plan into something that is executable, and that can run in any of the environments that I mentioned.

Kirk: That's a pretty neat implementation. So is it language-agnostic in the sense that okay, so we talked about Ruby on Rails. But what if I have an Elixir app, or I have a Crystal app or something like that? Are you language-agnostic, or are there certain language families that you support better than others right now?

David: So right now, we have already a couple of controls, and some of the controls are language-agnostic. For example, we have a control that is checking for secrets where you are leveraging the open-source, a great open-source Gitleaks. And it's completely language-agnostic because it's searching for certain patterns, certain patterns in the code such as RegEX for secrets, so that's completely language-agnostic.

Other tools that we're using, for example, for SAST, are dependent on the language. And for that, we're already supporting a couple of languages. And we're adding more every time because what we've built for the last couple of months, actually, is the ability to wrap all those controls into containers that can be integrated with our platform very easily.

Kirk: So I'm curious about something. We've been talking about the things that people should do. And I know from my experience with Rails applications sometimes it's really easy to, as you've mentioned, overlook simple things just because you're focused on the features that have to be delivered and your deadlines. And you're not focused on even sometimes very simple aspects of security. So I'm just kind of curious, what are a few of the really common things that people forget to even think about when they are building their applications but that are very easy things to fix? Are there some patterns there that you've noticed?

David: Yeah. So, for example, and I can tell you that from the users that are already using our platform. We got some great feedback from people telling us that "You saved us because we managed to identify secrets that were in the PR." It's really easy today to forget some secrets in your code because you're testing something locally, and you're not reviewing enough of your code while you're committing it.

But the thing is that once you commit that to GitHub, basically, even if it's a private repository, it's already not really secure because you don't know who can read it. And so, even if we discovered that you still need to recycle it. So that's really a basic thing. And one way would be to add something in your CI. One other way would be to add some pre-commit hook in your own machine so that actually you're checking your code before committing it so that secrets won't be leaked.

Another thing if we're always talking about secrets is that also a pattern that is common is that a lot of people are actually working with AWS keys. And the right way to actually or the better way to work with that is to use tools like AWS Vault so that your keys are never stored in your own laptop in plain text because otherwise, it can be committed by default. Or if you're not paying attention, for example, you would have that in some environment variables, and by mistake, you would commit your file. With Bash profile file, it can happen. So I would say that secret is very, very basic, something that you need to check.

Also, if you're working with an AWS environment, I know a lot of people that are still using and abusing the root account. And at Jit, we actually spent quite some time trying to find the best way to work with securing and bootstrapping AWS accounts. And I'm actually writing a blog right now about it. So I want to share how to do the first step of bootstrapping an account that would be secure so that, for example, you don't have to define users in multiple places. Let's say you have multiple accounts. You shouldn't define your user in multiple ways because you're actually increasing your attack surface all the time with that.

And so we ended up creating a dedicated AWS account for the users, and they're actually switching roles. And that's everything is code using Terraform. They will actually switch roles between the different accounts in order to get access. And there, you can be secure because you can enforce MFA, for example. So you would make sure that if someone manages to grab the credential of the users, he won't be able to get to production, for example, because he wouldn't be able to bypass MFA so easily.

So there are a lot of things that actually are not that hard to do, but if you don't know what you need to do, it's kind of hard to find them. Because, for example, for AWS, I was looking for hours online for a simple tutorial on how to secure my account, and there's no such resource. There are a lot of things you can find, but you're not even sure that that's the best way to do that, or these are the most critical things you need to do.

And that's why also we want to bring that to everyone. That's why we believe that MVS should be free because it's really easy to overlook those things. And it's not that complicated to apply them once they're automated, of course, and that's why we're working hard on automation.

Kirk: Very neat. It sounds like what you've got is you've got a concept here, and you've got a service here that regardless of whether someone is using a mainstream language or something less mainstream, whether it's something that you have specific language support for or not, pretty much every project out there probably can benefit some from what you're doing because of those simple things like the AWS security and the secrets you're monitoring.

I know that (I'm not going to name names.), but there was one company that I worked with where exactly what you said, the AWS stuff was all under the root user. There were no IAM profiles for different users being used. And that was a very simple thing that helped lock things down because when you're off-boarding people who leave the company, if they have access to that root user, you've got a huge vulnerability, and it's an easy one to miss.

David: Yeah, exactly. And that's why, for example, the way we implemented that in our companies that we have everything as code in Terraform and basically adding and removing a user is a matter of one line in the Terraform code. And so I can grant access to another environment by adding a line. I can remove the user by just removing two lines in the code.

Kirk: That's fantastic.

David: And also another thing is that I defined in each environment a role that has only read-only access and another that has write access because the same thing; you want to apply the least privileged access. So, on one hand, you want your developers to be able to debug things in production sometimes. There's no other way to do that. But on the other hand, you definitely don't want to give them write access there because of the possible consequences. And so the basic stuff that you need to do is to have two roles. That's where I would start.

But then you can think of, okay, maybe I can actually scope my read-only access down to only the services that the developer is supposed to check. For example, if he needs logs, I will give you access to logs. And I wouldn't give him access to the Lambda code or, I don't know, to any other services because he doesn't need that. And that's how you implement gradually least privileged access. You can also do that differently by, for example, checking CloudTrail and seeing exactly what are the APIs and the services that are used. And so you can scope down all the roles.

So there are a lot of things you can do, but the thing is, and that's my main message, is you need to do that gradually. And especially if you want developers that are really, really busy with writing the code, and testing the code, and deploying, and supporting, you don't want to give them a lot of work on top of that. So that's why automation is really key here.

And you want also to give him access to data just in time. This is what we're called JIT, just in time. Because what kills developers is actually context switch. And so every time that you can give him information about security issues when he's actually working on that, then he will definitely fix it. But if the bug is already in production and then he needs to fix it, there's a huge cost associated with that.

So people sometimes say that developers don't care about security; it's not that they don't care about security. That's not their main job, maybe. But all the time, they're getting the thing that they need to fix out-of-band. And so that's terrible for them because it's a lot of context switch. And that's what we're trying to achieve here is giving them the proper context and the information right in time.

Kirk: Fantastic. You wrapped everything up so nicely there. So I think we should probably start segueing towards concluding this episode of the Polyglot Show. So I want to thank you very much for coming on the show. And I want to give you a chance to let people know where they can find you online if they want to talk with you more about this or find out any other information. And also, if there's anything that you just want to mention that we haven't had a chance to bring up yet, go ahead and mention it now.

David: Sure. First of all, that was my pleasure. That was really, really nice for you to host me in your show, and I really enjoyed our conversation. For anyone who is interested to know more about the concept of MVS that we've actually taken from the concept of MVP, the minimal viable product in the product world, for anyone who wants to know more about that and is interested even to test our platform, we are currently in early release, just visit our website jit.io. And then there's a simple button, get started, and then you'll be able to start and test our platform.

And we have a big vision about where we want to go from here though actually, our motto is that we don't have...you know, Toy Story with their motto, right? To infinity and beyond. So this is definitely our motto. We believe that there's no real limits to what we can cover because we want in the future to ask the community to actually help us write controls and integrate that with our platform because we want, at the end, the world to be a more secure place.

And so this is what I would like to wish to everyone is to have better, secure product. If I can help anyone or you want to find me, you can find me on GitHub, dvdmelamed. That's really easy because I was a big fan of movies, so it's dvdmelamed, same thing on Twitter. You can also find me on LinkedIn. I will be around in many conferences for the upcoming month. And so I'd be happy to talk with anyone who is interested in security. And thank you again for having me on your show.

Kirk: Thank you for joining me. It was a great conversation. And thanks everybody else for listening to us. You can find us on Twitter @PolyglotShow. And this is Kirk Haines for New Relic. Thank you, and we'll catch you again next week.

Open Source From Day 1 – Make Your Repo Shine with Eyar Zilberman

Mandy Moore — Wed, 02 Mar 2022 15:23:10 +0000

Eyar Zilberman is a co-founder and CPO at Datree. Datree is a CLI tool that supports Kubernetes admins in their roles by preventing developers from making errors in Kubernetes configurations that can cause clusters to fail in production.

In law school, Eyar researched open-source licensing, fell in love with the technology, and became active in the development community. He has always been fascinated by the concept of open source and how it enables developers of all expertise levels to build applications and automate processes.

In this episode, Eyar talks about why people are creating open-source projects, the reason building in the open for a company makes sense from day one, and why stars, licenses, READMEs, and tags on GitHub projects are important.

Links:

Datree
Follow Datree on Twitter
Docs
Eyar Zilberman: Twitter | LinkedIn | GitHub | Dev.to
Kubernetes

Give us a follow: @PolyglotShow

Open Source From Day 1 – Make Your Repo Shine with Eyar Zilberman

Polyglot

Your browser does not support the audio element.

1x initializing... ×

Transcript:

Ben Greenberg: Hello, everyone. Welcome to another episode of Polyglot. My name is Ben Greenberg. I'm a Lead Developer Relations Engineer here at New Relic. And today, we are joined by Eyar Zilberman, who is the Chief Product Officer at Datree io. Hello, Eyar.

Eyar Zilberman: Hi, Ben.

Ben: It is so nice to have you here.

Eyar: Yeah, I'm excited.

Ben: So tell everyone a little about yourself. Who is Eyar Zilberman?

Eyar: [laughs] I'm still trying to figure it out by myself, but I will try. So my name is Eyar, and I'm leading the product at Datree, also co-founder. And what we're doing at Datree is basically it's a CLI tool, open-source, of course. And this is also what we're going to talk about today. And it's helping developers and DevOps people to prevent Kubernetes misconfigurations from reaching production.

And it's doing it by actually checking the different configuration before it's deployed into your cluster. And also, I'm leading the local GitHub community here in Israel, which is the biggest in the world. I don't know if you know that, but here in Tel Aviv, we have the biggest one. And some fun facts about myself, I love goats. That's my power animal.

Ben: Everyone needs a power animal. I would not have known that goats would have been your power animal, Eyar. That is fascinating on a couple of levels. First of all, I love how you said our product is open-source, and you qualified it by saying, of course, of course, it is open-source. So we're going to get to that in a moment.

Why is it, of course, for you? Why was that such an inherently obvious choice for you to make at your company? And how has that worked so far, building in open, in the public, building and learning in public, and creating an open-source tool? But before we get there, how did you end up creating the largest GitHub user community not only in our little country of Israel but in the world? How did that happen?

Eyar: Well, it's actually funny. It's exactly like open-source. It's happening for a need. So I had some questions about how to build a GitHub application that you can put on the marketplace. And I didn't find the knowledge online. There wasn't any YouTube tutorial or stuff in the documentation that helped me figure it out. So I started to find people that can help me. And I was surprised because every time that you have something, you're going through your local meetup community, you know, if it's AWS, CNCF, or everything else.

And with GitHub, I was surprised that so many people are using GitHub, but there isn't any local community. So I decided this is a challenge that I actually want to take on myself. And I started the community. And on the first meetup, we had more than 100 people showing up. So I think it was a clear case of product-market fit.

Ben: [laughs] First of all, I'm not surprised at all about that. For those of us listening to this podcast episode, I first met Eyar now going back several years ago. We had a lovely coffee together at a coffee shop outside both of our mutual workplaces. And your drive and passion was already so evident in that one meeting. I'm like, this guy is a person we need to put ourselves close to because he's going far. So the fact that you created the largest GitHub community not only here but in the world is testimony to that.

And I think the kernel of it, though, where you said, there was a need, and the need became evident as I spoke to more people, and they also had that need. And together, we created something. That kernel led you to a meetup, but that kernel of that expression of there is a need, and we need to solve that need can also be an excellent motivation for creating open-source projects.

Eyar: You're totally right. So let's talk about why people are creating open-source projects. And so I will put my project out again, and we start with the why. So why are people doing it? So I tried to think about it and research a little bit. And I found three main motivations that are helping people or causing people to actually open an open-source project. Because let's face it, that's a lot of responsibility to open an open-source project.

So first, maybe you just want to build your own brand. It's a really nice way, a good line to your resume. Let's say you just finished school, and you want to get some experience, hands-on experience. So you can open an open-source project; maybe you get some people to actually use it. And the next job application that you're going to submit will also have this on your resume, and it will look really, really good. For example, when we are hiring people for development positions, this is something that we're looking for. Are you part of the community? Are you contributing code? Maybe you have your own project that is used by the community, something that is a huge bonus when you're evaluating developers.

Something else maybe it's your business, so Datree, it's my business. And, of course, I love open-source. And for sure, it was meant to be an open-source project. But in our space, when you're doing something for developers, especially for DevOps people, engineers it has to be open-source. This is the standard today for every dev tool.

And the third reason that I think that a lot of people will identify with is actually, maybe you have a passion for something to solve a problem. So for me, for example, I had a project it was for creating a backup for a Jira instance. A lot of people were using Jira by Atlassian and were using the cloud version. And apparently, there's no way to create backups to what you have on the cloud. And I looked for different solutions for that, and there was nothing out there that's supported by Atlassian or by Jira officially.

So I just used some API calls, glued them together, and I created some kind of application, then doing it on a priority sequence. And there you go; it's an open-source project. So it was something that I needed for my own reasons. But each one of us we're coders, so every time that we see a problem, we're trying to solve it with code, sometimes over-engineered. I guess you'll also have your own examples.

Ben: I think what you just articulated makes so much sense, and those different gradations, if you will, of why to get involved in open-source feed into each other. So if you are somebody who needs to advance your career, as you said, open-source becomes a fantastic tool to advance your reputation and your recognition as a developer when you get involved in projects, when you get involved in community.

When I was just starting out in code as a career changer, I was told that advice. And they told me, "Get involved in open-source. Get involved in GitHub." But then I had a hard time thinking what I was going to do until I was faced with a problem. And then, the problem became the motivation when I had to solve something for myself and automate it. So whether it's solving daily health forms, I needed to fill out for my kid's school and automating those daily health forms.

Or I was working on a project across time zones, and I wanted to know what time was it for the person I was collaborating with. I created a GitHub Action so I could ask what time it was for the person, and then GitHub fetched their location and got with time API and got me the time for that person where they were and helped me understand whether or not they're in the right time zone to ask them something or not. Those personal motivations help drive it, and I think that is 100% spot on.

But what I think is really interesting for our listeners and for us to talk a little bit about is how does building in the open for a company make sense? And when do you start doing that? When do you take your product? When you take your tool and say, am I going to from the very initial iteration begin building in open? And meaning that it's going to be all in the open-source, and it may be messy in the beginning. Or am I going to first polish it up?

And we've seen different attempts from different companies, and they decide to release it as open-source later. And you can only imagine all of the engineering work that went to making it look good first before they released it as open-source. Or do you start from the beginning when it's all messy and dirty, and you're still figuring it out? And you have a lot of different...you're pushing up code that may not look so nice all the time because you're just trying to get it right, and you're iterating in your early steps. When do you start building in the open? And why does it make sense to build in the open?

Eyar: So I think it's really related to what you're trying to do and which interest you address. So again, like I said, if you're doing something for engineers, it has to be open-source from day one because you want them to see the code because this is how they trust the project that they're using.

Today it's a little bit weird to see projects that don't have open code because this is the standard. It's really different if you're going to build a tool for marketing people. And if you're building a tool for marketing people, for example, I don't know, you have Zapier. It's not open-source, and it's totally fine because marketing people are not familiar with what is GitHub. So I guess they don't really care about it.

But again, there are pros and cons for each decision if it's going to be open-source or if it's going to be closed source. I think the question that you need to ask yourself when you face this dilemma is, what am I trying to achieve? And will doing it open-source actually help me do it? Or maybe it can actually have some bad impact on my business.

Ben: You decide from the very beginning, let's say to build as an open-source project because that's the standard for engineering dev tools today. You start from the very beginning. Before you start pushing code to the repository on GitHub or GitLab or wherever you're hosting, what are some of the things that you should do to get the repository ready to be widely available for the community, to be accessible to the community?

Are there things that you do as a preparation for that code? The ways you set up that repository to make it more usable and more user friendly for those from the open-source community who don't work at your company but who might want to browse the code, maybe raise an issue, maybe even offer a pull request, maybe they want to contribute code. What kind of things do you do to the repository even before you start really pushing code in there?

Eyar: I think that actually writing the code this is the easy part because, like I said, we're all engineers, so writing code is not something difficult for us. Actually, doing all the things around it and to make sure that people will understand how to use it and will use it is actually the hard part.

And it sounds so obvious like, why should I write something if no one is going to use it? But the fact is that majority of projects that are on GitHub; no one is using them. I ran some numbers to check it out. And it looks like you have more than 30 million repositories today on GitHub, and only, listen to that, only 4% have more than ten stars.

Ben: What does having less than ten stars tell you intuitively?

Eyar: Actually, it can tell us a lot, and it can tell us nothing. [laughter] So it's a good indication if a project is popular. If it has zero stars, I guess no one is using it, but it's not the only indication if it's a good project. But it can be a really good indication to tell if it's a popular project, if a lot of people are using it, if it is a community-facing project, and so on.

So it's a good indication to get started. Because yeah, there are many other factors that you need to consider, like when was the last commit to this project and how long it's taking them to actually solve bugs, and a lot of other factors. How many pull requests have opened? How many pull requests are closed? What is the size of the repository? A lot of factors.

But again, I think the stars are a really good indication to actually tell you by a glance if this is a project that you should consider using or not. I'll tell you what, when we started our project, we started with zero stars, [laughter] of course, like everyone else. But today, we have more than 5,000. And I was surprised that the code is pretty much staying the same. But if we change a lot of stuff around it, and this is what drove the adoption and what drove more stars to this project.

So some important stuff when you're getting started, and this is like the mandatory stuff. I'll start with the mandatory stuff, license. I guess not a lot of people are familiar with why you need to have a license or why to use a license. I'll just give it in a sentence. But basically, a license is a way for us to understand if you can use the code and if you can use the project freely or not.

Ben: And how you can use the code.

Eyar: And how you can use it, exactly. And if you don't have the license, by default, you can't use it. Although you can see the code, you can't use it. And this is the legal hat that I need to put for a second and give this disclaimer.

Ben: You have so many hats.

Eyar: Yeah, [laughter] actually, I don't know if you know that, but I actually finished studying law.

Ben: I'm not surprised.

Eyar: Yeah, that was my degree, studying law.

Ben: Engineering, law. You're just creating your own startup basically at this point. [laughs]

Eyar: Yeah, one-man startup, exactly. So a license is really, really important, and it's important to put the right license. I'm not going to expand about how to choose a license because there's so much information about it. Just Google license for GitHub, and you have all the information about how to choose a license and how. And once you have the license, people will see the project and understand that they can use it.

The second thing that is important is to have a contribution guideline. Because if someone will find your project cool and will want to actually submit a pull request, you want to understand the guidelines, how it should look like, what you will accept, what you won't accept, how the commit message should look like, what is the day for doing a code review, so on. All that information it's important for people to know.

Something that was really surprising for us that we didn't implement it when we started, but when we crossed the 1,000 stars benchmark, we actually introduced it, and it was amazingly effective. So we had a lot of issues, but we saw that people are not taking them. But we knew that people are using the product because, like I said, we already had like 1,000 stars, and we had the community around it.

So we knew that people were using it, and we knew that people are loving it. But we had issues, and no one was taking them. And then someone told me, "Hey, there's a problem. Think about the person that wants to submit code for your project for the first time. And it's a big project right now, and they don't know where to get started. You need to tell them which issues are good first issues."

Ben: The tagging of the issue.

Eyar: Yeah, exactly, the tagging. So we started to tag them. The second that we tagged the issues, they disappeared because people took them.

Ben: So, not having the tag became a barrier to entry.

Eyar: Exactly, exactly. Because think about it, you see a Golang project. It's an enormous project with 1,000 stars, and you're afraid to actually go in the core of this project and actually start doing stuff. You want to do it with baby steps. You want to change small stuff, but you don't know what is a small change. So you start with everything that is tagged as a good first issue. After we did that and we saw there's a lot of impact, we actually changed the way that we're opening issues.

When we're opening issues, we're trying, especially for good first issues tags, we're trying to explain exactly to the person that will take it which part of the code they need to change, where they need to touch in order to submit this pull request. We're trying to help them as possible to guide them because the motivation is there. People want to contribute code. You just need to help them get started. So that was really important.

And the last thing that is the most important thing is the README. So the README this is actually the cover of your project. This is how people will decide if they want to use it or not. Think about README in plain text with three sentences and compare it to a fancy README with badges and images, and examples. I can promise you that you will actually try to read the second one trying to actually investigate if this is something that is interesting or not. While if you see a project with three lines in plain text, they didn't spend too much time on the README; why should I spend time reading it? And you can miss something amazing.

Ben: I think those points are so crucial. And for a lot of people getting involved in creating an open-source project, whether it's an open-source project for a company or their own personal project that they want to get people involved in and excited about, they often forget about those steps, whether it's the basic legal fact that without a license, no one can use this code. They can look at it, but they can't use it. So you need to license, the contributing guide, how to contribute, what areas you're looking for contributions in, and what type of contributions you're looking for, and how to submit the contributions.

And then tagging issues, and you're totally right. We often tell people to get involved in open-source. Everyone should get involved in open-source. But then you come to a popular repository, a popular project with thousands of stars and hundreds of pull requests, maybe more than hundreds, maybe even 1000+ issues. And people are really engaging in them, and you're brand new. It can feel very intimidating to enter into that project.

So tagging as a good first issue, creating pathways, helping people identify where the code lives, where the change might happen. I think they are all ways that you can help make it not only welcoming for the veterans of the project, and continue sustaining the welcoming for the veterans, and making it a place they want to stay in, but also welcoming for those who are just coming in.

And you have to always wrestle with both of those at the same time. How do you keep it a place that nurtures those who are continuing to provide support to the project and who are part of the community while also not alienating and being a welcoming place for those who are brand new, whether they're brand new in the project or they're brand new in the project, and they may also be brand new in code? And they see your project is something that's really interesting. And maybe this is the place where I want to finally get involved. Do you have a docs issue that they could jump in on? Is there a testing issue they could jump in on?

I often found that getting early developers writing testing is a great way as an entryway into a project because you get to learn the project through writing testing, and testing teaches you the behavior of the project so those sorts of things. I think you're totally spot on about getting people involved. And how has that worked for Datree? So it sounds like you went from zero stars to thousands of stars. It seems like it's going pretty well overall, if I'm understanding correctly.

Eyar: Well, it was 1,000, and now it's more than 5,000. But yeah, [laughs] doing all this infrastructure to make sure that people will feel comfortable to be involved in the community that you are creating is supercritical. But again, it's a startup, and your open-source is also a startup. And just like that, it's always important to prioritize stuff. So we talked about what is mandatory. Let's talk about stuff that is less mandatory, and people actually tend to think that they are critical. So you will be surprised less critical is code coverage and unit test. [laughs]

Ben: Shocking. That's shocking.

Eyar: I know, I know, but I'll tell you why. Because if we're aiming to do something that adds value and we want to have the community join us in doing that, like you said, testing is a really, really good place for new contributors to get started. So this is something that you can put aside because it's taking a lot of time. So I'm not saying do zero tests, [laughter] don't check that it's actually working. Do the bare minimum but also leave some room, not to make it 100% code coverage but give some room for people to actually get involved. It will save you a lot of time.

Ben: I think that is such a brilliant insight that you intentionally leave gaps, not in a bad way and in a malicious way. You have coverage of your code, but you're not necessarily covering every single detail with 100% code coverage in order to provide the space for those who are just entering into the project, provide them an easy avenue to get involved. And testing happens to be one of the easiest ways to get involved, and it's a great way to learn the project.

I think that's fantastic and especially when you're talking about a project which is like Datree, which is both so essential because Kubernetes configurations can be a nightmare for so many people, figuring out your configurations for your Kubernetes clusters and the deployment options. And the complexity can scale dramatically. And that scaling of complexity, the more the complexity, the more potential problems there are.

But at the same time, that complexity can also be overwhelming and can be almost intimidating as well. Kubernetes, as an area, can be very intimidating. Have you seen in your role and at Datree, and it's part of open-source, that not only have you made your product more accessible by being open-source and more genuine, more authentic to the developer community, but it has helped also get more people involved in Kubernetes? Because your project, in some ways, can be seen as a gateway into understanding and having a more thorough involvement with your Kubernetes configurations and understanding what goes wrong and getting more insight in all of the vast and complex world of Kubernetes.

Eyar: Yeah, of course. So because our tool is actually providing some kind of, let's say, a guardrail for someone that's getting started, and so we can actually try Kubernetes without making fatal mistakes. So essentially, [laughter] I think getting started. And like you said, Kubernetes has so many setups and knobs that you can change, and just missing a character or something can actually cause total failure. [laughs] If something is not configured correctly, nothing is working. So Datree is a really good way to actually getting started with Kubernetes.

But the fact that it's open-source, it's also created something interesting that we didn't consider, but we're really, really proud it's happening. So it's helped people to actually be engaged with our own open-source. But it's actually created a community around our open-source, which we saw people actually creating their own projects that are relying on our open-source.

I'll give you an example. So someone created a VS Code extension that is relying on our project. So we didn't add this integration. So he took Datree, built a VS Code extension. Behind the scenes, it's actually our open-source, but it's a project that he created. Another example, so someone created a Tekton plugin, which is really common when people are using Kubernetes. And someone else created a GitHub Action for GitHub.

Ben: So the ability of it to be open-source one of the things that it lets happen is that it accelerates the adoption with all different types of other ancillary products and projects that people are building on top of your project. And it makes it that much more relevant for the developer community.

Eyar: Yeah, exactly. And something that I really enjoy doing is actually looking for people that are using Datree in the CLI. So it's really easy to do it. You just write Datree; you look for YAML files. And just to see the number of projects that is rising that's using Datree in the CLI is so satisfying to see that people are using it and enjoying it. And it's implemented in their workflow exactly like we intend.

Ben: That's one of the amazing things of open-source in general. You can search across and see, oh, this project is being used in all these things that I didn't even imagine would have been used. Or they were on my roadmap, but we never got to it yet because we're doing 30 other things. But this obviously was a need for this developer or this project. And they built it for us, and they put it on the open too. And now it's being used by the vast community. It's unbelievable. It's amazing. You're totally right. So it sounds like it's working pretty well for you.

Eyar: Yes, yes. Yes, it is.

Ben: [laughs]

Eyar: But I also want to give some tips to other people that are starting open-source projects.

Ben: We'd love to get those tips. I'm sure we want to hear them. Go ahead.

Eyar: So we talked about how to write it. We talked about what should be included, what you can actually skip. And I think that another really important part is actually how to market it, how to make people hear about it. And I think this is, again, something that people tend to skip. And it's not magic. It's not once you click on make it public everyone is coming and making a star and starts using it. It's not like that. There's actually some elbow grease, work that needs to go into it to make people hear about it.

So again, I'll give a disclaimer; some projects are so amazing. And it's happening that sometimes they are going viral, and you don't need to do anything. But for the majority of projects, including ours, by the way, we needed to do some effort from our side to show to the community that this is something that we created, and you can actually use it. So I do want to give some best practices for that.

So I think it's not that hard because if you think about it, we are the audience of something like that. So I thought about myself. I thought, where do I find my own open-source projects that I'm using? So I know that I find them on Hacker News, on StackShare, Reddit, Slack groups, Twitter, newsletters. And these are exactly all the places that we went to publish and to announce when we created Datree. And it's really, really important to always think about it. You're, in a way, the user of your own product. So you can think about where you find other open-source projects. And this is how you need to market your own open-source.

Ben: So the question I have for you on that, and I think you're totally spot on, is how did you manage to do that in a way that felt natural? So again, putting ourselves in that perspective. And I'm looking through my subreddits that I like to read, and I come across material that feels very marketing. I may just walk right past that. But how did you make it in a way that felt like it was something I, as a developer, would want to look at?

Eyar: Super easy. Don't give a marketing guy or woman to do it.

Ben: [laughs]

Eyar: Do it by yourself and write it like you want to read it. Every time that I'm writing something, I'm trying to read it again. And I'm saying, will I use it, or will I say what a bunch of BS?

Ben: [laughs] Fill in the word, right.

Eyar: And I always try to write stuff that I want to consume, and I want to read by myself. So I will never write something that is high-level marketing fluffy with no content and big buzzwords with no examples. So every time that I'm announcing something or every time that I'm writing about something, if it's a Hacker News, or Reddit, or whatsoever, I'm explaining exactly the use case. I'm explaining why we built it.

I'm actually getting really technical about how we did it because people like to geek out about the technology itself. So we explain exactly how we decided to do it. Sometimes we actually explain why we decided to do it in a specific way and not in another way. Why did we decide to use Golang and not Python? And again, I'm trying to think about stuff that I want to read. And this is how I write the announcement.

Ben: That is so important, and I can imagine it takes an extra layer of thoughtfulness. Because when you're writing something, you also have to then put yourself in the perspective of the person who's reading it. And so many times, we're in the mind of writing, and we don't take the extra step to say, okay, let me read this through the no-BS factor and look at this from my personal perspective. And does this actually read okay, or am I writing something which is going to be put in the metaphorical garbage the second that I look at it?

And a lot of times, we don't take that extra step. So you're saying it's crucial. It's pivotal to take that extra step and think to ourselves, am I actually going to be wanting to read this? And if not, I need to go back and rewrite the whole thing.

Eyar: Exactly.

Ben: That's amazing advice. I think that is...for those of us who are most interested in getting people to even hear about our open-source project, a lot of us know we go to Hacker News, we go to Reddit, Twitter, newsletters, but it's how you phrase it. It's, do I want to read it? And more than I'm writing it, but do I actually want to read what I'm writing? I think it is so important. And that tip is really, really, really crucial. Eyar, thank you so much for your time today. I think this has been a wonderful conversation. Where can people find you out in the world?

Eyar: Everywhere. So LinkedIn, Twitter, and GitHub, our own project, open an issue. I will also drop a link for people to check out, and they can ask any questions that they have about how to do open-source or how to market their open-source. And I will be more than happy to share from my experience.

Ben: From first-hand knowledge, Eyar is very accessible for everyone. He will respond to you. Thank you so much for taking the time. We will post those links in the show notes. Thank you so much for joining us on Polyglot.

Building A Network with Rynn Mancuso

Mandy Moore — Thu, 24 Feb 2022 15:04:43 +0000

Rynn Mancuso is a Developer Community Manager. They began their career as an Accessibility Engineer working on Women Who Code and building a WordPress community locally at Tech Liminal, and have built developer communities at Mozilla, Wikimedia, Tidelift, and New Relic.

This season, we’re helping you level up your interviewing skills! Each week Lauren Lee, Danny Ramos, and industry experts will offer advice on navigating career progression within tech.

👉 Give us a follow: @LaunchiesShow

Building A Network with Rynn Mancuso

Launchies

Your browser does not support the audio element.

1x initializing... ×

Topics Covered On This Episode:

How Communities Have Changed Since The Pandemic
Advice For Introverts and Extroverts
The Importance of Social Media to Achieve a Career in Tech
Networking & Finding Community
Community Engagement
Finding a Mentor
Leveraging Your Network

Links:

CTA (Call To Action): Join the New Relic Community Slack and tell us…

List what are key things you're looking for in a community that you want to join. Share them! What you do want? What don't you want?

👉 Follow Launchies, Lauren, and Danny on Twitter!

🚨 FutureStack 2022 call for papers is now open! 🚨

Sign up to share your successes and learnings in a hands-on lab, workshop, or deep-dive session to help your peers advance their observability game.

Transcript:

Danny Ramos: Launchies is a tech podcast dedicated to helping early-career developers or soon-to-be devs.

Lauren Lee: We'll share insights on how to navigate these early opportunities and bring on experts from the tech industry to give advice on general career progression.

Danny: In the first season of our show, we focused on how people launched into their tech careers.

Lauren: And now, in Season Two, we want to offer advice on your career progression.

Danny: The next 12 episodes will be all about the interview and landing your first job.

Lauren: Hello.

Danny: What's up? What's up?

Lauren: How's it going?

Danny: It's going good. It's Monday. [laughter]

Lauren: I put an 8:00 a.m. call on your calendar for this.

Danny: I didn't even know how to respond. I'm like, you know how it is. It's 8:00 a.m. on a Monday. [laughter] And I didn't know about this until last night. Well, it's my fault. I didn't look at the calendar. But I was like, hmm, let me see how my day looks tomorrow morning. And I was like, ah, Lauren scheduled an 8:00 a.m. meeting.

Lauren: There's a way to see this in that you're starting your day with the Launchies community, and what a great way to kick off the week.

Danny: It is a little cold in the Bay today. So I just need the warmth. I need the warmth of the community around, a big group hug, so to say.

Lauren: So let's give that for Danny, my deepest apologies. [laughter] I am on the East Coast, and it is midday for me. Well, I wanted to see your face and talk about networking, and community, and the opportunity to leverage the folks in our world while navigating the job hunt.

Danny: And this is today's theme for Episode Two. This is not --

Lauren: Oh no. That was just my musings of what I was wanting to do. [laughter]

Danny: I was like, this is what Lauren likes to talk about, just a cup of coffee. Let's talk about community and networking and then go about our day.

Lauren: This is going to be a great episode. I think folks are going to have a lot of takeaways and hopefully feel good about; I don't know; I think there are a lot of pressures to know everyone in the industry and just have...I remember being obsessed with getting to the 500 mark on LinkedIn because once you hit that number, it stops counting them, like people that are in your...and so going to meetups and being like, "Hey, do you want to connect on LinkedIn?" [laughter]

Danny: Yeah, I remember that from the Twitter Spaces that we did recently about how to break into DevRel as a junior. A lot of people had brought up like, oh, it's just really difficult to...because you end up comparing yourself and thinking like, oh, people in DevRel have to be like influencers. And I'm sure it feels the same way when you're going into tech. You're like, oh, this person with this many followers or with this many people in their community they're going to get the job because they know people, and they have that network.

But this episode is really about just how to begin, where to start to get into those networks. What are some networks that interest you? Maybe you'll end up growing from there, or maybe there's a way to find a mentor. What are just the different approaches of finding community like blogging, Twitter, open-source, those types of things?

Lauren: Well, the conversation took a really cool turn in that we really explored the positives of the world going online and how that opened up doors for all these communities that may not have been able to gather in person previously in years past. And so, I think that that is a really cool way to spin the reality that is now, and it's got me excited to check out some new communities. So I have some good follow-up action items, and I hope everyone else does after listening.

Danny: Oh, absolutely. Rynn, thank you so much for being here. We're really excited to have you as our second guest. Please tell us about your background. What got you interested in community management, community in general? Was there anything in your life that got you to the point to where you are today?

Rynn Mancuso: Sure. So honestly, I got into online community from doing offline community. I was involved, and this is back in the late 2000s, in a community for artists in Atlanta called Alternate ROOTS that focused specifically on getting out there in the community. And many of these people weren't technical at all.

And so what I was doing was helping these folks who were storytellers, generally older folks, visual artists who would involve whole communities in murals in developing and sharing their work online, creating even a website for the organization. And so I really learned from them a lot about the power of community and, at the same time, the power of technology to really enable community to reach a larger audience, and so that's how I got into community management.

At the same time, I was working actually on the LiveJournal support team. And so I really saw the power of it, both online and offline, went to graduate school, focused on community, and my degree was in digital media, and moved out here. And, of course, the social media revolution was really just beginning in 2010 when I came out here. And so for a while, I was really involved in that, did a large [inaudible 5:52] on social media, worked for Oprah Winfrey for a minute, which was totally wild to be a community manager for her.

Danny: What?

Rynn: What? I know. [laughs]

Danny: You're just going to throw that in there? Just casually like, oh yeah, and I also worked for Oprah, no big deal. [laughs]

Rynn: Yes. Oprah's community, speaking of the power of community, it's wild. People will write Oprah and be like, "You're my only hope. I was going to give up on life, and then I saw your show."

Lauren: Oh my gosh.

Danny: [laughs]

Rynn: She's just so into their space.

Danny: So you went from helping older folks get their work online, and then you're just working beside Oprah, you know, you're drinking coffee alongside her.

Lauren: Rubbing elbows.

Rynn: [laughs] I wish it were that cool. I did not ever meet her. Our team worked for her, and it was great. But yeah, you have to remember Oprah is a master community builder because she was in everybody's living room with her community as her studio audience, and everyone was like, we're just an extension of that audience. And so, working for her online really gave people the sense of being part of that studio audience.

Danny: I really liked that you worked within the art community at Alternate ROOTS. Was there something that you were passionate about, like in the arts world, that put you there, or did you just find yourself there?

Rynn: I actually was passionate. So my other passion besides building digital community is accessibility. And so I was there because I was working on inclusion for disabled people. And I was specifically at the time working on accessible dance.

Lauren: Oh my gosh, cool.

Danny: Wow.

Rynn: Yeah, that was another really powerful community building because a lot of times, folks with physical disabilities have been actively discouraged from participating in any movement activity. And so they've been told this just isn't something they can do. And so to really create a space where people with physical disabilities as well as people with mental or cognitive challenges who might have been told, "Oh, keep your brain covered up. You must act a certain way at all times," were sort of allowed to dig in and fully express themselves through movement. It was really a truly amazing community to build.

Lauren: I love that.

Rynn: I could tell stories about the power of community all day. [laughs]

Lauren: And so this show is focused for folks that are ready to launch into their tech careers and today focusing on that how do you leverage community or how do you participate in community or build a network? So that that process feels a little bit more collaborative or that you know the community that you're launching into even before you're in it necessarily for a full-time job. So I'd love to hear your thoughts around tips you have in that regard; just for folks that are, I don't know, it's a tough thing to navigate. Plus, I imagine that communities have really changed in the past few years also in our new reality.

Danny: I think one thing to point out that I really, really liked was that when you are curious about communities, and much like what you did, Rynn, was that you were really into accessibility. So you went to the accessibility space and then made and found your community there. Whereas someone who is new to this and doesn't know where to begin...let's say you're really interested in gaming or really interested in people who contribute to open-source; you can find a community there and get your foot into the door and just --

Lauren: Let your passion drive it like where you show up for community. Gosh, that throws me back to when I was navigating all of it. I had no idea what I liked. So I speed-dated meetups. I would go to a different one every single night of the week.

Rynn: [laughs] Amazing.

Lauren: I was living in Seattle, so I could. There genuinely was a back-end meetup one night and then a Ruby meetup the next day. And I could just go and check the vibe of each group [laughs] and like, oh, those are my people. Or wow, I really don't want to go back to that one again. [laughs] So that was really, I mean, I was very fortunate that was an opportunity given to me because you want to be passionate about what the community is. It has to happen.

Rynn: Yeah, I totally agree. Especially if you're in a large city but also now that everything's online and we've got Clubhouse, and we've got Twitter chats, and we've got webinars, and we've got lots of ways to connect with things. Speed dating different communities is not a bad way to settle on a technology you want to work with because I think just as important as you really liking the technology is you liking the community. Because it might be that you have decided you want to make contributions to languages, and you want to go fairly deep with languages.

And so maybe you want to be in the Rust community, which is quite a lively community and can be a great one to join. And you go feel it out by going to Rust meetups. But maybe it turns out that you're not really a Rust person, and you want to be contributing to Ruby Core or something, and you go ahead and explore where those intersections are.

Because chances are that whatever your general technical area of interest is, there are going to be 15 different ways to apply it. So you want to pick the thing that you want to apply it on, a community that you want to be in, that you enjoy showing up to every day. And I would say think of showing up to a community is a little bit like showing up to work. You got to like your co-workers. These are going to be your co-workers in terms of open-source contribution, in terms of helping you figure out problems. So you've got to like the other community members.

Lauren: That's great advice.

Danny: That is really good. Yeah, I didn't even think about it that way. I always separated the two in my mind where I was like, work is work, and then my community are all my friends. But of course, I'm going to put them through the same type of step-by-step process. Like, do I like these people? Do I like being here? Do I like hanging out with them? Do I like talking to them? Do we share the same values?

Lauren: For sure. And gosh, I wonder, Rynn, if you can speak to now how things have changed, what do you miss from that kind of in-person stuff? But what also are the positives, or what have we embraced since the world has gone online? And we can have these virtual conversations with people across the globe.

Rynn: The biggest thing for me has honestly been seeing small communities get more connected and galvanized. And that was something that we saw really at the beginning of online communities back in, you know, as soon as it became possible with LiveJournal or whatever for just the average person to connect to other people. We would see people meet people who were like them. And you're living in a small town, and you work on an incredibly specific technology. And no one else in the town works on that technology. And all of a sudden, you're connected to people.

And I think we had an acceleration of this during COVID. Because once we had injected into communities, people who maybe were not that into hanging out online before...and it's meant some spaces get worse. People have, in some cases, brought polarizing opinions into internet communities that were less present there, to begin with. And we've definitely seen an uptick in negativity.

But we've also seen tremendous positive things happening. For example, dance communities are coming online for the first time. People are dancing over Zoom and connecting over Zoom with people in other countries. And your grandmother is maybe coming online and dialing up to the internet for the first time. And it's really been a pretty amazing change.

Danny: Yeah, it's been kind of really interesting to see because I started my tech journey all online.

Lauren: Great point.

Danny: And seeing these communities grow it's actually made me more excited for people who are more introverted like my younger brother. He's now interested in communities because of things like Discord because he talks to his friends on Discord, and he can do that in the comfort of his own space. He doesn't feel like he needs to go out and do anything. And for me, I'm like, I missed these in-people interactions. I need to have people around me at all times. But then I forget about the people who maybe don't necessarily find that as comforting as me.

Lauren: Right. And your brother is like an active member in his community. He's a participant, and he's valued, and he's participating just as much as anyone else in there. So he's not differentiated because of his introversion or extroversion. It's really beautiful if you think about it. I love that.

Rynn: Right. I'm a very extroverted person, which I think has led me to be more comfortable seeking out community. Although honestly, I know many introverts who are really good community managers. I think sometimes introverts can feel more comfortable in an online community and being able to respond asynchronously.

And that's another thing I would say, consider what communication methods the community uses and what is right for you. For example, if you were trying to join an open-source or open standards community whose primary method of communication is a weekly call and you don't have a good time processing audio information, like, you don't learn best that way, maybe that's not the best community for you. Maybe you need to go one community over to the folks who have a weekly Slack stand-up.

Lauren: Sure, yeah. And being open to playing around with what works for you and also knowing yourself and setting those boundaries too like, this isn't for me, and that's okay.

Rynn: Very much so.

Lauren: As you said, there are so many communities. And something really lovely about tech is that people want to help each other. If you have a loving space, that might be the place to ask for help while reviewing a resume or finding a referral to apply to a job or find your next gig. And so you really want it to be a place that you've put a lot of thought and care into participating in.

Danny: Yeah, I really like what you had said, Rynn, about the communication style and seeing if that feels comforting for you. If the community that I wanted to join was like, okay, we're going to go into breakout rooms immediately, and no one has their camera on, [laughs] I'd be like, I don't like the way that makes me feel. I don't know if I want to do that.

Rynn: Sure, yeah. And it's tough online to pay attention to your feelings sometimes because you're so in the computer and in your head. But I think in terms of finding something that is a fit for you, it's really important to step back and really think, how did that make me feel?

The other thing I'm going to say is every time you go to a community for the first time, sometimes you can tell it's totally going to turn you off, and this is not your thing. But I would encourage you, if you feel uncertain about something, to go back two or three times because it may be that you were anxious. You didn't know how it was going to go. So go ahead and participate in three Twitter chats on C++ if you're debating what language to get into.

Lauren: That's great advice. That brings up a question I have around for folks that are brand new to tech. And where would you recommend someone gets started with navigating all of this? Where do we start?

Rynn: There are really great tech communities designed specifically for beginners or learners, and that can be a good place to start. I would say also, going back to what Lauren said, if you can find a community that's strong locally where you are, maybe there's a big company in your town that hires lots of people who use a particular language, it could be good to make that the first language that you learn because you'll be able to get lots of support and build connections both online and offline. And then, for your second language, you could feel more empowered to make a larger, more focused decision.

Lauren: Absolutely. I think it's really helpful to have people that are going through similar things that you're also in the weeds with, whether it's looking for a job or learning a new language. It feels nice just to have people to be like, yeah, today sucks, doesn't it? Or like, wow, I got another rejection letter, I don't know. There's value in finding people that are in the weeds in similar places like that, I guess.

Rynn: Yes, I'm going to memo this here, but there's a community on Twitter right now learning to code, and somebody is going live twice a week with them on Twitch streams, and they're all learning to code together. And a space like that can be really wonderful because Twitter, you also talk about your life. And so you're able to tweet when you're frustrated with the hashtag and get support.

Lauren: Yeah, because it stinks to struggle alone. I mean, that's just a human truth. So that's going to be the same while job hunting. [laughs] That's just the reality of the situation.

Danny: Speaking of Twitter, I wanted to ask you, Rynn, has there been a more successful approach in your eyes to building community, or joining a community, or more engagement? Have you seen it more on Twitter or just on Dev.to answering questions or, like Slack groups, open-source? Are there ones that you've seen that have been more successful for people who are just starting out or just successful for you in general?

Rynn: I would say Stack Overflow they are working on it, but I would not necessarily suggest engaging a lot with Stack Overflow as a beginner because they have a lot of really complicated rules about what kinds of answers get accepted and voted up. And you might want to treat it as a read-only mode site, unless you feel really motivated by that kind of community.

Wikipedia is a similar community. They have lots of rules to maintain answer quality and article quality, both of them. And both of them can be wonderful welcoming places, but they're probably places that you want to go to work on something that you're already an expert in. Because learning their rules is so complex that that's where you're going to be doing your learning.

I would say Dev.to is really a great place to learn in public to go ahead and post your learnings and posts where you're stuck. And you can blast out your Dev.to posts on your Twitter or whatever, like, get people's attention on it. Dev.to is sort of like Medium for developers if you've ever been on medium.com. It can be a really great empowering free-form space.

Danny: For me, I was always suggested like, oh, go join different Slack groups. And for me, when I was first starting out, I actually found that really useful. It was nice to just get the opinions from people that I didn't even know. So I was like, I had no real strong connection to them. And I would just throw my resume in the Slack group. Like if they had a resume channel, I'd be like, "Hey, can I get some feedback on my resume? How does it look?"

Lauren: Take a look. [laughs]

Danny: Yeah, like, please. "I don't know you, so don't feel bad if you are afraid to criticize me or something. I want all the criticism."

Rynn: The anonymity of it is nice.

Danny: Yeah, yeah, exactly. I just see this little, tiny square photo of them looking cute and smiling. So I'm like, whatever.

Rynn: Absolutely.

Danny: They're nice.

Rynn: I've also found Slack to be really positive. There's a great Slack for developer relations. There are a couple of different Slacks for community management. And all of those have really been my lifeline because often, when you're working in community, you're the only person who knows about community within your organization. And so you really need to talk to other people in the field.

And I think that can also be true...sometimes, in a technical role, you might be the only technical person in your organization, like if you're supporting a non-profit or whatever, and you really need that connection. Or it might be that you're the only expert in your particular technology. And Slack groups can really bridge that gap of loneliness. And I think Slack groups can also learn together, learn in public. I took a course together with a cohort from a Slack group once, and that was really wonderful.

Lauren: That's nice.

Rynn: And I think I got more out of it than I would have because it turned out the course covered a lot of information that I already knew. But I was able to get on calls with these two people and help explain the information to them. And for them, the information was all new. And I felt really empowered by being able to do that and got really positive feelings. Whereas otherwise, I would have just blown through the class and been like, yeah, whatever, didn't learn anything from that. But I learned I have some valuable insights to share with people. And sometimes you learn you know more than you think.

Lauren: That's great. There's something really powerful about teaching a concept to your peers and realizing, oh, I get this, and it helps you really solidify your understanding of stuff, I suppose. Danny and I have a great debate going around social media for a career in tech. Where do you land on that? And whether it's necessary or helpful or, I guess, a good thing. [laughs] How do you feel about all that?

Rynn: I think especially with COVID going on, you can't go out to meetups to get your next job. You can't literally go shake people's hands and be like, "Hey, I want to be an engineer at your company." And I think right now; social media is a really helpful place to connect with folks who you might not otherwise connect with.

And you can kind of meet somebody on Twitter in a Twitter chat. You connect with them on LinkedIn; you see what their background is. Now you've had a few exchanges with them. Maybe you're able to ask them to hop on a half-hour call with you to network, or maybe you're able to ask them to join you in a Slack and have a text chat or over at Google Hangouts or even over Twitter DMs.

So I think that social media can be wonderful. At the same time, I realize that it is not for everyone. I think if you are a new person trying to break in and social media is not for you, then that is fine. I would definitely say maintain a LinkedIn, even if you don't log into it all the time just because that's a nice, little web presence. It's a nice way for people to see who you know, for you to connect to people and keep track of who you know. But I don't think that if you really are someone who feels repulsed by Twitter that you need to be on Twitter.

And I would say if you're not going to be on social media, maybe an open-source community is best for you. Maybe making contributions to Kubernetes will get you Kubernetes jobs. That is fine. And there are lots of people around all those open source and open standards communities who make great contributions who don't go on social media. But you definitely need a way to be connected to people. And I think right now, given that we are all inside due to COVID, it's not going to be in person, so it's got to be an online option.

Lauren: I think Danny and I can agree on all those points, right?

Danny: [laughs] I am just such a Twitter fiend. I think from just everyone needs one. Why wouldn't you just use it?

Lauren: Because it's overwhelming. [laughs]

Danny: It is overwhelming, and I think I'm just naive because I'm just like, my experience with Twitter has been okay. It's fine. But I know that people have bad experiences with Twitter, and I forget that.

Lauren: Oh, the privilege.

Rynn: Right.

Danny: I'm over here, just like doo, doo, doo. I'm just going to share my feelings; I don't care. [laughter] So I forget that there's a bad side of it.

Rynn: It's totally people who, and we have to acknowledge for good reasons, like they've been stalked or something like that. They can't be on Twitter or can't be public on Twitter. And I think we need to be aware that those people exist and be inclusive and remember that they're losing out on an opportunity.

Lauren: Definitely. Tailoring things to what works for you feels like a really good theme that I'm pulling from today. I'm hearing you say that a lot, that just know what is good for you and prioritize that. The comparison game can be so toxic that if we allow ourselves to think that we need to be like other developers that we see in our network or whatnot, that's not going to work. And so listen to yourself and decide, oh, I think I want to be a part of this particular community for these reasons. That's a great way to navigate things.

Danny: Yeah, I actually really like the idea of someone being in their space and thinking about it to themselves like, okay, so I'm thinking about joining a community, and this is what I would, like, take some time to write it actually out so you can see it and say, I want there to be this, this, and this, and I want to feel these feelings, blah, blah, blah.

Lauren: I like that.

Danny: And that could be a call to action when we get there.

Lauren: I was just going to say that. [laughter] Danny, you took the words out of my mouth. Is this our call to action? List it for us. What are those things that you're looking for? Because for sure, what I want is going to be so different than Rynn or Danny both of you want. And then declaring it to the universe might also be an interesting exercise also so that you can maybe even learn about some of those communities.

Rynn: Exactly. Yeah, I think declaring it can be really helpful. It's probable that somebody knows about the community that you should join.

Lauren: Yeah, I really like that.

Danny: I mean, they're probably going to share this on Twitter, unfortunately. [laughter]

Lauren: Oh, stop.

Danny: Or an email chain. I don't know. What else?

Lauren: Okay, you're done. Okay, you're done. [laughter]

Rynn: If you're not comfortable on Twitter, it's really fine to join...I would say consider the big affinity Slacks. Consider women in tech. There's a Slack for that. There's a Slack for LGBTQ people in tech. There's a smaller Slack for disabled people in tech. I would consider starting out with one of those communities because you'll have something in common with the other members and be able to go from there. If you're not a learner of community, that's a good place to start.

Lauren: For sure. I know we wanted to touch today on if, say, the scenario, someone's looking for a mentor but doesn't know exactly how or who to ask. Do you have any tips when it comes to community on finding folks that might be supportive of your journey and might have insights on how you can maybe progress your career?

Rynn: One way you can get lots of eyes on you, and I did this with Women Who Code when I was an accessibility engineer I found it...actually, the first front-end meetup of Women Who Code, the meetup previously to me, had been all Ruby. And so I was like, I'm having a hard time finding a job right now. It was the Great Recession. The recession of 2008 was still going on, and the industry was pretty down. And I couldn't find a job as an accessibility engineer.

And so what I did was start up this group, and I brought in a lot of people who were learners who knew even less than me, which helped reinforce my own feelings about learning, and they learned together. And the most important thing was I didn't have to know everything because it turned out that once this just emerged, there was a real need for it. And other women who were more experienced developers would come in and get engaged and want to teach.

So I think just starting a space where you can talk about problems, whether that's your Twitch stream, whether that's a Slack channel where you all decide to maybe go through a set of tech lessons, whether that's a Twitter Space where you're just all like, well, we're going to do this one five-lesson course that's supposed to take an hour. We're going to do this tonight, three hours, and we're all going to talk together. I think that can be a wonderful way to get exposed to new people who might be mentors or might just be lateral connections.

I think building mentorship is a process, like, over time of how you show up, and people will see that you are showing up in a way that is holding space for other people. If you're not a holding space for other people type, sometimes the thing to do is for you to publish your project in public, whatever this is, and let people gather around.

And something I wanted to add about being in public is going back to touching on some other issues is don't try to be exactly like the influencer in your area. Just be your best self. Bring your best self and get people right next to you to appreciate you.

Lauren: That is really lovely advice, and I think it is a daily practice that we need to say to ourselves sometimes, too, and that's okay, or remind ourselves, I suppose.

Danny: Rynn, let me ask you, how does your job change when things come to open up again? Can you completely do your job from home in the comfort of your space? Or do you have to go out and be within the community in person and do things like that?

Rynn: It's a mix. So different community management positions have different mixes of this. For example, if somebody wanted to get into community management, one way that a lot of people get in is being Yelp city hosts. And if you are a Yelp city host, you are at a different event in your city every night, driving folks to sign up for Yelp. You go to a bar and get the patrons in the bar to write up reviews. That's an example of a community management job that is very much out and on the road.

And my job I could still do a lot of it from home because the reality is we're global. A lot of folks can't connect in person anyway. And I think it's about figuring out what's the right balance for you and seeking out that job. Maybe you do want to travel. Maybe you want a job that's 25% travel, and you go to a different technical conference every month, maybe you don't. That is okay.

I would definitely say developer community is a way to connect to other developers all the time, even when you're at home or whatever. So I highly recommend this career track if you're interested in DevRel and don't want to hit the road. I definitely hit the road sometimes when I choose to, but it's not my key OKR.

Danny: [laughs] Is there a piece of advice? Let's say I'm listening to this in my car right now. I'm feeling hyped. I'm hearing you talk of all the cool things, and I need one more piece of information, one more couple sentences to be like, I'm going to go join a community. What would you have to say? What do I need to know? I want to learn more.

Rynn: So I think really my best tip about community is, again, go out and experiment with different communities. Don't be afraid to try different things and jump around. Don't feel bad if you don't succeed or don't really connect with one community. Understand that the next community is going to be different. Go ahead and focus as much on am I excited about the technology as am I excited about the people and the way that the people communicate with each other?

And have fun. This really should be joyful. I appreciate that maybe you're more introverted, and this is challenging for you. And maybe you have to set a goal that you're going to go out and try to engage with one community a week and reward yourself with some thinking time after that where you don't have to talk to people. But when you find the right community, you will know it because you will enjoy it.

Lauren: That is beautiful. It's a great way to, I guess, wrap up our conversation. Rynn, thank you so much for sharing your insights, your experiences, and your wisdom with our Launchies community today.

Rynn: Thank you both so much for having me on the show. It's been great.

Danny: All right, everyone. So we had referenced a call to action before in Episode One, and we did in Episode Two, but it's kind of mixed in. So I'm just going to rephrase it.

Lauren: Sure. Do that for listeners. I love that. [laughs]

Danny: Say it again. So today's call to action is to sit down and list what are the key things you're looking for within a community that you want to join? And share them. Share them with us on Twitter, even though I got some beef about Twitter. [laughs]

Lauren: Let's brainstorm other places people can share them. How about in our podcast reviews? Give us five stars and list out those qualities, and we'll read them on the next show. Why not? I'm sure there are others. That doesn't have to be the only one. But oh, I know. They could join the New Relic community Slack. The link is bit.ly/nrslack. So that's bit.ly/N as in nuanced, R as in...oh, Relic. I could just say as in New Relic. [laughter]

Danny: Nuanced Relic, it's actually a new release. [laughs]

Lauren: Come on, stop. That is not how someone should read out a link, holy cow. But okay, you get what I'm saying. Actually, just go look at the show notes because you might not understand what I just said.

Danny: Oh my gosh.

Lauren: But join our community in Slack, and let's have a conversation there because that would be a great place to meet other folks that are enthusiastic about this sort of topic. So yeah, that could definitely be a place to encourage the dialogue or Twitter; that's fine too. [laughs]

Danny: And our Twitter would be @newrelic Twitter. And be sure to follow our personal handles. I'm @muydanny.

Lauren: And I'm @lolocoding. And we also have a conference called FutureStack coming up. The CFP is open, and the deadline for submission, I believe, is March 1st. So be sure to go check that out and apply to speak or register to attend. Love to see you there. But, Danny, this has been such a joy today. I have loved today's episode.

Danny: So much fun.

Lauren: Thanks for, as always, being a phenomenal co-host.

Danny: Aw, this is only Episode Two. You're getting me all emotional; come on. [laughs]

Lauren: Episode Three, I am stoked to continue these conversations. You want to give a little preview to listeners?

Danny: Yeah, so Episode Three is going to be all about finding where to apply. And so obviously they tell you, "There are so many jobs out there. There are tons and tons of jobs. You'll be able to find one." But it's hard to narrow it down. What am I looking for? What is the company that I'm interested in?

Lauren: It's the blank page syndrome when someone is like, oh, I'm overwhelmed about where to apply. And someone responds like, "Oh, everyone's hiring." It's like, well, that's not helpful. [laughter]

Danny: Yeah, you're like, okay, but do they like me? Are they cool? Am I going to like being there?

Lauren: Yeah, exactly. And we'll also touch on some evaluating, how to evaluate a company, how to research employment and business practices. And I think it's going to be a cool conversation, so yeah, stay tuned. But with that, thanks, everyone. Thanks for tuning in for another week and another episode of Launchies.

Danny: Take it easy.

Lauren: Bye.

Tangible Goals – Addressing The Why of Things with Nočnica Fee

Mandy Moore — Wed, 23 Feb 2022 13:47:45 +0000

Aisha Blake, talks to Developer Advocate at New Relic, Nočnica Fee, about how the technical field is a 50/50 split between people writing code and people doing a thing often overlooked: operations, and in order to learn a skill, you first have to understand all the individual components of that skill. You should always have some tangible goal you're trying to get to, and changing strategies to get there along the way is a-okay!

Give us a follow: @PolyglotShow

Tangible Goals – Addressing The Why of Things with Nočnica Fee

Polyglot

Your browser does not support the audio element.

1x initializing... ×

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Aisha Blake: Hello and welcome back to Polyglot. I'm your host today. I'm Aisha Blake, and I am Lead Developer Relations Engineer at New Relic. I'm really, really excited today to talk with my guest, Nočnica Fee.

Nočnica Fee: Hey, everybody. This is Nočnica. I do developer relations also for New Relic. You might know me from the live streaming shows at Nerdlog where we talk about product updates or the uptime where I talk about product updates, but it looks certainly better because it's pre-recorded. It’s every month.

Aisha: [laughs]

Nočnica: I do a lot of live streaming stuff, do conference talks, do all kinds of fun things. And I'm excited to come on today. We were hoping...we were talking about topics. We're like, what are we going to talk about?

Aisha: Yeah. And I feel like, with you, there are so many options.

Nočnica: So back in the day...you can find me everywhere as ServerlessMom. But these days, serverless is not necessarily my big focus. So we have a lot of stuff we got to talk about, like cloud engineering stuff.

Aisha: I'm excited. Certainly, I've learned a lot in my time at New Relic, but that's not my home. And so I think I love the idea of starting kind of talking about what your path has looked like. And maybe we'll branch off from different parts of your own journey and go from there. And I'll have lots of questions for you.

Nočnica: What you see, right? You see, people talk about as a sort of placeholder for talking about working as a job in technology is they say, "Oh, well, I don't want to learn to code," or "I have to learn to code if I'm going to go do this job. If I'm ever going to stop sleeping in my parent’s basement, I have to learn to code," because the economic system has continued to grind people down.

I often say when people are depressed about how they are with money, they're bummed. They're just, "Oh, I buy too much delivery food or something." I always say remember that in your parents' generation, people who were bartenders bought houses. So obviously, we want to have financial security, and we'll want to try for it. But don't forget that the system isn't really in your favor like it used to be. I don't know, take it with a grain of salt, but it's true. So making it what you will.

So we often say, "Hey, just learn to code," and that's a standard. But even when people are pretty serious about they want to have a job in technology, they're very often being told, "Hey, go learn HTML and CSS and stuff and use that as a pathway into software and web development."

Aisha: Absolutely

Nočnica: And you occasionally hear, "Oh, I'll work in maybe...or I'll do something related to cryptocurrency." That's the big one right now. But all of these other jobs that exist in software really don't come onto people's radars. And part of that is the soft skills stuff like I do where it's like, oh, there's developer relations, and marketing, and growth marketing, and sales, all these things that are like ancillary jobs to the technical field. But the other thing is that the technical field is about 50/50 split between people writing code and people doing this other thing that no one talks about called operations.

Aisha: Yeah. And I think that that is true of so many people's entry into the industry as a whole. You have a handful of very, very visible options. And so that's what you gravitate towards most of the time. Very rarely have I had someone come up to me and say, "I am really interested in operations. I've heard about it. I don't really know what it is." Usually, if somebody has a more specific path in mind, it's because they know somebody, and they've seen them doing this thing. And they're like, that sounds like it could be right for me.

Nočnica: Yeah, there's a pretty common pattern that's like they got a very entry-level job working on a help desk. And then they did some administrator stuff with the UI, then they got asked to do some administrator stuff with the command line, and they're moving into it. Often when you're working on that help desk, you're working next to the person who's sitting there sweating in the server room. And so you often have that sort of guide.

So you don't get someone just walking and saying, "Hey, I want to become a Linux administrator, and I'm just doing that based on Google searches. And how do we get started?" Usually, they're saying, "Hey, I'm trying to learn Python," or "I'm trying to learn this other language." It was interesting for us, I think, at New Relic, we often are guilty of when we want to talk to people who are starting out; we kind of do the same thing. Like, hey, let's come and teach you Python.

Even though New Relic is a production monitoring tool, somebody who writes Python all day probably doesn't care how their code runs in production. That's really not their job. The job is to make new features, not to keep track of is the memory running out on our main servers or is the code performing well in production? So okay. So let's talk about it. Let's talk about that getting started. Because one of the things...Lord, forgive me for the things I'm about to say, but I've been spending more time on reddit.com. So I'm sorry.

Aisha: [laughs]

Nočnica: If my family and loved ones can hear me saying this, I'm sorry. I know I said I quit. I know I said I would stop. But you can't. Oh, you just can't. It just keeps dragging me back.

And the question I see quite a bit is like, "Hey, I'm trying to get started with Kubernetes." This is like, "Hey, I bought a laptop. And I've searched for tutorials, and I'm trying to get started with Kubernetes." And that is not going to work. And I would encourage somebody to do anything that their little heart desires. When you want to do machine learning right out of the gate, great. These are practical engineering challenges. Anyone can get started doing them. Obviously, it will take you a long time to get a lot of knowledge in a really obtuse area.

But saying, "Oh, I want to get started with Kubernetes," I try to think of the analogy...I can't think of a perfect one. It's sort of like someone saying, "Hey, there's an industry where you repair cars, and I want to get started by altering the fuel mixture in whole fleets of cars," where it's like, "Well, do you know how a carburetor works?" Like, "No." "Do you know how a fuel system works?" "No." That's not going to work, right?

Aisha: Yeah.

Nočnica: Orchestration is one of these things that exists in the world of software and actually not that applicable in the real world necessarily, but there's just, I mean, I suppose one way to think about...I'm just thinking about the literal definition is orchestration is like you cannot say, "Hey, I'm interested in music, and so what I want to do is try to be a conductor."

Aisha: That's exactly the analogy I was thinking of. Like, if you don't understand music theory...

Nočnica: Yeah, I got a little baton, and I started waving it at crowds of people, and they're not playing any Sousa at all. [laughter] That's actually a way better analogy because we don't expect that a conductor is the best oboist or even a concert oboist. But obviously, they must understand a great deal about the individual components. So I was thinking we could take a minute and talk about how someone could get to that point because I can't teach you everything in a half-hour podcast, or I don't know how long this thing is supposed to be; 45 minutes?

Aisha: [laughs]

Nočnica: But there is a curriculum that you can follow that sort of says, hey, here are the skills I want to check off, and here's where I want to be next, and Kubernetes is on there. It's just it’s one that there are two or three other foundational skills before you can get started.

Aisha: Absolutely, let's do it.

Nočnica: Let's jump in feet first. So if someone asked me...I tried to make some notes and sort of say, you know, this isn't something authoritative. And there may be better versions of any one of these resources. I'm sure we'll link to these in the show notes as well.

Aisha: Definitely.

Nočnica: So the main thing is if we go with that conductor musician analogy, is you have to understand the individual components of any kind of cluster, which means you have to understand a Linux machine. So until you get up to the Kubernetes level, you really shouldn't have to spend any money at all except maybe to buy a book or if you have no working PC to get a working PC.

But I think a really good first goal is to run a Linux machine generally as a virtual machine or on a Raspberry Pi and one without a UI. So just from the command line, you should be able to control it. And that feels pretty daunting to start with. You're just looking at this little text prompt blinking and saying, "Hey, what do I put in here?"

Aisha: I'm yours to command.

Nočnica: Yeah. What to do, right? One thing that's interesting is that I actually think this got a little easier now because it turns out that a lot of people who are getting started in technology now aren't that familiar with Windows or OS 10. So they don't have to unlearn the file GUI because they're actually not super familiar with it at all, like a file structure and a directory structure. They can just learn that new now.

It is kind of fascinating to be hanging out with somebody much younger than me and realize that they, too, like my parents, don't understand where a file goes when you download it. They can't necessarily find the file that got downloaded onto their computer because they're used to their phones and their tablets and the other interfaces that don't give you a file browser.

Anyway, so a really good place to start there's a textbook called the Linux Command Line by William Shotts. It's free. It's at linuxcommand.org. And it is a fantastic place to get started. It starts right from the beginning. It's like, hey, you're looking at this command prompt. What on earth is this? What do you do? And it's also a really good start because that book is like 800-900 pages long, or I don't know how long, maybe it's about 300 pages long. But it's long. And there's no universe where you would master that whole book before you got on to the next thing.

Aisha: Certainly.

Nočnica: That's a really good starting place is to say, hey, we want to understand this. But we have to know some certain point to say, okay, I get it enough to start with a little project. So I would say (Give me your thoughts on this.), but I would say a really good idea would be hey, what we're going to get to you in a couple of steps is we're going to get to a little Linux server, maybe just running on our laptop, that is running some kind of software and is responding to requests with some piece of software that we wrote.

Aisha: I feel like that's something...I want to say tangible, but that's something you can sink your teeth into. But it also gives you all the most basic pieces. And when you start to understand how those pieces fit together, then you're able to start building that mental model that you build off.

Nočnica: I think it's fair to say you want to have a tangible or a measurable goal because when you're first learning the command line, it is frustrating. You forget stuff; you go back. And it's hard to say at first, like, do I understand this? Yes or no? Am I further than I was before? Yes or no? It's tough to know that exactly.

And that's worth acknowledging because when you ask yourself later, like, is this a good use of my time? You should have some tangible goal you're trying to get to. So I think it's reasonable to say, hey, I'm going to give myself an amount of time, maybe six weeks, to be able to stand up a virtual machine on my computer that's a Linux server and that is running a little bit of Python and is responding to requests. It's like if you're working hard and you got kids and all this stuff, give yourself six months. It's not that it has to be on some timeline.

But it's also okay to say at the end of that, hey, did I get there or not, and do I need to change strategies? So that means one of two things if you get to that point is either you need to change strategies. Like, I always say it's great to start with resources that you can find for free. I personally never would have become a developer if that was the path that I was taking. I would have just never studied these things and gotten there. It's also okay to say, "Hey, turns out this isn't for me," right?

Aisha: Absolutely.

Nočnica: Yeah, it's not the end of the world to say especially, (well, stage 2 we'll get to) but especially if you really try to make a project, especially if you're accountable to someone else, and you have a list of features, and you need to code those up and deliver them, it would be great to try and do that once or twice before you jump into this career to know if hey, is engineering full time? Is that something that I would actually enjoy or would, in fact, hate? I think it's worth asking yourself that question.

Aisha: And I think your point about having a timeline even if it is I am choosing this timeline, and it is entirely on me, and no one else is relying on me. All of that is fine as long as you stick to it. Because in that sticking to your own personalized timeline, that gives you the opportunity to reevaluate and ideally without the shame that I think a lot of people tend to feel when it's like, oh, I don't know what I'm doing. I don't feel comfortable doing this. I'm not sure if I like this. All of that is okay.

Nočnica: Yeah, absolutely. I think it's also worth it to say, hey, if I was in a CS programming college, this would not be totally self-motivated, and I would have check-ins. And you might ask yourself how you can replicate that and say, hey, is there someone else I can have accountability to? Can I break this up into smaller chunks?

A great thing about having a text like Linux Command Line is that it is a really good way to say, hey, I have sections 1,2,3,4 here, and I want to move through these sections instead of taking this huge phonebook of information and saying, well, I'm supposed to be done with this in six months. And it's really hard to pat yourself on the back at the end of the week because you're not going to be very far through that in that amount of time.

So once you've gotten to the point of hey, you're kind of running this Linux server, running some Python or some Node code on that server is kind of the next step. And so you can find this is probably where people do know like, yeah, I can find a lot of tutorials to do this. You want to stand up code that is doing something really simple because you're not targeting being a full-time coder.

You just need to get familiar with once you write a piece of code; how do you make sure that when this server gets requests, it runs that code? So that's the concept of generally a web server is that it's taking in requests and it's going and saying, okay, this came in in this way, and therefore, I'm going to run this piece of code, and the code is going to tell me how to respond.

So ideally, you get to the point where you send in a request, and the request has a payload that's the number 10, comes back, and it gives you the number 20. It always multiplies those numbers by two or adds ten to them; however, you want to do it. I'm not going to define your math, but that's where you want to get to. That's now you have the basis for moving on to operations.

Now I will say I do not think that HTML and CSS, if you're targeting operations, is a good use of your time. So they are incredibly complex and erudite technical areas that you can learn for years. I think even a basic knowledge of how those things work is probably not something that you for sure have to cover early on here. You can get it sometime. And if you're interested, you can totally study it. But if you're really sweating HTML and CSS for six months and your target is to be in IT and operations, you're probably taking more time with that than you need to.

Aisha: Totally agreed. Now, if you're talking about I want to be a web developer, and you are ignoring those technologies in favor of JavaScript, that's a different conversation for perhaps a different podcast. [laughs]

Nočnica: Yeah. No, really worth saying. Like, anybody who says, "Oh, I'm a full-stack developer. I don't know any HTML and CSS," or like, "Hey, I make code that creates websites, but I don't understand HTML and CSS," you're shooting yourself in the foot there. That's not a way to do things. In the same way that Linux Command Line will teach you this or other resources will teach you this about file permissions, you want to do a little bit on that. You want to at least get to the point where you can edit and control file permissions in Linux because if you can't, you don't really understand that pretty basic component of how this stuff works.

So once you've got that little server again, it can be running on your laptop. It can be running on AWS. It can be running some other place, but you should be able to be in control of it. Now it's time to get into this operations side of it. So one very solid place to start the CNCF has like, I mean, it's a little silly, but it's Kubernetes for Children. It's like their Phippy page, P-H-I-P-P-Y, Phippy. And it's like a storybook for children, but it's in a very readable level to be like, what is it that we're doing when we're talking about clustering, containerization, and strategy? So that's really good to check out.

The next one would be Google. If you go to sre.google their books on how the SRE role came to exist, Software Reliability Engineer (SRE), right?

Aisha: Yes.

Nočnica: And that's from 2016. It is not out of date, though. It is still information that new organizations need to read and hear about. And that's really critical to do because, especially as you do engineering every day, you're not going to talk about architecture, organization management, and why things work the way they do. You're going to hear a lot more like, that's not my role, or that's not my responsibility. And we have these other people do it. But you're not really going to hear why.

And most shops are working in a way that these Google Books on SRE are really going to cover why that is this way. So again, link in the show notes to that, but I think it's worth reading. They're not long. And if you've gotten to this point, technically, they should be pretty readable what they're saying. They're not technical tutorials. They are high-level tutorials about strategy and how you handle problems, and how you handle uptime and stuff.

Aisha: I love that. Addressing the why of things is so important. And I think when we're getting into a field, it's really easy to focus on the what and the how.

Nočnica: Yeah, and I'll say also when it comes to organizational responsibilities to what makes good code, good software, good tools, if you go on a community site, even a relatively non-toxic one like Dev.to or what have you, you will find information that is dead wrong all the time. It will be the popular wisdom is like, serverless isn't that great because I can just build it myself. That's wrong. [laughs] But you find it every day. So try to consider the source when you're learning tech stuff, and that kind of matters. And we're not going to have time to cover this here.

But you don't want to go into interviews with a lot of odd toxic beliefs because, frankly, a lot of engineers these days can sniff that out pretty quickly. So if you have stuff to say like, "Well, I'm a really rational person, and a lot of people are really irrational. I care about facts, and facts is the real thing, and other people don't care about facts," eh, that’s...

Like, "Oh, I only write really good software. And a lot of people are too lazy to write good software, but I'm not." These are red flag emoji. So it's totally cool to read this stuff, especially the social media cadence makes it fun to read through this and like, oh yeah, hot story. Let's talk about it.

Aisha: Sure.

Nočnica: When you really try to see what's true and what's not, go back to something like one of these books. Go read something that Kelsey Hightower has written. Go read something that Charity Majors has written. Go read something that someone who actually works in the field and whose face is attached to their words and is not just making anonymous comments about what have you. I had a friend who shared one of their projects on Hacker News, and he shared an article that he wrote.

Aisha: Bold.

Nočnica: Somebody replied on Hacker News. "I looked through the project that you worked on, and one of the pull requests says that a bug had existed for over six months before you fixed it. So I'm not going to read anything you write because you're too stupid."

Aisha: Oh my God. [laughs]

Nočnica: That's easy enough to do when you're on Hacker News, and your username is weedlord290. As long as you can make just random, anonymous comments and no one can see your GitHub, that's for sure.

Aisha: [laughs]

Nočnica: By the way, literally every person who leaves comments like that their GitHub is a white sheet of paper for the last three and a half years because they've only done closed-source commits to their poorly run software shop. I guarantee you. But yeah, you want to make sure that your high-level industry stuff is formed by somebody who you actually respect, and what they're saying makes sense.

Okay, so you have that layout. Now it's time. Now it's Kubernetes time. And so I was just mentioning Kelsey Hightower. Kelsey has a tutorial called Learn Kubernetes the Hard Way. If you're capably running your own little hobbyist Linux server, then you should be ready to follow Kelsey's tutorial and get something from it.

If you go there and you hit a wall, and again you can run a Linux server on your own pretty well, then you should feel really comfortable posting either issues to Kelsey's GitHub or asking questions on Stack Overflow or Reddit or Dev.to. Say, "Hey, I'm stuck here. Can I have some help?" Because you have a pretty good basis. So, of course, you're going to get stuck. It's a complicated process. Now you have some understanding of what on earth you're doing.

And so that I think is the path to say, hey, I want to get that understanding. And the most important thing to keep in mind is that there absolutely are people who understand almost all of the Kubernetes API, understand almost every single operator command, understand kubectl really well, do all that stuff. Those people currently make $400,000 a year. That's what they're doing. And most listings are "Hey, we need somebody who understands anything about Kubernetes, can deploy it on any kind of public cloud." Those listings have been open for nine months.

So you really need to let the pressure off yourself to be like, I have to be really perfect at this. Lots and lots of shops now are hiring competent back-end coders, people who understand Linux to a degree. And then they're like, "Okay, now we need you to understand this Kubernetes stuff." And that's just the reality is a lot of places are training entirely in-house. Having some familiarity, being able to stand up and take down a cluster, trigger some scaling, and read some events, that's a really good start to say, "Hey, I'm going to go make a case for why y'all should hire me."

So take as much time as you want on Linux administration and understanding that. Deeper is better, and it's great to get some knowledge, getting all the way to the Kubernetes space. Of course, the other reason I'm soft pedaling that is, first of all, a lot of places will hire you with cursory knowledge or beginner's knowledge. Also, frankly, what you can simulate yourself in your little private cloud that you're spending five bucks a month on is --

Aisha: Exactly.

Nočnica: Yeah, the point of implementing continuous deployment, continuous integration, doesn't really make any sense. So like, you see CI/CD alone. So there's just going to be a level that, like, okay, I can't simulate it at all. So even if you spend an extra year really leveling up on that stuff, it's not necessarily going to be that applicable. So better to say, hey, now, it's time to get some real-world experience with this.

Aisha: Makes a lot of sense. So I'm here now, and I'm looking maybe what are some things to look out for? What are some red flags? How should I be looking to level up once I have found a team and I'm working at a larger scale?

Nočnica: So one thing I would say is that it is more fun working for a startup, and it's easier to get a startup to take a chance on you. I would say it's worth considering if you really are just starting out that that startup is not going to generally have the resources to train you effectively.

If they're saying, "Hey, Kelsey is amazing. She knows everything, but she does need help. She's going to be training you an hour a day." Fantastic, go take it. That's not usually the situation the startup is in. Normally, there are a lot of fires that people are putting out. It's a lot of work that people are doing. And so when they're hiring, they're hiring somebody to work full-time in the field. So that can be a little tougher.

Now, obviously, an enterprise can also be very bad at training people and have no plan to train people, but it is more likely that those resources are going to exist. And I would say probably the worst thing to do first is, hey, nobody here knows anything about this cloud, about AWS, Azure, whatever, and nobody knows anything about Kubernetes. And we need you to do it all. And you do see that quite a bit.

You see a lot of wishful thinking listings that say, "Hey, probably we're in a bad state, maybe even we deploy the cluster, and we're even sending production stuff to it, but we do not know how to manage it or control it. And we need someone to get us unstuck." And what those people should be doing is going and spending half a million dollars on a consultancy to fix the problem.

Aisha: Exactly.

Nočnica: And instead, they're trying to hire someone and offering them $64,000 a year, so good luck. That's its own category of things to look out for. It's great to believe in yourself, but do not go take a role where you're going to be the apex of knowledge as your first or second role. Ask questions right away about hey, what is the plan for training and skills growth? Who's here? And how much time out of the day are they going to be able to commit to it? Or is it going to be when I get to it, I'll only answer a few Slacks here and there? So yeah, I think that's the basic.

There's really great advice out there about pay and stuff. Frankly, as a white woman working in the tech industry, I really can't give you a lot of advice about that stuff. You're going to experience very different stuff coming into it than I will if you're not from this white West Coast background. So I won't speak to any of that. And also, I think I will say your skills leveling up are the important part. Probably that 10% pay or something is not going to be worth very much if you're not growing your skills in some other role.

So, if you're in that situation and you want some real talk about it, hey, come message me. I'm at twitter.com/Serverless_Mom. And I'm happy to chat about it. I get DMs pretty frequently, like a couple of times a week, that are like, "Hey, I have these roles. What should I take?" and stuff. That's pretty gratifying. It's actually super nice to do. It's kind of a fave. I can't speak to all the other career path stuff but definitely look for a place that's developing your skills.

Aisha: Absolutely. And I think that makes sense just any kind of engineer really, look for those opportunities to grow in the areas that you want to grow in. And, ideally, have some idea of where you want to take things, but I would say be open as well. There's always the chance that you're going to try something, or you're going to see somebody working on some tangentially related thing and be like, you know what?

Nočnica: That's what I really want to do.

Aisha: That sounds like a lot of fun. And even within the same role, there are hopefully going to be opportunities for you to try that thing and say, you know what? Actually, I like working over here with Angie. I'm going to do what Angie is doing and learn about that. Or I'm going to go over here and work with Bob for a while. And that kind of exploration becomes possible when you open yourself up.

Nočnica: Yeah. And one of the things we don't talk about or often gets soft-pedaled is people talk about what they make in dollars in tech, but one of the privileges that we really don't discuss is you do generally have that flexibility to say...hey, hopefully, the money introduces a margin to your calculations to say, "Hey, I don't have to just go make the decision that pays the absolute maximum amount of money." I can say, "Hey, this is the style of work that I actually like to do."

When I got started, I always said I wanted to move into DevRel and the more marketing-focused stuff. For a while, I needed 100% of my pay to pay my bills. I was working for somebody where you'd hand off an article to him, and he would say, "Okay, I have these notes. Come back." And then I'd be like, "Okay," and I edit it. And then he'd be like, "Oh, I have more notes now." And not all the stuff that you had edited, just other stuff. And by the time I had my second role in that field, I was able to say, "No, no, no, that's not going to work."

Aisha: [laughs]

Nočnica: The same thing happened like a year and a half later, and I said, "That's fine this one time, but that cannot be the workflow." That's maddening. You send it to me; I edit it. You edit it, I revise it, then we're done. Just come on, that's just crazy-making. And that was definitely...I was working in this highly technical field. I was writing highly technical stuff. And so there just wasn't...I was able to say, "Oh yeah, you can't do that." But if you just work in regular content writing or just any sort of…thing, you just have to deal with whatever workflow you're handed. So that's a real thing to identify.

And also, it's really real to say that's really what you're seeking when you're seeking a tech role and saying, "I want to be able to have that flexibility." Because once you've done one of these engineering roles for a couple of years, your ability to say, "Hey, no, I really like going to parties and organizing events and writing stuff, and so I want to do DevRel all the time." That's very accessible.

If you say, "Hey, I like working with customers and making deals and doing that stuff," solutions architecture is open to you. And there are 100 other directions. As long as your real happy place isn't driving a tractor across a field of corn, you should be able to use your development skills to do something fun. Actually, there are developers who work for John Deere, and then they get to drive a tractor around.

Aisha: [laughs] That's true.

Nočnica: I knew somebody once who said that his dream job was...there was like a Java developer for Caterpillar. And in the afternoon, you would go test your software by moving gravel around and stuff.

Aisha: I live in Detroit now, and I have known a whole lot of developers who work on cars, and it's not even always directly relevant. Sometimes it's just like, yeah, I got to go and ride along at the Ford Test Track, and I'm like ooh. [laughter]

Nočnica: I'm terrified because that to me sounds like, hey, we all got an opportunity after we wrote our code to die. [laughter] That's what I like.

Aisha: Definitely an adrenaline rush for sure. [laughs]

Nočnica: I was talking to one of the Serverless AWS Heroes. And he's got this car where he's like, "My truck is being nice, and they're not making me install a roll cage in the car because it goes this fast, and it really should have a roll cage already." It's stressing me out hearing that. All right, so what else do we need to make sure people know?

Aisha: If you have a bead on community shout-outs.

Nočnica: So join Portland Containerds. PDX Containerds on Meetup. You can find the links on my Twitter @Serveless_Mom. We meet up every month. It's a pretty fun one. Take a look at Dev.to if you haven't, especially if you're trying to get started in the industry. Yes, we mainly talk about JavaScript and PHP, but I promise that there are also AWS people and other people on there. What else do I recommend people do? That's it.

Get a Twitter account and follow some people that you like. Unfollow anyone who's tweeting a bunch of...anybody whose face is inside a hexagon on Twitter just move on. I love you, and I want you to have joy in your life. Did you follow an account two years ago that posted really cool art and animation, and they suddenly started just posting weird stuff that looks like it's from Second Life? Just unfollow them. Don't even worry about it. Give yourself peace. Give yourself the gift of peace. Just move on. Stay off Reddit, kids. No, I don't know.

Aisha: [laughs]

Nočnica: Here's something that I'll tell you. Really early on, it can be great to share your path and what you're learning. If you have career questions, it is fine to post on Reddit and see what people say. You might get some helpful advice. If you have early code to share or stuff you want to show people, keep it off of Reddit and Hacker News and go post it on Dev.to.

Because at Dev.to if you post here's how to store everyone's passwords in plain text, you'll get comments back saying, "Maybe don't do that." If you post very capable file compression algorithms to Reddit, people will comment on it telling you that you should burn your computer in a fire. I really mean this.

Share your early career stuff but think about the platform. Look at the culture that you're interacting with and make sure that you're picking one that is supportive. So I very often find great people on Twitter. You can find great people on Dev or Dev.to, great places to start there. And yeah, just go read the comments on other sites and don't take their criticism or weirdness too personally.

Aisha: I feel that, yeah. And Twitter and Dev are also really solid places to look for mentorship, which does not necessarily need to be a one on one relationship. You want to look for people who are doing the kinds of things that you want to do and see what they're talking about, see how they are thinking about building their own skills. Look at the things that they have already done and see what parts of that journey are interesting to you.

Nočnica: I really feel that. I will say the last thing if you have access to it, especially if you feel that you are in a job now that is making you really miserable, if you have all your bills paid and you still say, "I need to change careers, or I'm really, really sad, or I'm really, really struggling," get therapy. Try to get some time to talk to somebody about it.

Because I was certainly somebody who gave herself a lot of opportunity and a lot of privilege and ability but was still just absolutely miserable, so go talk to somebody. It does help, and it's not an admission of failure. And then I promise that the feelings of success and actual success will follow that. So on that extremely real note -- [laughs]

Aisha: All right, I want to thank you so, so, so much for joining me and having this conversation. I really appreciate it. And I feel like you came away with some super actionable things for folks, and so thank you.

Nočnica: I'd love that. My only regret from this podcast...please do go look me up on Twitter so that you can find out that I have chrome teeth. I will tell you that no one who talks to me on video can think about anything else when they talk to me. So it's just a real disappointment that you don't get the full experience with audio. But yeah, look up my photo and just imagine. Thank you so much, everybody.

Aisha: All right, thank you so much for listening. Be sure to check out our other podcasts, Launchies and Observy McObservface.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.

Resumes and Cover Letters with Chloe Condon

Mandy Moore — Thu, 17 Feb 2022 14:01:13 +0000

This season, we’re helping you level up your interviewing skills! Each week Lauren Lee, Danny Ramos, and industry experts will offer advice on navigating career progression within tech.

👉 Give us a follow: @LaunchiesShow

Resumes and Cover Letters with Chloe Condon

Launchies

Your browser does not support the audio element.

1x initializing... ×

Topics Covered On This Episode:

Objective Statement: Write or leave out?
Make Your Resume Pop
Resume No-Nos
Getting Personal
Playing The Algorithm Game: Is listing every tech keyword I can think of in hopes of making it past a machine learning screen a good idea?
Getting Feedback
Including Non-Tech Work
Keeping Things Up-To-Date

Links:

CTA (Call To Action):

Write a hook for your cover letter that grabs the attention of the recruiter and/or hiring manager.
What is the most important feedback you’ve received on your resume?
Join the New Relic Community Slack!

👉 Follow Launchies, Lauren, and Danny on Twitter!

🚨 FutureStack 2022 call for papers is now open! 🚨

Sign up to share your successes and learnings in a hands-on lab, workshop, or deep-dive session to help your peers advance their observability game.

Transcript:

Danny Ramos: Launchies is a tech podcast dedicated to helping early-career developers or soon-to-be devs.

Lauren Lee: We'll share insights on how to navigate these early opportunities and bring on experts from the tech industry to give advice on general career progression.

Danny: In the first season of our show, we focused on how people launched into their tech careers.

Lauren: And now, in Season Two, we want to offer advice on your career progression.

Danny: The next 12 episodes will be all about the interview and landing your first job.

Lauren: Welcome back, everyone, to Launchies. This is Episode One. We're so stoked to have you here listening.

Danny: Here, yeah. [laughter]

Lauren: Listening in your earbuds, I don't know.

Danny: Oh my God. I'm just cracking up because we were talking, having a normal conversation, and then you pivoted into your radio voice, and I --

Lauren: I did. I went into like, hello, welcome to Launchies. [laughs]

Danny: I was impressed. You didn't answer in the interview that we had but did you ever do any performance or performances?

Lauren: Oh yeah. I was really into high school theater, really, really, really into it. I went to college thinking I was going to pursue it. And then got to Los Angeles and was like, okay, I don't know that I'm going to make it [laughs] and got really nervous about it and then I became a teacher. Like, then I would start taking a bunch of education classes.

Danny: Did you go all the way to LA for that? Thinking that?

Lauren: Yeah, that's why I went, yeah. I went to undergrad out there and thought that that was what I was going to be doing. But I don't do super well with rejections, so that wasn't the right career path for me. [laughter]

Danny: Wow.

Lauren: And then I decided to become a freaking coder. And this is what we're going to be talking about in today's episode is like it's a numbers game. There are going to have to be some nos before you get to yes. Or maybe not even explicit nos just when you're applying to jobs, and you just don't hear back, or you don't get to even the first round of an interview.

Danny: There's definitely that gut-wrenching feeling of just being turned down or just left on read. You're like, I've been left on read 200 times this week.

Lauren: [laughs] Oh my gosh, 100%. And the comparison is very real. I've heard it been made before of like; searching for a job is like online dating. You just have to weed through the bad ones. [laughter]

Danny: Every date with me is tight. I don't know what people are talking about.

Lauren: Oh, okay, sure. Great. [laughter] I'm really excited for folks to listen to this conversation today with Chloe that we have because she really genuinely gives some incredible advice and is so gosh darn charming while she does it.

Danny: Chloe really does rule. And so I was really excited that we got her to be in the first episode and brought in her expertise in general but also her recruiter mindset when she was a recruiter.

Lauren: Yeah, that lens we were lucky to get that. I guess I remember my first resume when I was graduating my bootcamp. I really leaned heavily into the projects that I created while in my bootcamp, all my repos, and everything that I had built. But then I realized that everyone that I graduated with had the exact same resume.

And so, looking back on it now, I didn't make it pop. I didn't make it stand out. And it could have been a carbon copy from anyone that had gone through the program before. And so yeah, I feel like I’ll have a lot of takeaways from our conversation for sure.

Danny: Absolutely. And just so everyone is aware, this first episode, we're going to be talking about resumes, the cover letters, do's and don'ts, and really just some great tips from Chloe on how to make your resume pop, how to make your cover letter, pop and just the trials and tribulations of beginning the whole interview process.

Lauren: Yeah, so I guess without further ado, shall we jump in? Shall we do it?

Danny: Yeah, let's start the crazy like, I don't know, I'm imagining some magical charm or something, some transition, and then it begins fluidly.

Lauren: We're warping into...okay, so music, woo woo, woo.

Danny: Yeah, curtain call, boom.

Lauren: Boom. Action. [laughter]

Danny: No one says action for a curtain call, but -- [laughs]

Lauren: You don't know that. [laughs]

Danny: Yeah, there's the other directors backstage like, [whispering] "Action." [laughter]

Lauren: I can't wait for everyone to listen to this. So yeah, cue the music. [laughs]

Danny: Our guest today is a Senior Developer Relations Engineer previously working at Microsoft, Sentry.io, and Codefresh. Before entering tech, she got a degree in Drama from San Francisco State University and worked in the Bay Area as a musical theater actress while working nine-to-five in various admin roles.

She's worked in tech in roles ranging from video game, customer support, virtual assistant, office manager, executive assistant, and recruiting. A Hackbright graduate and mentor to many non-traditional background folks in tech, she's passionate about bringing more artists into tech and more tech into the arts. Her name is Chloe Condon. Chloe, welcome to Launchies.

Chloe Condon: Hello, I'm so excited to be here.

Danny: Yay.

Lauren: We're so happy to have you, Episode One.

Chloe: Oh my gosh. I'm honored. I'm truly a friend of the pod. I'm the first guest. [laughter]

Danny: You are going to set the standard for the whole season. No pressure at all.

Chloe: Okay, good, good.

Lauren: That's so much pressure.

Danny: Yeah, yeah. If this is not a good episode, that's it. I'll crumble.

Lauren: [laughs]

Chloe: Okay. Well, you can count on me.

Lauren: Okay, so let's dive into today's topic, I suppose. We are hoping to cover the beginning of a journey someone is navigating as they're hoping to find a job, and they're putting together a resume, maybe a cover letter. We'll dive into that too, of course, you know, how to write them, what stands out? How to pass that HR screen, I guess maybe too. Where should we start, y'all?

Chloe: Oh my gosh. There are so many angles to start from, I feel like. Something that I think about a lot, and maybe Danny can speak to this as a performer and maybe Lauren. I don't know if you ever did any performing art stuff growing up. But I think my biggest epiphany was when I was on quote, "the other side of the table."

As in I was an actress, and I was auditioning for, you know, when you audition in a musical, there's the casting director, the director. It's like American Idol. There are people behind the table, and it's very vulnerable. You go in, and you sing, or you do a monologue. Or you have to dance, which I'm a terrible dancer. [laughs] I hated dancing in auditions.

But once I was on the other side of the table, I was like, oh my God, I want everybody who comes through here to be good. You never want anybody to be bad. When you watch American Idol, it's fun to watch the bad people, let's be honest, [laughs], but that's not real life.

Danny: I mean, that made the show great.

Chloe: In real life, when you are a recruiter or when you are someone interviewing someone, you're like, I want the best person for this role. And I always think of that now that I interview people for roles. And I have interviewed people as a recruiter and as an engineer and in so many different roles in my previous life. I've never been in a situation ever in my life...except maybe if your enemy is on stage where you're like, I want this person to do bad. You know what I mean? [laughter]

So when people tell me they get nervous for interviewing, or whiteboarding is terrifying, and we should all address that, whiteboarding takes practice. And you need to take at least a month to just practice that. Like, engineering interviewing is broken. However, informational interviewing you want it to go good. So that's where I always tell people to start from. It's like, you have to get your resume in, and there's like all the nuances ahead of time that, like, we can definitely talk about. But I guess I'll ask both of you have you interviewed people before? Have you ever wanted someone to do bad? [laughter]

Lauren: You're really genuinely rooting for them. You're wanting it to be a good fit. And also the opportunity to make sure that it feels like a nice, I don't know, potential relationship too. You're getting the vibe check of is this going to be someone that's fun to work with every single day? I'm going to be spending a ton of time with this person. And so it's just an opportunity really to know them as a human, I think also.

Chloe: And a fun interview is so important because you're like, I'm going to work with these people.

Lauren: Oh my gosh. Yes, absolutely.

Danny: I haven't interviewed anyone within the tech space. But I would interview a lot of people when I was working at Costco. And exactly, I would feel the same way. I was like, I really hope this person's cool, and I would want them to succeed. I guess a big problem that I have always heard from people who get nervous about the interview is that they feel like they're doing a personality test. And they feel like, oh, if I'm not chipper or I'm more of an introverted person, I'm not going to do well in the interview process.

For instance, I think of my little brother, who is very quiet, very opposite of me. But if you get him in front of a computer, he can get things done. But in an interview process, he would maybe be nervous or shy. Chloe, do you have any tips or tricks for people who feel like they're more introverted and don't know how to really...they look great on paper, but once they get to the interview...Do you have anything that can help them boost their confidence with that?

Chloe: Yeah, I guess I feel like leading from a place of authenticity is so important for everyone. And I think when I entered this space, there are different kinds of schools of thought in engineering. Some people are super serious about their work, and some people love a really quirky creative space; that's me. I'm like, I want creativity and freedom to speak to developers how I would want to be spoken to as a developer. Which I know my flavor of engineering and development is not everybody's cup of tea, and that's fine.

So I think when you're interviewing in places, just vetting the company. Like, is this company working on tools and stuff that I think is exciting? And if you can speak...I feel like passion shows through on anyone. Like for me, it's talking about Rock-A-Doodle. [laughter] But for other people, I'm sure it's like, I freaking love React, you know what I mean? [laughs] There are people who will talk about...I mean, I follow them on Twitter. They talk about React all the time [laughs] or JavaScript or open-source or whatever that is for you.

So one of the reasons I decided to apply for Sentry is I loved their website. I just loved their vibe and their energy. They had a sense of humor. They really spoke to developers how I felt developers wanted to be spoken to, with a sense of humor and empathy. And this is a tool that does error reporting and bugs. Let's dive into that. That stuff is tough. Their jobs' page, every single employee had a GIF made of them.

Danny: Oh, that's cool.

Chloe: Like a personalized GIF that they got to...and we can link to this. I think it's still on their blog. But we had an amazing content team that would sit down with you and be like, "Okay, Danny, what do you want to do in your GIF?" And some people were like, "I want to be teeny tiny and on my keyboard and jump around." [laughter] Or like, "I want to be a Pokémon Monster and throw a Poké Ball." Mine was so nerdy. I went to the theater, and I was like, Fanny Brice from Funny Girl.

Lauren: Oh my gosh.

Chloe: Because I'm not much of a musical theater nerd. [laughter] But it showed everybody's personality which I thought, oh, that's so cool. I got a sense of what this team was, which it was a startup. We were under maybe a couple hundred people, and it was very intimate. And I just loved that energy. And I was like, this is the kind of team I want to work on.

And I think people forget, especially new people, to this space or maybe if you're a junior candidate coming out of university, that you're interviewing the company too. You're in an in-demand field and role. And if you get a weird vibe from a company, interview with a different one. It's okay. [laughs] But vibe is important. Like you mentioned, Lauren, vibe is so important.

Lauren: You're allowed to gut check back almost.

Chloe: Yes.

Lauren: If it doesn't feel right, then it's not going to be a good fit. And there are so many places that are hiring, so keep on it. Let's take a step back to the place of resumes in particular. Do you have advice, oh gosh, on how to make it pop or how to stand out from a crowd? Because it probably feels like there are a ton of people, especially for an entry-level role, that you're competing against. And it may just feel like you're one in a million, almost.

Chloe: Oh my God. I should work for this company because I talk about them every day. Canva, I love you. Canva is a beautiful place.

Lauren: That’s in line with it, yeah.

Chloe: Canva is a beautiful place. I learned about them during Hackbright. I literally was like; I don't even know what this is. And they're like, put your resume in Canva; it's free. And there are all these templates, and I was like, excuse me. I have a Canva pro account. I've used it for literally the last five years on my resume.

And there's super quirky stuff on there [laughter] that I use, but there are also really professional templates. Microsoft Word has a lot of really great templates as well, if that's your jam, that are very business-y and professional. So it really depends on wherever you apply, regardless of if it's a big company or a smaller company.

Just adding more than just a font is so important, even if it's just a very subtle template. When you are a recruiter, which I was in a previous life, every single resume starts to look the same because everyone's using Times New Roman. Everyone's probably using the same base template that comes with the first one that you pick. And I implore everyone please just go into Canva, get a basic template. I swear I don't work for them. I should work for them. [laughter] I love them so much.

Danny: Yeah, this is a sponsored podcast. [laughs]

Chloe: Sponsored by Canva. I love you.

Lauren: It would be so organically embedded into the episode. [laughter]

Chloe: But truly, I can't even tell you as a recruiter...I was a sourcer; then, I worked as a recruiter, which is the career trajectory. When you're a junior recruiter, you're a sourcer which means you literally just source through like, we need a person who has these qualities and qualifications, and you just look for those roles. That's all those messages you get on LinkedIn that are like, "Hey, girl, come and apply for this company."

Lauren: Ugh. They're wilding out these days, I feel like, oh my gosh.

Danny: I just looked at my LinkedIn this morning. I was like, wow, I'm a popular guy.

Chloe: The market is very hot right now. [laughter]

Danny: I was like, my DMs have never looked like this; something must be up. [laughter]

Chloe: Truly, that was the biggest moment in my career; it was changing my title to engineer on LinkedIn. And the difference between that and having Disney Store retail and summer camp experience changed my life, [laughter] completely different experience.

Danny: Did you put that kind of stuff on your resume?

Lauren: Oh, that's a really good question.

Chloe: Yeah. So here's how I view all of this, y'all. LinkedIn for me...and full disclosure, I used to work at Microsoft, but I've been using LinkedIn my whole life, and I use that as my personal timeline. I literally have every job, every certificate I've gotten. That's just my single source of truth of where I've put everything.

And I've had it since I've worked at The Disney Store. I'm old. [laughter] That was like my first job in college. So I literally have my Chinatown YMCA experience as a program leader. I have some theater stuff on there that I've done. But that's just like something that I have. When I'm old, and I have dementia, I can be like, where did I work? [laughs]

Lauren: It's the timeline.

Danny: Yeah, when you're old and have dementia, that's what you want to know. You're like, my name? I don't care. I want to know where I worked.

Chloe: But basically, I think of my work resume how I used to think of my theater resume. And also, I should say my dad is a director, and my mom was a costume designer. So I grew up in the theater looking at resumes, theater resumes, but I know what a good resume looks like. When you see people who have agents' representation, there's a certain way that a resume is, and there's a way to make it stand out.

So people used to literally put like, "I played the Little Red Hen in preschool. It was my first role," on their theater resumes. And I'm like, girl, come on. [laughter] We don't need to know that you played Oliver. You're 55 years old. This is wild.

Lauren: So don't go that far back. [laughs]

Chloe: I would say whatever is the most relevant, maybe two most recent jobs. And that's really difficult for folks like us who come from non-traditional backgrounds, just tweaking your resume in such a way that it's like, here's my relevant experience from roles that literally have nothing to do with engineering, right? [laughs]

Lauren: Yeah. That's really, really hard. It's like, how do you flip that narrative so that it feels like, no, there are skills there that will apply for the team, and I really want to highlight that. But yeah, they are not technical, or they're not anything connected at first glance, maybe.

Chloe: And you really just want to have...if you're like me, you know, you've been working in the industry for five years, unless it's super relevant. Like, let's say I apply for Disney and that I just want to put my Disney Store...[laughs]I don't know what scenario it would be in which I put an old thing on there.

But the best advice that I got...when I started my bootcamp, I took this wonderful person out whose name is Nemo. I used to be an office manager at PAX Labs. And they had just hired this new engineer, and he was a bootcamp grad. And I was so excited to talk to him because I was about to start at my bootcamp, and I took him out to coffee after I graduated.

And I was like, "What's the best advice you can give me to get a job?" And he was like, "Just have a resume; that's your standard resume. Have a cover letter where you're just like, it's the same template for each one, except for maybe very special circumstances, and just send them out. Send them out to as many places. It's a numbers game for your first job. Get it out to as many places as you can." I hate to compare it to online dating, but it's literally like, you're not going to meet the love of your life on the first date. If you do, that's great. But most people – [laughter]

Lauren: Yeah, happy for you. [laughs]

Chloe: It doesn't happen. And also, you want to have, especially as a new person, several interviews because as an engineer, you have to learn how to interview. [laughs]

Lauren: Exactly.

Chloe: It's so weird. Like, we don't talk about it enough that it's like senior, senior engineers have to take a month off to study to even think about interviewing again. So I always tell people your first job is the hardest, hustle, hustle, hustle, just get it out there. You want to get practice. And I think it took me my second or third whiteboarding interview to even know how to whiteboard because it's a skill that you have to learn.

Lauren: Yeah, a muscle. Yeah, for sure.

Chloe: As many interviews as you can get to get that practice for that first job, go for it. As you get more senior like myself, you have more of a choice of where you want to go. And you can get referred, and you're not applying through a recruiter. You have friends and contacts there. And you should always go through a friend or a contact because they get a referral bonus typically. [laughter] It's great. I think my boyfriend made $40,000 when he was referring people at Evernote back in the day.

Danny: Hell yeah.

Chloe: There are ways to...there are big incentives to have good quality engineering talent.

Lauren: True.

Chloe: So just know the first job is the hardest. Oh my God, the first job is the hardest. [chuckles]

Lauren: Well, I think next week, Danny, we're going to be talking about building referrals and that network kind of concept of how to get into that. So I suppose stay tuned, folks. [laughs]

Danny: I told you this is the first episode. We're really setting the bar high with having Chloe here. But stay tuned, really, stay tuned. [laughter] I think when you are looking for that first job, or you're trying to look at your resume and really fill it out with your best of your best, you want to have your projects on there. You want to have your experience. And like we had mentioned earlier, it's hard to put some things that are not technical. I know for me, it was kind of hard to just throw projects on my resume. And then, all of a sudden, I'm like, I worked at Costco.

Chloe: Right. [laughs]

Danny: But then I tried to really look at the position that I was applying for and see how I can correlate my previous job experience with what they were asking for. So I did something like, oh, I was an e-commerce manager, and I was responsible for very tight deadlines that meant managing people and data analysis. And so that can correlate to the position that you're applying to rather than just being like, oh, I just worked at Costco, and that's that. Like, really dive in a little bit deeper and show that you have work experience that relates to the position that you're applying for.

Lauren: That's great advice.

Chloe: Truly be the resume you wish to see in the world [laughter]; just make the resume that you think the candidate who's going to get this job...because you're qualified for it. You're applying for it. So I would say you can tweak it with each...for myself, I'm a developer relations person. So I'm applying to developer advocate roles. And pretty much the job description for most developer advocate roles, it's slightly tweaked at different ones.

But if there's something you really want to be doing, if you're like, ooh, I did a lot of, I don't know, event work at my last company, and I want to do more events. Emphasize that. Be like, yo, I'm great at this, and I want to do this, and here it is written very clearly on my resume.

Let's say you started to do video work at your previous company. You want to do more video work, highlighting that and applying. I always say to people like, the worst thing that can happen is you don't hear back. [laughs] And I think there's a preciousness that people are like, Oh my God, I'm going to apply to Facebook, it's my dream or Google, it's my dream, or Airbnb, whatever it may be.

Lauren: Oh gosh, yeah.

Chloe: And that's great. But also know that you need to practice before you go all out. [laughs] And the best advice I've ever gotten with interviewing is from my mentor at Hackbright who said there's this...you know when you start dating someone new or something, and you're like, oh my God, we're planning the wedding, like, in your head? [laughs] Don't do that with a company. It used to be when there were on sites. But the best advice she gave was; basically, you're going to go to the on-site. You're going to be like, oh my God, I can ride my bike here. They have my snacks that I like. Oh, and they have this benefit or perk.

And she's like, just don't go there in your head at that point. Be present in the interview and be like, do I like it here? Is this fun? Am I getting a good vibe? And then, if you get an offer, you can think about all those great things. But it reminded me a lot of auditioning and being like, oh my God, if I audition, I'm going to get this part, and my life is going to be like this, and I'll get this role. And you can't plan the show in your head ahead of time, if that makes sense.

Lauren: That's great advice.

Chloe: Just be present. And I'm like, oh my God.

Lauren: Don't plan the wedding.

Chloe: Yes.

Danny: For real, you get really excited. And I know for people who are just postgrads from university or just finished a bootcamp, this idea of being able to pick and choose a company is so foreign to them.

Lauren: Good point.

Danny: Because they're just like, hey, I just want a job. Anything that I'm offered, I'm going to take it. And there's kind of this emotional attachment with every application that you submit for. I know that's how I felt like. I was like, if they offer me anything, I will accept it.

Lauren: Yeah, everything was going to be so much more money than my teaching salary. So it was like, I'm not going to play that game of negotiation, or I'm going to say yes to anything that they throw at me. So that's tough in itself.

Danny: Yeah, I think it's good to just have a team on your side that will empower you.

Lauren: True.

Danny: I know for me I was talking to my cohort all the time just being like, "Hey, y'all, I just got this offer. But I'm waiting to hear back from these people." And I'd reach out to my mentor and just like, "What should I do?" And luckily, I was going to take an internship that was going to pay me like $15 an hour, and Lovisa was like, "Just email New Relic one more time, just see where they're at." And I was like, okay, and I thought I was being annoying.

But I realized that with every resume that you're submitting to, like Chloe you had said, it's just a numbers game. There were thousands and thousands of other people doing the same thing. So sometimes you get lost in it. So if you feel like you're being annoying, you're not being annoying until someone tells you you're being annoying. [laughter] So that's what I've learned. And luckily, they were like, oh yeah, actually, we were going to email you. Can we talk to you right now? And I was like, oh my God, I was just about to accept $17 an hour. [laughs]

Chloe: Truly, here's the thing. I love recruiters. I've been a recruiter. And my boyfriend told me when I got into engineering, he's like, "You're going to hate recruiters." And I was like, what? I am a former recruiter; how dare you? I love recruiters. But let me tell you something. There are really, really great recruiters in the world, there are. And there will be recruiters in your life who give you really great signing bonuses and advocate for you, and are really on the team to make a decision.

And you're going to interview places where the recruiting experience is a nightmare. And especially at larger companies, it's totally luck of the draw, right? At startups, there are just such an excitement or even just smaller companies. Not to say anything is wrong with corporate recruiters. It's just like, your mileage will vary with any person. That's why I really say, folks, always go through a referral if you can, someone who can internally advocate for you, especially if they're close or know someone on the team. Because sometimes, especially at larger companies, it's a numbers game, you get lost in the shuffle.

Danny: We talked about some things to highlight your resume, like changing the font or going to...[laughs] That to me makes so much sense because if I'm looking at the same type of like looking resume all day, I'll be like, boring, boring, boring.

Lauren: Yeah, one pops.

Danny: And then I see Comic Sans or something. Ooh, wow. [laughs] I'm like, cool.

Chloe: Papyrus.

Lauren: Are you using this ironically? [laughter]

Danny: Yeah. What were some big no-nos for resumes to you?

Chloe: Oh man. You know what I hate, hate, hate, and I wish that people would stop doing this?

Danny: Lying? [laughs]

Chloe: To give it some context, I used to work with university students. Like, people who put a statement of intent on their resume like, "My purpose with this resume is to get a job."

Danny: Oh my God.

Chloe: And I'm like, yeah, of course. No duh.

Danny: I had one. I had one. [laughter]

Lauren: I still have one, y'all. [laughs]

Chloe: More in the sense that it's like, I would see these ones where it would take up the whole top half of the resume. And I was like, no, no, no, I want to learn more about you, sweety. Who are you? What is your life? And then I would also say this isn't a pet peeve but something...so a lot of times you just want a lot of space. You're a little pressed for what you want to fit in there.

Lauren: Sure.

Chloe: And I see people put their age and their address. And especially in today's age, I'm like, I don't need to know where you live.

Lauren: No.

Chloe: I think that's even illegal for me to know.

Danny: [laughs]

Chloe: I think a phone number and an email is good contact-wise. If you work in a social-related role, social media can...like, I have social media on my stuff. But I would say when I look at a resume, all I want to do is be like, I want my eye in the first five seconds I know what's going on where I'm like, name, cool. Oh, here's the last two or three jobs that they had. Maybe there's some education stuff on there or relevant experience or training. I should be able to do that in five seconds.

So if you don't have any bolded stuff or if it's really confusing, and I can't see...the amount of years you were there is more prominent than what company it is. Just basic formatting, which I think as engineers, a lot of engineers think they're designers, but they're not, which is why I just encourage Canva templates, [laughs] sponsored by Canva, just kidding, not an ad.

Lauren: But Canva, come talk to us.

Danny: [laughs]

Chloe: But truly, a good formatted resume is just like, great, 1-2-3. Here are the recent jobs, here's how long you were there. And if I want to dive deeper, I can look at the bullet points and be like, oh wow, Danny worked at Costco, and he managed people there. If I want to learn more, I'll look at the dot-dot-dot. But I can tell in five to six seconds; this is a candidate that I'm moving forward or not.

Danny: Someone was like, "I don't need to see a summary," exactly what you just said, Chloe. "I don't need to see a summary. I'd rather see just another project that you worked on, and they could be the same size." To me, I was like, oh, duh. Why would I write exactly what the resume is portraying? Of course, I want a job.

Lauren: Redundancies, yeah.

Chloe: They know when you're bullshitting.

Lauren: 100%

Chloe: You can tell on a resume when someone is lying or making something bigger than it is. People who have confidently done things and then put them on the resume, you can tell. And if you have trouble figuring out...for me, I'm always like, what did I do in this job? I always try to save the job description of the role that I applied for. I've forgotten to do it at the last couple of jobs that I've had.

Lauren: That's great advice.

Chloe: Because afterwards, you're like, oh, what did I do? What were my OKRs?

Lauren: The action verbs of it.

Chloe: You know how I said my LinkedIn is my single source of truth? I also use that as a media version of my resume, if that makes sense, so any video podcast, things that I think are relevant projects. If you go on to LinkedIn and you go to add links to a job specifically, each job has a little media section. Use those as you see fit. If you're a designer, put designer portfolio stuff in there. I don't know if people are looking at resumes. I'm sure they are. I look at resumes when I interview candidates. But people go on LinkedIn often, so it's worth keeping that in a good updated place.

Lauren: I think both should stay updated. You just don't know. And I think as a manager, I have quickly looked someone up on LinkedIn right before the call starts just to refresh my memory of it. So you might be catching them at a very particular important moment too. So yeah, I think that's great.

Danny: That is so nerve-wracking, Lauren, just to be on the other side of the call and being like, ooh, I am so excited. Okay, everything's fine. And then you just look on LinkedIn, and it's like, this person looked at your profile. [laughter] I'm like, what? What? What?

Lauren: For sure. I really should be in incognito when I do that. [laughs] Because my day is busy, I have 10 minutes before the call is my time to do the research. So I'm trying to catch up really quick. And so you never know the state of mind of the interviewer, I suppose. And so that's the behind-the-scenes piece of what's happening there. [laughs]

Chloe: Oh my God. I just had a very existential thought. [laughs] So I've been seeing more stuff about the metaverse.

Lauren: Sure, timely.

Chloe: Just like the funniest TikToks out there of just kids being so rambunctious in the metaverse like throwing a boomerang, one of my favorite TikToks I've seen. But I just thought about how currently the way that LinkedIn works, you know, if someone visits your profile. In the future, in the metaverse, is LinkedIn going to be a place and people physically metaversely will go into your LinkedIn? Because I hate that for me. [laughs]

Lauren: It's like your apartment almost and then looking in. [laughs]

Chloe: Oh no.

Lauren: There it is.

Danny: You just walk in, and you're like, oh, never mind.

Chloe: The future is terrible. [laughs]

Lauren: Enjoy, folks, that's all we have for you. [laughter] Oh my gosh.

Danny: You said that you weren't really even sure people are looking at resumes, almost seems like this old-fashioned way of doing things. That kind of brings up our next topic about cover letters because I've always thought cover letters no one was reading them.

Chloe: [laughs]

Danny: To me, I was like, no one is reading this. But would you actually take the time to read a cover letter, and if someone actually wrote a good one where you're like, oh yeah, I'm moving this person forward?

Chloe: I think it makes a difference for sure. Have a good one that you like, especially if you're like bing, bang, boom. You're sending out hundreds of resumes a week because you're new or a new grad or a new student, whatever that may be. Just have a template like a Mad Lib that's like, I'm excited to work at this company because blank, and I think blank and blank. I would love to work for insert company here, you know, Danny.

I will say I have not had to write a cover letter since I was applying for my first role to get a job. Anytime you're referred, a cover letter is not necessary. So I think it's something with seniority that just is...and also, I think it's getting a little phased out. I would say have a good cover letter. Have a good go-to.

I always tell the story of like [laughs] in my bootcamp, we had this thing called demo night where different companies came. And I was so excited that DroneDeploy was going to be there because I was like, I've flown a drone once. [laughter] I was like, this is my in, right? And so, in my cover letter, I had this standard cover letter I was sending out to everyone. But I was like, oh, I met these people at this event. I'll write a personalized cover letter for this one company because I have a video that I wanted to attach that's like, and here's me flying a drone. [laughs]

Lauren: Oh my gosh.

Chloe: I did not get an interview there.

Lauren: Oh no.

Chloe: But that's why I tell people, like, don't treat these opportunities so preciously the way that my mentor was like, don't plan the wedding. It's literally like, don't plan it in your head ahead of time because it hurts so much more. I remember I wanted to play Éponine so bad in Les Mis, you guys. [laughter]

Lauren: Oh my God.

Chloe: And I never got to audition for it to be fair, to be fair. But there are roles that you miss out on that you're like; I wanted that role. And like, don't let that happen to you with engineering roles because there are so many great roles. It's not like we're all trying to play Elle Woods. There's literally so...it's a great market.

Lauren: Yeah, that's so true. Oh gosh, I remember I walked into a Blue Origin interview, and I wanted this job so bad, Jeff Bezos' space company. And I casually dropped my library book about space on the floor as I walked in and was like, oops. [laughter]

Chloe: Oh my God.

Danny: Why did you do that?

Lauren: In case I get asked about space. [laughter]

Chloe: We love a performer. We love a performer.

Danny: Silly me. [laughter]

Lauren: Apologies. I didn't get a second interview just to update on that one.

Danny: I don't know if you saw, but I just love space so much. [laughter]

Chloe: It's like the girls who dress up as Annie at the Annie audition. It's very the same.

Lauren: Exactly. That's me. [laughs]

Chloe: But that's also a great point, too, is you build these companies up in your head. And I've worked at Microsoft, and it was a lovely experience. But it's like, I think the biggest eye-opening thing for me was I was working at Microsoft, and I went for this event at NASA. And I was like, oh my God, this is going to be so futuristic and cool.

And you forget that NASA is a corporate government organization. It's like the DMV for space. [laughter] And you think oh, you're going to meet all these...and it's literally like, oh, this is an office. There's all this technology, but it's an office. But it's so important to go to these places. I wasn't interviewing but be in these places.

There's a quote from Cinderella in Into the Woods that's like, how do you know what you want till you get what you want and you see if you like it? And that is literally the story of my career where I was like, I'm going to be an actress. Okay, that was cool. I'm going to go do this thing. And so much of even...you're like, oh, do I want to work at Facebook? Do I want to work at Google?

Interviewing these places or meeting people at these places and your experience really defines what these FAANG companies are to you or what a startup is to you. And I think just have so much fun with your career. Don't feel like you have to work at Google or at LinkedIn or whatever your dream company is. You can contribute to this space in such meaningful ways and for competitive pay at other companies.

Danny: Absolutely. I do want to note that you said the best quote of the day so far, "NASA is the DMV in space." [laughter] I just want to note that.

Chloe: It is.

Lauren: I thought it was the Cinderella one. I was like; I did love that. [laughter]

Chloe: I love NASA. NASA is incredible. NASA is literally open-source space. But for anybody who works in open source or works in a government agency, we know what that life...it's so interesting. You grow up, and you're like, I want to work at a game company. And you're like, oh, gaming companies, the culture can be depending on where you work --

Lauren: Dicey. [laughs]

Chloe: Like, it's very in demand. Or I want to work at Pixar. And it's like, no, I don't want to work at Pixar. There are so many different considerations to factor in. It's just like Ivy League schools, right? I went to San Francisco State University. I went to a state school, and I'm doing fine. You don't need to have...it's great to get that experience. If you get the opportunity to work at a big company, go for it, but it's not going to solve all your problems.

Lauren: That actually makes me think that Danny, for a future episode, it would be a really fun thing to workshop in the there are so many things to look for in a job that you maybe want to hierarchically rank while doing the search, whether it's the opportunity to work remotely, or you really want a great work-life balance, or you want good mentorship, or the opportunity to do pair coding, whatever that list is.

But maybe we could spend some time really massaging that particular topic because I think some people do do a little bit of company hero-worshipping thing. And that is great advice that it doesn't really get you very far always. Cool, you can brag about it at the Thanksgiving table with your non-tech family members but like day-to-day --

Chloe: You guys should do truly like a job mood board just like manifest or like, what is it called? A goal board thing where people set their intentions, or they put their goals on a board.

Danny: Ooh, and you cut pieces of paper from a magazine, and you put them on the board.

Chloe: Yeah, very that.

Lauren: Oh yeah, yeah, so like you're manifesting.

Chloe: But do that for a job where you're like, I want to do more video content or whatever that is for you.

Lauren: I love that.

Chloe: I want to make TikTok for a living, I don't know. [laughs]

Lauren: Sure.

Chloe: Just putting all the things that you want to do. There's a really great book. I'll send you all a link. It's a really wonderful book that my friend wrote about...it's literally like a workbook for what do you want in your new job? And what are you looking for? And being able to just...like, that job probably exists. [laughs] I want to eat candy all day. That's not going to be my job. [laughs] But for something where you're like, you know what? I really love this part of my job. And that's how a lot of people end up in developer relations like us.

Lauren: True.

Chloe: They're like, I really enjoy teaching people these things and making content around this. And you kind of wake up one day, and you're in developer relations. And you're like, oh, that's a job. And so many people come to this field being like, yeah, I was an engineer for six years. And then I was like, oh, I like doing content, teaching engineers how to use developer tools. And it's like, oh, that's a job. [laughs] And something that someone said to me recently is that with the rapid rate at which technology changes, the job that you will have in five years may not even exist yet.

Danny: Yes, someone told me that recently.

Chloe: So a great example is April @vogueandcode on Twitter, one of my best friends, a lovely human being. We met five years ago at a conference. She's like, "What do you do?" And I'm like, "I'm a developer relations person." She's like, "I want to do that." And then she did it. But she didn't know anything about VR then, and now she works in a very senior principal VR role at Microsoft.

Lauren: That's awesome.

Chloe: Because you have to be a beginner at some point in these technologies, whatever that is, like blockchain, VR. You don't even know what your job is going to be in five years, truly. Like, technology is changing so much.

Danny: It's all going to be automated. We won't have jobs, hopefully.

Chloe: Exactly. [laughs]

Lauren: Quit it. Would you stop it? [laughter]

Danny: Okay, I have to ask this, Chloe, because Lauren and I were dying because we read my old cover letter.

Lauren: Oh my God.

Danny: And because you are a performer as well, I think you will like it. [laughs] And I want you to get in the recruiter mindset. You've been doing this for –-

Lauren: Oh my gosh. You're not going to do this right now.

Danny: Yes, yes, I am. [laughs]

Lauren: I can feel secondhand embarrassment for you. I'm starting to sweat. [laughter]

Chloe: I'm so excited.

Danny: So you've been doing this for hours. You've been reading the same cover letter over and over and over. Hey, my name is blah, blah, blah. I'm excited for this position, blah, blah, blah, blah. I've always been told you had to come in with a hook. You got to come in with a bang. And so what I'm going to do for you is I'm going to read you my first sentence, my hook sentence.

Lauren: I think I'm going to mute myself. [laughs]

Chloe: No, you're not.

Danny: No, no, no. We want authentic support laughter, not laughing at laughter. [laughs]

Lauren: Laughing with, not at.

Danny: Yeah, so this was my cover letter sentence. I want you to [laughter] just imagine me writing this: Broke, alone, sad probably, hungry, probably a little sweaty. Two years ago, after finishing an eight-hour shift in a large warehouse, I walked into an old, dingy dive bar to try stand-up comedy for the first time. I repeatedly failed standing alone on stage in front of an 11:00 p.m. weeknight bar crowd. I wouldn't say it was the most fun I had, but I knew the only way to get better was to continue working on it. And then I go on and on about how I did that with code. I mean, are you not --

Chloe: That's beautiful.

Danny: [laughs]

Chloe: That is the opening to your book. That is your book pitch.

Lauren: [inaudible 42:12] [laughter]

Chloe: Oh my God. I'm so here for it. I'm hooked. I'm like, tell me more. Tell me more.

Danny: And then I go on to say I put in the same determination and grit to use when learning how to code. I had a great conversation with one of your software engineers blah, blah, blah and blah, blah, blah spoke very highly of the team at blah, blah, blah. And then that became my little template, and I just put the name in there and the company in there. And I said I'd be delighted to be considered for the blah, blah, blah role, blah, blah, blah.

Chloe: Danny, here is the real tea.

Danny: See, Lauren, I need you -- [laughs]

Chloe: If I read this, I would be like, stop the presses. We need to hire this man. [laughter]

Lauren: That's exactly...No, stop, Chloe. That was the phrase that he was like, I want them to say. [laughter]

Danny: I told you. I told you this shit was fire. It was so good.

Chloe: Because here's the thing I can tell you, Danny, this was me. This was legitimately like before I was in engineering. I remember I applied for Yelp for a sales role. I worked in sales at Yelp for a very brief period of my life. And I was like, I love Yelp. I would just truly have a cinematic what you wrote. I was there. [laughter] You brought me to a place.

But if I had just been sitting in my little recruiter chair going through being a sourcer and I came across...if I even looked at the cover letter and I came across this beauty, I'd be like, excuse me; I would be like, I just woke up. Who is this?

Danny: See? And I would do that for other roles that I knew I couldn't even get hired for. There was one that I loved. It was like this creative coding. They were asking for someone with huge experience. And I literally started my hook with, "I am nowhere near experienced enough to even have this role, nor do I even think I could even get this role. But I want to be hired there."

Chloe: Honesty.

Danny: And they responded to me. They were like, "Hey, we love the honesty."

Lauren: I've heard of that working.

Danny: And they were like, "We love the honesty. We're not looking for any juniors right now but hit us up again in a year or so." And I was like --

Chloe: We love a hook.

Danny: They love a hook.

Chloe: And you know what? That's the performer in us. [laughter]

Lauren: And you're being your full self. And that is an important piece to the equation of showing who you are. So I totally understand it. I want to have our call to action for this episode for listeners be what is something that you've included in your past resume that you wish you could go back in time and perhaps take off or keep? [laughter]

Chloe: Yeah, some spring cleaning.

Lauren: Yeah, what is something that could give us some second-hand mortification or share with us something from that early resume. I would love to see.

Danny: Or let's say you wrote the best resume you've ever written. Just read the first sentence, like, the first hook of your cover letter.

Lauren: Oh, you want to hear the hook. Okay. [laughs]

Danny: We can have two calls to action.

Lauren: Sure. Tag us at @newrelic. [laughs]

Chloe: Did you guys see the girl, lovely woman, Karla Stickler, who was a software engineer who stepped in for Elphaba on Broadway a couple of weeks ago. Did you see this?

Lauren: Yes.

Chloe: Okay, so I'm obsessed with her. I love her. And I'm trying to imagine if Karla were to write a cover letter like Danny, it'd be like I step on the stage. I truly defied gravity just like the Hulk. [laughter] I love this idea of the hook challenge, the Launchies hook challenge. Write your hook. [laughs]

Danny: I'm promising someone...I was going to promise money, but I don't have. I'll just give you attention. [laughter] If you write the best hook, I'll just give you a bunch of attention, say what's up.

Lauren: Oh, Danny. [laughs]

Danny: I don't know if anyone wants that, but I don't have any money to give.

Lauren: Oh my goodness.

Danny: But we'll give you maybe...we have some New Relic swag, I don't know.

Lauren: Yeah, we have some very cute LEGOs of our data nerds. That's what we can send your way.

Danny: And I have a ton of stickers that I was left with at a tech conference.

Lauren: Heck yeah. Well, Chloe, thank you so, so much for joining us today to share your wisdom and all things resumes and cover letters and your past in theater, and all of your work experience. It just makes for a great conversation, and yeah, we just so appreciate you.

Chloe: Absolutely, anytime. Anytime you guys need me to do a resume makeover, I love doing makeovers on resumes. I used to host an Extreme Home Makeover: Resume Edition at the Microsoft Reactor.

Danny: Woow.

Chloe: Back in the before times, people would come in, and I'd grab their resumes to redo it for them. So truly, I love doing content like this. So I'm happy to help anytime you guys need advice.

Danny: You rule, Chloe. You rule.

Chloe: You rule. [laughter]

Danny: What is one piece of advice, Chloe, that you could give to someone who is writing their cover letter, resume, or anything right now just your...not your hook, not your one-sentence hook, just your one-sentence advice.

Chloe: Ooh. So I just watched Goofy Movie. And I feel like Stand Out, the song Stand Out, [singing] stand out above the crowd. You literally need your resume to stand out.

Lauren: Yeah, absolutely. I love it. Thanks, Goofy. Thanks, Chloe. [laughter] Thank you so much, everyone, for listening to the first episode of Season Two of Launchies. We want to hear the call to action. We want to see those hooks. Please tag @newrelic in your tweet. We are so stoked to continue this conversation online with y'all.

And then also we have a New Relic community Slack and an easy link...I can put the link in the show notes, but it's bit.ly/nrslack. And come join and hang out with all of the other users and customers of New Relic. And we can chat to you there during the day-to-day workday, and that'd be kind of fun.

Danny: And don't forget to follow our personal handles. I'm @muydanny on Twitter. Lauren is @lolocoding. And don't forget to follow our wonderful guest, @chloecondon, even though you're probably already following her because she rules. But yes, thank you so much, everyone, and be sure to do those calls to action. I will figure something out, a prize or something. We got to give out some stickers or, I don't know, maybe I'll just send you a cool selfie or a picture of my tortoise for everyone who does a call to action.

Lauren: Sometimes I think I'm just going to be quiet here and let him finish his thought and see where he goes. [laughter] I'm like, don't open your mouth right now, just see what happens. See where he takes this. [laughter] Send them a picture of your turtle?

Danny: Tortoise. It's a tortoise.

Lauren: Torty is coming to you, folks.

Danny: Oh my God.

Lauren: All right. Well, there's your prize. We've landed on it. Be sure to tweet at us and let us know what you really would love or if you're happy to see Torty. That's good data for us as we're growing this program. But of course, stay tuned for next week. As we mentioned in the episode, we'll be diving into how to build your network and get those referrals so that you can get an in at a company as you are interviewing and navigating the job hunt.

Danny: Take it easy, everybody.

Lauren: Bye.

Giving 100% – Working Towards Shared Goals with Ryan Bahan

Mandy Moore — Wed, 16 Feb 2022 15:30:48 +0000

Relicans host, Aaron Bassett, talks to Software Dev at Shopify and Turing School alum, Ryan Bahan about being comfortable being uncomfortable while figuring out what error messages mean, the application process when applying to a bootcamp and belonging to a post-pandemic remote cohort, and making important (& fun!) design decisions.

Give us a follow: @PolyglotShow

Giving 100% – Working Towards Shared Goals with Ryan Bahan

Polyglot

Your browser does not support the audio element.

1x initializing... ×

Aaron Bassett: Hello, everyone, and welcome to another episode of the Polyglot Podcast. I am your host, Aaron Bassett. I am a Principal Developer Relations Engineer here at New Relic. And I am joined on the show today by Ryan. Ryan is a Front-End Dev at Shopify. He is also a graduate of the Turing School of Software and Design. As we've covered a few times, I think on the show before; we're all big fans of bootcamps here. So I'm sure we will have a lot to talk about there. Welcome to the show, Ryan. Good to meet you.

Ryan Bahan: Yeah, thanks so much for having me. It's great to be here.

Aaron: No, no, thank you for coming on the show. It's always fun to meet a graduate from Turing School. I know I mentioned in our lead-up conversations that we have two of them currently on my team here at New Relic. Our Director of Developer Relations, Jonan, is a graduate as is one of our associates, Danny. Do you happen to know Danny? I don't when it was you graduated. [laughs]

Ryan: Yeah, we've chatted a couple of times. I don't think we've ever met in person because my cohort was post-pandemic, so more so just acquaintances, but he's a great dude.

Aaron: So you're saying your cohort was post-pandemic. So it was all virtual then, or?

Ryan: So we were square in the middle. So Turing has four modules for people who don't know. I did my first two in person, moved to Denver from Burlington, Vermont. And then yeah, the world got a little bit crazy. And we heard Mod 3 is going to be remote. And we're like, okay. This is when there were still thoughts of like, this will maybe be over soon and then not remote, and now it's permanently remote. But I think it's awesome to see that so many more people can be positively impacted by Turing now, and that opportunity is not relegated to Denver.

Aaron: Yeah, it was one of those things. When the whole pandemic was starting, I remember my partner and I were both booked to talk at a conference in Italy in May. And we were like; it will be fine. It will all blow over by May, not a problem. Little did we know.

So yeah, I'm sorry I jumped straight into the whole Turing stuff there. People on the podcast may not know what Turing is. Do you want to give them just a quick outline of what the bootcamp is all about?

Ryan: Yeah, for sure. Turing is a seven-month program to transition into software development. There are two sections, the frontend and the backend section, independent of one another. So you do seven months in either or. Backend is focused primarily on Ruby on Rails development. Frontend is focused on HTML, CSS, and JavaScript and then moves into React in the later modules. And then, by the end, there's quite a bit more collaboration between the cohorts. And yeah, it was a wonderful, wonderful program to learn the foundations of software development.

Aaron: You already were kind of in programming a little bit before you started at Turing.

Ryan: Yeah, I was a little bit tech adjacent for a lot of my life, I guess. I came from a very DIY background. I grew up skateboarding and got really into filming when that was still on MiniDV, and I had to save up money for tapes.

Aaron: [laughs]

Ryan: And then got into editing and music production that way. And by the time I graduated college, I was thinking I was going to be a college professor but then got offered my first adjunct role, and I couldn't afford to pay back my student loans. So I was like, okay, something else needs to be done here and got into building CMS-based websites. So I was always touching the outskirts of development.

After a couple of years of working in an agency and doing PHP-related stuff a little bit but never really knowing what the heck I was doing, I finally took the dive and decided it was time to actually learn what some of those words meant.

Aaron: [laughs] Was it beneficial to have that background before you started Turing, or did you have bad habits you had to unlearn?

Ryan: Probably a little bit of both. I think it was definitely beneficial in the sense that once I started doing front-end development, quote, unquote, "for real," I had already experienced a lot of failure points. I think that was maybe the most important one is just being comfortable when everything breaks and falls apart and you have no idea what's going on. [laughs] So having that background and like, what does this error message even mean at all? And being comfortable being uncomfortable, I think, was probably the main benefit.

Aaron: Yeah, it's one of the things that does come with experience as well in programming, especially around debugging and when things are going wrong. My partner is also a bootcamp graduate. She went to Ada in Seattle, so second career dev, was a teacher for a very long time before getting into tech. And whenever she has a bug or is trying to debug something or trying to figure out what's going wrong, she was like, "How do you know where to look, or how do you know that it was going to be this?"

And it's like, "Because I have broken my code in this way many, many times before." [laughs] It is the experience of going through that, as you said, that kind of turmoil and problem solving a lot that it's like, okay, no panic, we can solve this. We can figure out what's going on. And you were working in agencies before, did you say?

Ryan: Yeah, so I was freelancing for quite a bit after I graduated college. I had a consistent gig producing a podcast for a startup space. And then I was doing the website thing and turned 26, and no longer had the option to be on my parent's insurance. So I was like, I need a real job now and was lucky enough to get hired by an agency doing mostly non-profit fundraising.

So it was like Drupal sites and lots and lots of email marketing, and I did that for about three years. And that's where I got hired as a content strategist but ended up wearing many hats and doing a lot of templated emails and, yeah, CMS stuff. So that was my more formal intro to the world of tech.

And yeah, I got unfortunately laid off when we lost a big client and was looking for marketing-related jobs and had a couple of friends suggest just doing development full time. And I brushed it off for quite a bit, actually, because I was like, I'm not, I don't know, I just never saw myself as a developer, which is kind of so silly in hindsight.

Aaron: [laughs]

Ryan: But yeah, it just didn't seem like it was something I'd be good at at the time, or I don't know what it was. I had that I'm not good at math type of outlook because I thought that's what development was. And I got the push to apply to Turing, and I was like, all right, I'll take the qualification test and see what happens, and it went super well. And yeah, I decided to make the move out, and it was awesome. It really changed my life and changed the way that I looked at what I could be capable of doing.

Aaron: That's wonderful. So for people who are thinking about going to a bootcamp or a code school, what was the actual application process like?

Ryan: I'm trying to recall this. I think it was a lot of logic questions so similar to when you take the bar from what I've heard of just logic-based problem-solving. And then there's like a culture interview type thing. I guess it does match the tech interview, and there's a tactical challenge and a culture challenge. Who would have thought? Almost unintentional, one might say. And then there's a culture fit. And that was pretty much the process when I had applied. This was a couple of years ago, so it might have changed now.

But yeah, you talk with a couple of different people. They ask you why you want to get into it and do some problem-solving. And then you go into they call it Mod 0 or they did at the time. I think they still call it that, though, which is like a pre-course where after you've been accepted, before you really get into the meat of things, you make a GitHub account, learn a little bit about Git and some command line basics and then dive right in for seven months.

Aaron: [laughs] You're saying it's Ruby. So how was that transition for you from doing Drupal, WordPress, and PHP work to making the switch to Ruby?

Ryan: So I did the front-end program. So I was out doing JavaScript most of the time. But I didn't know enough about PHP, or we were using a lot of Twig at the time for templating stuff. We literally, like me and another content strategist, had a text file full of snippets. And we would just paste stuff together and then move it around until it looked right in the browser.

Aaron: [laughs]

Ryan: And then every now and then, someone would be like, "Actually, I'm on Outlook," and we'd hit up the tech lead, and he'd give us like the Outlook code snippet to fix things in that client. So it was pretty hacky. I guess I had one overall big bad habit rather than a lot of them. So it was lucky that I felt like I got to learn things from scratch with a little bit of CSS understanding.

Aaron: So it was mostly just like front-end scripting then.

Ryan: Mm-hmm.

Aaron: So you have to make the choice between whether you want to focus on backend or frontend whenever you join Turing.

Ryan: Mm-hmm. That was actually a pretty difficult choice for me. I was stressing a lot. And it's unfortunate that people think this way, but I was thinking this way as well, like, well, backend is probably like for real developers and frontend is less real for some reason.

Aaron: [laughs]

Ryan: I talked to a lot of alumni, and I talked with teachers. And they basically said, "You're going to be able to get a job no matter which one you do. You're going to eventually learn both if you're interested in it. And your skills in learning one language will transfer pretty well. So do what you enjoy more." And that's what I did.

Aaron: That's pretty good advice.

Ryan: I tried both out, and I did really come to like both. But I thought that my experience and what I'd done in the past and enjoyed doing lended itself more to frontend, so sort of hit the ground running with that.

Aaron: [laughs] I cut my teeth in agencies during the Netscape and Internet Explorer browser war days. So I'm terrified of the frontend now. And I much more like running my code on a server that I control rather than somebody else's browser. [laughs] Things are better these days.

I started off as a front-end developer and then made the switch to backend because I perceived it as being more straightforward. I think that's pretty common that people will look at the one that they don't do and say, "Oh, yeah, that one looks more straightforward. I should do that one." [laughs]

Ryan: Yeah, I remember. It was pretty funny. Once you get towards the latter end of the program and you're collaborating more with the other side of the stack, it was such an odd feeling looking at Rails and being like, "Wait, you run a command and get all of that for free?"

Aaron: [laughs]

Ryan: And then the Rails people being like, "What? It's just JavaScript in the wild. This is pure chaos," which actually having done a lot of TypeScript, now I do look back at Vanilla JavaScript like it is just the Wild West of code.

Aaron: [laughs] I'm still interested about that choice when people are coming in. You obviously had a little bit of experience previously. So you knew a little bit about programming. And it sounds like you had some great mentors who were able to help you make that decision. But it just seems like it is such a significant choice to put on people who are coming in who may not really know anything about programming at all. What's the level of knowledge of the average person joining somewhere like Turing?

Ryan: I would say probably pretty low. There's definitely diversity there. But I think most people have some technological literacy. But myself and a couple of others were definitely in the minority of people who had maybe written a couple of lines of code beforehand. So they do try coding sessions where you get to do a little bit of frontend and a little bit of backend and see which one you like more.

Most people seem pretty happy with their decision, in my experience. So there are a handful of people who have switched in the early stages or in the middle, but Mod 0 also gives you a chance to get your hands on a keyboard and see are you having more fun messing around with command line stuff, or is making something on a browser change really exciting you right now?

Aaron: [laughs] I know at least for some of the bootcamps or the code schools, they really insist that for certain programs that you can't have any background. Everybody's coming in at the same kind of level. So you don't have people who are racing ahead, or people feeling they're getting left behind. And I think that's a really interesting part of it as well.

My partner has talked about it often that you would get people in class who their husband or their wife or somebody at home would be a programmer. And they were always so...jealous is not the right term but envious of the fact they had somebody at home they could go home and talk programming to. Did you have somebody like that in your life outside of the Turing School that you could talk tech with?

Ryan: That's a good question. My partner is a product manager, so talking tech realm and culture. And she has helped me in a number of ways, and that support has been amazing. I had a couple of friends of friends who were developers, so a little bit. But it was mostly our cohort. Turing actually gets a lot of their incoming students from being partners of graduates because you go and you get a tech job, and you love it. And then you're like, "Hey, you should just do this now."

Aaron: [laughs]

Ryan: So there were a couple of developer partners in our cohort. But really, they told us at the very beginning your cohorts relationship with one another is really going to define how successful you all are and lifting the people up around you, providing support, listening, especially because there are so many peaks and troughs in the journey of learning software development that you might be crushing it on learning the basics of HTML and then learning array methods is just really messing you up.

And it can be really nice if you were helping other people previously to get some help back and pass the knowledge and support around. So I was very lucky to have an awesome cohort of people. And we did as much as we could to lift one another up from the learning journey to the job hunt journey as well.

Aaron: That's great. Was it impacted at all by the fact that you did have to go partially online? Does that have an impact on the cohesion as a cohort?

Ryan: I think it was tough for us because it was the beginning of the pandemic. It was the first shot at doing this stuff remotely. So there definitely was a bit of a morale hit, especially because the job market was not good for those couple of months. But yeah, I think that we all did the best we could with the cards we were dealt, as did Turing, and we got through it.

Aaron: Great. And indeed, you're now a front-end developer at Shopify.

Ryan: Yes. I managed to trick them into letting me in. [laughter]

Aaron: Did you come straight from Turing into Shopify? What was that journey like?

Ryan: So I graduated Turing in June 2020. It was not an easy market to be in. I basically did a couple of months of contracting for a small agency working in React. We were basically working on like a DoorDash clone for beaches because, again, in Florida, people were still going to beaches at this time.

Aaron: Oh, we never stopped in Florida. Like, it never stopped. It didn't even pause. As somebody from Europe, this being my first introduction to living in the U.S., being in Florida during this time has been interesting is the best way I can describe it. [laughter]

Ryan: Yeah, that is a hard entry point into the United States.

Aaron: [laughs]

Ryan: But yeah, I did that for a couple of months and then got hired at Shopify in September 2020, so about three months out of Turing.

Aaron: That's really good going, as you said, especially that time with everything that was going on. So you moved to go to Turing or at least for part of the time. I know some of the schools make the attendees write letters to their loved ones, basically going, "Hey, you're not going to see me much for the next 16 weeks." Did you have to do anything like that with it, or how did that impact your personal relationships?

Ryan: I've never heard of the letters thing. That seems intense. I didn't have to do anything like that. Me and my partner were both, I think, over living in Vermont at the time. She's from Vermont; I'm from Connecticut, so still New England. But the winters there were getting pretty exhausting to deal with. And so, I think we were excited about moving to Denver.

We had been prepared. We had a couple of friends who graduated Turing. So they were like, "It's going to be a lot." I think they were saying between 60 and 75 hours a week easily to do things for seven months. So we had prepared for that. It was tough being away from my partner. And I had already been away from most of my family when I moved to Vermont, so trying to keep in touch on the weekends. But it definitely is a commitment, certainly.

Aaron: The change of tide in your direction and in your career. And thanks to Shopify now, it seems like it's a commitment that was worth doing.

Ryan: Yeah. I think it's probably the best decision I've ever made in my entire life, which at some points was a lower bar than others to reach.

Aaron: [laughs]

Ryan: I don't know the best way to say this, but I guess I considered myself sort of like a B-plus person for a long time of like; I never gave 100% into things and always just finagled my way into doing decently. And I came to realize that it was completely out of just fear of failing. And Turing was the first time that I moved across the country. I had a fixed amount of money that was whittling away as time went on. I really didn't have any sort of backup plan. It was just like, this needs to work.

And it was the first time I really gave 100% into something. And it really taught me so much about myself and what I was capable of, and what other people were capable of. And it was just really inspiring to see so many people working towards a shared goal and being fully invested in something. And yeah, I love programming. It's so much fun being able to build things for people. And it's been an amazing journey certainly.

Aaron: Yeah, definitely something almost kind of magical about being able to conjure something out of essentially nothing and getting it in front of other people. So with your cohort then, I know you mentioned they were really supportive throughout the actual course itself but then also in the job hunt and things afterwards. Do you all still keep in touch, or have people grown apart as they've moved on to their development roles? What's the alumni network like?

Ryan: I think that when we were in person, that was sort of the closest we could be. One of my best friends I met in the program, and we talk all the time and hang out all the time. And there are a couple of people that I'm still very, very close with. I think as we've all moved states and jobs, we've all kept in touch. It's like graduating college or high school, where it splinters a bit. Like, you're not the one unit, but you get in touch and build the subgroups of people, and then those subgroups meet up every now and then.

Overall, the alumni network is super strong. People are chatting all the time. And the job network is really amazing to be a part of. So that was actually one of the reasons I chose Turing as well and chose to do that program because I had heard such great things about the alumni network and the people you get to meet and the opportunities present there.

Aaron: So we've talked a fair bit about Turing. So let's talk a little bit about what you've been doing at Shopify. You are a front-end developer there. I think you mentioned you do a lot of work in TypeScript. Is that right?

Ryan: Yeah. So I spent the last year and a half working on Shopify Balance pretty much from the ground up, which actually released last week to general audience, which is super, super exciting. And it's basically our response to traditional banks. So now, if you're in the United States and you sign up for Shopify, you can have a business account and physical and virtual cards and be able to manage all of your money inside of Shopify and get insights and rewards.

Aaron: Wow.

Ryan: And same-day payouts and a bunch of awesome stuff that we're able to provide because we have the ecosystem with us. So it was really amazing to work on. I think it's something like over 60% of merchants are using their personal bank accounts to manage their funds. So being able to provide simple ways for them to like, make your taxes easier, make their lives easier, and hopefully make some more money along the way was an amazing journey.

Funnily enough, we finished that up and moved into developer experience. It's been like two and a half weeks on a new team. And I'm super excited to be focusing on the developer experience for our Shopify partners and third-party app developers now.

Aaron: So with Balance...is that the right name of the product? Am I getting that right?

Ryan: Yep.

Aaron: So, what was your favorite part of that that you worked on then?

Ryan: Just, generally speaking, being able to basically work at a startup but inside of a well-funded company with a bunch of resources was pretty sweet because we got to move quickly, build things from scratch, and experiment with all this stuff. But we were still inside of a company that has a bunch of best-in-class tooling and support. To be more specific, I got to build the card designer. So when you get a physical card, you can put a name or a logo on it.

Aaron: Awesome.

Ryan: So I got to do an SVG project of building the actual card designer, which was my first deep dive into how images work on the web. And that was pretty interesting, and wild, and crazy to be a part of.

Aaron: I remember a few years, well, more than a few years ago now, and there was a Twitter account I think called @NeedADebitCard. When the banks first started launching the ability to customize your cards, you could get whatever you wanted printed on the cards. And people were then so proud of the card they had custom printed. They were taking photographs of them and posting them on their Twitter.

Ryan: Oh geez.

Aaron: And there was a Twitter account that would just retweet these photographs of people's debit cards [laughs] called; I think it was something like @NeedADebitCard or some like that. But yeah, hopefully, people are a little bit more sensible now.

Ryan: So funnily enough, we actually made a bunch of design decisions around that. And it's something that's much more popular now where all the card details are on the back of the card. So then people put their branding and custom stuff, whatever, on the front and can take pictures for the Gram or TikTok or wherever the youth are congregating these days.

Aaron: [laughs] See, I have a couple of cards that are that way where it's just all printed on the back on them, and it's nothing on the front or not like the embossed that you used to get. And I just thought it was because they were just going a little bit cheap and didn't want to pay for the different kind of printing. [laughs] But now I can see yeah, maybe it's a security feature if they want to show off their shiny front cards. So how is it then...you're essentially working in a fintech startup then inside of Spotify.

Ryan: It was really interesting coming from not knowing much about how finance works at all to dig into the different flows. I think from a product and experience perspective, one of the most interesting and challenging parts was the amount of branching flows that can happen, especially during like, take, for example, signing up for the product.

I don't know how familiar you are with KYC verification. It's Know Your Customer, and it's basically protocols in place to verify someone's identity if they are who they say they are. And there are a number of reasons it could fail. And depending on the way that it fails, you may need to provide identity documents or just a little bit more information about yourself.

So with our signups, trying to think about how can we make this secure, prevent people's fraud risk from going up but also get people to sign up? Because if something fails on step one, most people are probably just going to go away and be like, "Well, I have a bank account, so whatever."

Aaron: [laughs] Yeah.

Ryan: So it was really, really interesting trying to think through the number of branches that any typical flow could have, especially once we got into suggesting people set up multi-factor auth. A lot of our part of the product was completely barricaded behind multi-factor auth just because of the risk involved. So yeah, getting the average person to commit to MFA is not an easy task. It was a lot of fun. It was a very unique challenge to be a part of.

Aaron: I know my banking app on my phone has on a couple of occasions made me do selfie videos while reading out certain phrases and holding my ID to verify who I am. Is that the kind of thing we're talking about or not quite that extreme? [laughs]

Ryan: So I don't believe we ever had to do anything that extreme. We got to a point for our release where I think it was like above 75% of people were able to just do the regular form and signup flow and then go through, which I think it's just your SSN that you need. But I think we did have some people that needed to submit a photo ID but never anything like video recording and speaking.

Aaron: So what you're telling me is the customer service agents on the chat version of my app were just having a good giggle on my behalf, really. [laughs]

Ryan: You never know.

Aaron: This is not an actual protocol that's being used in fintech. [laughs]

Ryan: Well, depending on what sentences they made you say, you may or may not be able to deduce whether or not they're having fun.

Aaron: Yeah, I'm not going to go Google them on YouTube in case it's...[laughs]I don't want to know that. I don't want to know if I'm a TikTok sensation. [laughs] So how is the change then from doing...was it just straight JavaScript at Turing? You're now on TypeScript. How has that been for you? Are you enjoying it more? I know you said it made JavaScript feel a bit like the Wild Wild West. What are the benefits you're seeing with TypeScript?

Ryan: Yeah. So we did React at Turing for a couple of months. And I was lucky enough that a lot of the stuff taught at Turing translated. Shopify is a well-known Ruby on Rails shop. They use React in the frontend. I think the big differences for me were TypeScript and GraphQL, both of which I've come to really, really love.

I mean, I think static typing has become such a powerful tool. Apollo has done a really fantastic job of leveraging the fact that you can print the shape of an entire app to do some really, really cool things with IntelliSense and auto-generating code and stuff. So it's been wonderful. And yeah, it is hard to imagine.

I do a bit of mentoring at Turing, and outside of that and looking at JavaScript and React projects, which I do think you should learn those things without TypeScript for a number of reasons, if not just to reduce the complexity of learning another thing. But yeah, looking at a React component, and you're like, how do you know those props are going to come in?

Aaron: [laughs]

Ryan: You just put them there and roll the dice. But yeah, it's been wonderful, and our environments at Shopify are really amazing. That's what made me fall in love with DX was coming from in a very short time span, being at a bootcamp where I had not set up a linter, so I'm still manually formatting my code, to the amount of lookahead and IntelliSense and things that just make your life easy. It was like; this should be everywhere. [laughs]

Aaron: Yeah, I do a lot of work in Python and in JavaScript, and I don't know what I would do without auto-formatting now. And I have to admit; I'm kind of one of those certainly older school people who was a bit of a hold out for a while on the auto-formatting. I was like, no, I've been formatting my code myself for the last two decades. I know how I like my code formatted. And these formatters don't format the exact way that I want.

You know what? They get it like 90% of the way there, and they save me so much time. It's like I can deal with a 10% that [laughs] they don't format exactly the way that I would want it to. I've been using Black, is the Python one, for so long now. I can't actually remember which bits of it I don't like. [laughter] My convictions obviously weren't that strongly held after all if I can't remember what they were now. It makes it so much easier to write, and also, it is so much easier to read other people's code as well.

Ryan: Yeah, for sure. For me personally, learning TypeScript really helped my other parallel learnings. I've done just a little bit of mobile and backend work, and going into Swift or Kotlin having similar sort of IntelliSense type features was just amazing. It's like, oh, perfect. It's all right here in front of me. And then, we use Sorbet at Shopify, which has similar functionality for Rails. So it's one of those things that it feels like as an industry, that's just there now for the better.

Aaron: Yeah, it definitely is coming along. I know there are, at least in Python, there are still a few projects, Django being one who's waiting for Black to hit version one. We said that once Black hits version one, then we would run Django through Black from that point onwards. Then Django, too, will be autoformatted, which I'm not sure if it has just happened or it's just about to happen. I'm not sure. We have a board meeting next week. I'm sure I'll find out then [laughs], or it happened weeks ago if you're listening to this podcast in the future.

It really is something that, for a while, there was a lot of pushback against, and it was a very small set of developers who were using these kinds of tools. And now it's like, yeah, I'm shocked if I come into a project that is not using some kind of autoformatter. And you can tell pretty quickly I feel as well.

Ryan: I think we're sort of in a renaissance moment of developer experience, and I'm super excited for it. I think for a long time, there might have been some underlying sense of if it's harder, it makes you smarter, which may or may not be true in certain situations.

Aaron: [laughs]

Ryan: And it just feels like in more recent memory, Netlify and Vercel and some companies really made things so ridiculously ergonomic and easy to make and deploy apps. I think it makes us all better. We can understand what a good product looks and feels like better. We can be more inclusive to people at different stages of their journey and get people up and running much faster. So yeah, I'm absolutely all for it.

Aaron: Yeah, because there was a moment there where the complexity of the tooling had increased substantially. Getting started in programming was you had a text editor, and you wrote your HTML and CSS into a file and maybe a little bit of PHP. And you FTP-ed it up into the server, and it just worked. It ran, and you could see it in your browser, and all was good. And now I feel bad for people just starting it and looking at okay, well, all of your different transpilers and pre-compilers and version control.

And it seems like you need to learn a substantial number of things just to render a Hello World in the browser. So anything we can do to help with that kind of developer experience in the tooling and make it, so there's a lower barrier to entry again for people. Because obviously, it's going to be a lot more inclusive, bring a lot more people on board. Does that feed into your new team at Shopify, and what you're hoping to do there?

Ryan: Yeah, I think I'm still very new. So I will be probably not the best person in this moment to give the TLDR. But yeah, there are so many world-class people and Shopify partners building amazing extensions and apps and things like that. And I think as an org, we're looking for the best way to make all of that more ergonomic for them and to give them the tools to...you have reduced barriers to entry and to build exactly what it is they want to build, where they want to build it, no matter where that is.

Aaron: That's great. The more people we can remove these barriers from and get involved in any of this, the more viewpoints and the better the products and services are going to become for all the rest of us as well. So this is in everybody's best interests, not to be gatekeeper-y about this kind of stuff and to try and make it as straightforward for people to get started as we can.

But that is us almost out of time. I've really enjoyed this conversation. I feel so deeply involved in the whole bootcamp and code schools despite never attending one myself [laughs] just because I hear my wife talking about it so much and friends and things at work. So it's always a pleasure to speak to someone who's gone through a different one as well than what my partner has.

So thank you for indulging me on that and talking about Turing with me. I just want to give you a few moments at the end here. Where can people find you online? What are you working on that you think people should go check out? If you got any kind of links you want me to drop in the podcast description?

Ryan: Yeah, for sure. It's been an absolute pleasure to be here. I am pretty much only on Twitter these days. You can find me at @ryan_bahan, also, ryanbahan.dev. Now that I've said that, I have to redo my site that's like two years old.

Aaron: [laughs]

Ryan: So sort of making a forcing function there.

Aaron: [laughs]

Ryan: But yeah, Shopify is hiring. And selfishly, I want to bring as many people there as I can because I think it's an amazing org, and also selfishly, if you are a Shopify partner or you're interested in it or anything like that, please feel free to hit me up. If you're interested in getting into programming as well, I'd love to chat. So yeah, working on getting to know as many people as I can and learning about their experiences, and hopefully making Shopify a place that they want to either work for or work on top of.

Aaron: [laughs] I know they always have a big presence at the Ruby conferences, so hopefully, we'll get to meet in person at one of those in the near future. But yeah, I've had a blast chatting. Thank you so much for being on the show. For everybody else, this has been another episode of the Polyglot Podcast.

Launchies 2.0!

Mandy Moore — Thu, 10 Feb 2022 18:32:49 +0000

This season, we’re helping you level up your interviewing skills! Each week Lauren Lee, Danny Ramos, and industry experts will offer advice on navigating career progression within tech.

Launchies is a show for folks launching into tech, and today we're kicking off this new season! Every new season, we plan to zoom into one specific topic and provide tangible resources and helpful advice for our listeners.

✨This season is going to be all about tech interviews and landing a job!✨

Give us a follow: @LaunchiesShow

Launchies 2.0!

Launchies

Your browser does not support the audio element.

1x initializing... ×

Danny Ramos: Launchies is a tech podcast dedicated to helping early-career developers or soon-to-be devs.

Lauren Lee: We'll share insights on how to navigate these early opportunities and bring on experts from the tech industry to give advice on general career progression.

Danny: In the first season of our show, we focused on how people launched into their tech careers.

Lauren: And now, in Season 2, we want to offer advice on your career progression.

Danny: The next 12 episodes will be all about the interview and landing your first job.

Hi, everyone, my name is Danny Ramos, and I'm a Developer Relations Engineer at New Relic. I am just barely passing a year at New Relic. So I really wanted to be part of this podcast to help people in any way that I can because it's very top of mind for me. I just kind of finished this process, the whole interview, going out there and networking and doing all that. So I wanted to be able to share the knowledge that I gathered during that process.

I'm a person who went to code school during quarantine, during the pandemic. And I was very fortunate enough to where it actually worked out for me. And I'm very, very excited to be here and to be able to share that with y'all.

Lauren: And hello, everyone. My name is Lauren. I am also on the developer relations team as a Senior Developer Relations Engineer at New Relic. And I am a teacher turned coder after about ten years as a high school English teacher. I got sick of the five-paragraph essay and decided that I needed to get with the times and learn something a little bit more modern, which meant me attending a coding program in Seattle.

And I'm so grateful for that journey and so stoked about the opportunity for this podcast because it allows us to merge the worlds of all of our interests of education, community, and tech. And I think it's just going to be such a fun journey for us. Welcome to Launchies.

Danny: Launchies 2.0.

Lauren: It sure is.

Danny: This is the bigger, the better, and what's the third cool word?

Lauren: Bigger, better, more. See, I'm taking it from the lens of like; we’re zooming in. We are picking a topic, and we are giving resources. We are giving content. We are giving things that people really need. I'm imagining someone's in the world wanting to get their first tech job and is like, how? That's the person we're speaking to on this adventure.

Danny: Exactly, exactly. Whereas before, we were learning about different stories, and people could relate to the story and be like, "Hey, whoa, I also am a barista." Or "I don't know if I can get into tech," or "I'm not sure if I can do this." And then hearing a story and feeling a little inspired and thinking if that person can do it, I can do it too.

Lauren: For sure.

Danny: If code school is not that hard of a thing or it is hard, but it sounds like many people are doing it [laughs] and --

Lauren: It is hard. Let's be real. [laughs]

Danny: It is hard. As I said that, it didn't even --

Lauren: I mean, even if the two of us can do it, I think is maybe a way to think of it. [laughs]

Danny: That is true, I know. As I said, code school is not hard; tears started forming in my eyes. I was like, --

Lauren: I know the sentence...Yeah, I felt super triggered. I went to a coding bootcamp as well. But there is always someone that's like flying through the program and asking all the correct questions. And you're just like, gosh, can you slow down? Or just a serious imposter syndrome of like, well, how come they get it?

Danny: Yeah, we could have a whole episode on that, on just the emotions.

Lauren: I know, for sure. But if you are curious and want to check out a show that does highlight the untraditional career progressions, I also have a show called We Belong Here. [laughter] So go check that out.

Danny: Yes, definitely do.

Lauren: Because it is important to celebrate ways that we as second career devs have navigated it and celebrate that community. But I think here what we are excited to be doing in Season 2 is saying, okay, how can we give back to that community and provide genuine resources, and advice, and tips, and wisdom so that you feel really equipped with the tools when going out on interviews and hopefully landing that first gig?

Danny: Yeah, especially I think when people are learning about all this, whether it's in code school or learning it on their own. It's always nice to get an outside perspective, kind of refreshing that part of your brain where you're just like, I have already read about all the interviews, or I've read all about this, and my instructor has talked about these different topics. But it's nice to get an outside perspective to be like, oh, okay, there are different stories out there.

Lauren: For sure. I mean, think of us as your coding big brother, big sister moment of like, we are here to help navigate that. Danny and I have been through this, have really [laughs] been in the weeds of interviewing, and faced a whole lot of rejection. I'll speak for myself personally. [laughs]

Danny: Not much for me but yeah. [laughs]

Lauren: Okay, happy for you, happy for you. [laughter] But I think it's an interesting challenge or topic for us to think about taking on for a show. We have this idea of every 12 episodes will be a new topic. And we want to start at the beginning, and that for us felt like tackling interviews.

So starting, you know, how do you even begin the process of finding companies to interview with? And then taking you all the way through that journey or lifecycle, if you will, to finally getting the job and negotiating how to assess an offer. So going all the way through that and us being with you every step of the way.

Danny: Yeah, and at the end of each episode, we're going to have somewhat kind of a call to action to really engage with our audience and almost be like a sample test or practice for you. So we'll have different things like, oh, talk about yourself like you are answering the question in the interview. Like, so, tell me about yourself.

Lauren: Oh. [laughs]

Danny: That amazing question that's asked every time.

Lauren: Literally.

Danny: And have a little...maybe in the future we could have a technical problem that you would solve via Twitter, or some new skill sets that you would put on your resume, and something that you could just share and then see different examples from other people in the Twitter world. I'm imagining this is done on Twitter. I don't know.

Lauren: I don't know. Yeah, you keep shouting out Twitter. And that's an important thing for us to acknowledge that it's really about community and finding community when you're in these early days and trying to make this maybe transition or career leap into tech, having folks around you to workshop ideas off of or to build that network for referrals to even get your foot in the door to get an interview.

And Twitter can be that for a lot of people. It can be a dark place on the internet. [laughs] But it also, at the same time, can be a wonderful community. And especially in tech, I think there's some niche, wonderful places within the Twitter ecosystem.

Danny: Yeah, most definitely.

Lauren: Okay, so can you walk me through what we're hoping to achieve in the season, in the episodes topics-wise that fall under this umbrella of the interview?

Danny: Yeah, the interview. Yeah, absolutely. Like we said before, there's going to be 12 episodes, and each episode really focusing on one specific aspect of the interview. And so, with Episode 1, we labeled it as Starting the Process. What that means is the resume, the cover letters, and how to go about them and really just dive in a little bit and share some resources.

Lauren: Yeah, I mean, this season, we're hoping to be really specific in covering each stage that we ourselves have navigated but know that is pretty common in the interview process, if you will. So we'll start at that like, okay, how to write a resume, how to write that cover letter, how to nail those, make sure that they get seen by a recruiter or, ideally, a hiring manager. So how to get your foot in the door.

But that then, of course, implies that you're building a network and that that is a huge thing that we'll spend an entire episode dedicated towards talking about, how to find mentors, how to build up a social media presence if that is your thing. I don't know; that one is tough. [laughs]

Danny: It's tough but, I don't know, it's such a big suggestion for me whenever I talk to people who are students. I'm like, "Do you have a Twitter?" And I don't know if that's because I'm just a social media nerd, maybe because I got my job through Twitter. And we can dive deeper into that in the episode, so stay tuned. [laughter]

Lauren: Yeah, because I fall onto the other side of it sometimes too. Okay, no, we'll save this for that conversation.

Danny: [laughs] Oh, we're already starting the episodes. But for me, that makes sense for the next episode, which will be Episode 3, which is finding where to apply. And I found out where to apply through Twitter. And so we'll hear different people's stories on what was their tactic? What was their way of going about things?

Lauren: For sure. Because mine was via almost like a whisper network of where folks I knew were loving their jobs. And then, I had to create a list of places where I knew people were hating their jobs, so I knew not to apply at those particular places.

Danny: Wait, I love that you just said whisper network.

Lauren: That is what my Ada or my coding bootcamp we referred to our Slack channel as. It's like a place for us to highlight incredible teams and also to be like, hey, let's all stay away from this one. It's super helpful.

Danny: Whoa. Yeah, it sounds like a guild or something.

Lauren: Yeah, well, let's make our own guild here. That's what this can be is as like, I don't know, that could be a good call to action for that particular one is like folks that are super happy at where their jobs are. Like, where should we be applying? Just because that stuff matters.

Especially for a first-time dev, that first job you want it to be a positive experience. Otherwise, there's a high turnover rate for coding bootcamp grads or even self-taught folks. I guess, in general, just career transitioners. Those first jobs, if it's a flop or unsupportive or a toxic work environment, that can be your first job but also your last job in tech.

Danny: Yeah, you're absolutely right. And it's so important to have a mentor or mentors that can help you along the path.

Lauren: And that will be Episode 4. Love it. Okay, cool. The episode I'm particularly excited to cover is the talking about yourself one [laughs], which sounds ridiculous when I say it. But it's that how to nail concretely that 30 seconds elevator pitch when someone asks you to tell them about yourself.

Danny: So tell me about yourself. Why do you want to work in tech? Or why do you want to work at such and such company? Do you find yourself updating it?

Lauren: Yes, of course. I think because my career has changed a lot since I've entered tech. I can speak exactly to what it was during my first round of interviews trying to land my entry-level job, like my first-time dev job. I spoke to how being an English teacher translated to this industry and my coding bootcamp experience.

Now I have been in the industry for a bit, and I've had different roles. And I want to make sure that I incorporate those sorts of things like. I might say, "English teacher turned coder," and that is maybe it. What about? Do you notice this change?

Danny: Well, I was doing some research, and I looked up my cover letter, and my hook, first sentence in my cover letter is very similar to how I answer that question, like, tell me about yourself. It was actually kind of triggering because I remember saying this specific sentence so --

Lauren: Over and over.

Danny: Oh yeah, over and over and over that, I started to hate it. But it was "Two years ago after finishing an eight-hour shift in a large warehouse; I walked into an old, dingy dive bar to try stand-up comedy for the first time." [laughs] And I was like, what the heck is that? Why did I do it? [laughter]

Lauren: Hold on, stop it. So you said...It's like telling the hiring manager...you're like, "Picture this. Close your eyes. "[laughter]

Danny: I know. And it somehow worked. I don't know how I have a job but look. [laughs]

Lauren: Stop. Wow, I can't wait to dive deeply into that particular topic on that episode. My goodness.

Danny: I'm telling you. I howled when I read that. I was like, what is this? [laughter]

Lauren: Oh God. Oh, and the mean streets of Denver when you walked into a dive bar.

Danny: I had just finished my shift. I didn't even have my name badge off yet.

Lauren: Oh my God. You could smell the Costco hot dogs. God, that's funny.

[laughter]

Danny: And they were like, this man's a storyteller, my God.

Lauren: And they were like, we must have him on this team.

Danny: Stop. Stop. We can't even hear the rest of what you have to say. We are hiring you right now.

[laughter]

Lauren: And it's above what you're asking the salary, actually. Oh God, that is later in the season. But we will have negotiation tips and how to assess an offer. That's going to be a good one. Because it sounds like you really didn't have to navigate that because they were giving everything you wanted.

Danny: Oh no. I was godawful at that too. I was really bad. I was like, I don't know. What do you think?

[laughter]

Lauren: Actually, that's not a bad answer when they ask what's your salary expectation, to put it back to them. That is a good tip.

Danny: Yeah. And I was acting nervous just to make them feel more...

Lauren: Mm-hmm.

Danny: Yeah, exactly. We'll get into it.

Lauren: He's kind of like that, folks. [laughter] We're hoping, of course, it's not just going to be Danny and myself sitting here waxing poetically about things. We really want to be bringing on industry experts and mentors to give their perspective on things, folks from established and revered companies that can talk to us maybe about the behavioral part of the interview because that's one section.

But then we also realize that there's the whiteboarding, the dreaded terrified part of where they ask you to traverse a tree or do some string interpolation. That part of the interview can be very stressful and anxiety-inducing. So you're not alone in that fear. So we want to make sure that we stack the deck with really thoughtful folks that will give some tips and wisdom in that particular part of the interview process.

Danny: Yeah, absolutely. And a good handful of them are co-workers, colleagues that we have here at New Relic. So I'm excited to get to know them more and get to hear their story but also their expertise in the subjects that we have on the episode.

Lauren: And we're going to bring some folks from our team on to talk about how to interview the company back, which I think is a really good topic. It may feel like when you're trying to find your first role that, you just want to say yes to everything. You offer me a job. I say, "Yes." You don't even think about it.

But there is an important part of deciding is this going to be a good fit for you? And we'll give the example questions of how to phrase those questions, to pose them to the interviewer so that you can really evaluate it for yourself if it's going to be a safe space for you to learn and get mentorship and to grow while on the job.

Danny: Yeah, absolutely. And so through all this rambling and laughing, and tears, and just overall fun we --

Lauren: So wholesome.

Danny: [laughs] Yeah, we're just going to cover the interview, and this will be this season. And we plan on focusing on different topics each season. And so, Lauren and I will really be narrowing down this interview process. We hope that you learn some things, get inspired to get out there, and interview.

It's the beginning of the year. You probably have some resolutions; you have some intentions. And maybe those involve crying from a rejection letter, maybe making some new mentors, or talking about yourself in a cool, new, dingy bar way like I did. [laughs]
Lauren: I say a concise, clear, and pointed way. [laughter] But you know what? Potato potato.

Danny: And that's why Lauren's here, to really level me out, or I'm just going to be unhinged with the microphone. [laughter]

Lauren: Do you have any intentions for the New Year? Speaking of, when we're recording this, it's still January. I think we might be launching out in February. Who knows what this...but do you have things you're thinking about?

Danny: My intentions are is that I want to gain more technical knowledge and contribute to maybe four to five open-source projects that revolve around Rails, maybe some new framework that I haven't worked with before.

Lauren: I love that. And I think the community, like listeners, can support you in that too. That's something cool about sharing it aloud.

Danny: Absolutely. And now they will hold me accountable. [laughs]

Lauren: Perfect.

Danny: If it's October and you're like, you've only contributed to one project, you got to figure this out. [laughs]

Lauren: I think you also had one around mentorship too.

Danny: Yes, yes. And because I had such great mentors when I was in code school, I want to be there for two individuals or more or whoever needs my help and guidance in any way possible. I would like to be there for them and give them the same type of value that I received when I was in school.

Lauren: Sure. DMs are open, folks. Go ask a question.

Danny: Oh no. Oh no. What about you? [laughter]

Lauren: Oh gosh. I really want to be thoughtful around community this year. And as the world hopefully begins to open back up, I want to blend the work that we did last year, which was really online communities and on Twitch and just being at virtual events, bringing that to a hybrid and connecting...

I'm in a new area in South Florida. I've recently moved. And I'd love to know developers near me and get them excited about perhaps New Relic technologies and be supportive of people's journeys and be a champion of that also. I'm also bringing a child into this world this year which is --

Danny: Yes. I was about to say you're going to do all of this amazing work whilst having a new child.

Lauren: I have no idea how that will change things; I’m sure it will. I have to be realistic about it. But I also want to think about how I can incorporate motherhood (I don't know. Like, I even feel nervous saying that aloud.) into my code or innovative demo project ideas that support parents in tech and embed that into projects that I'm working on and things.

I think there's an opportunity for a new community too. And so I don't know what it'll look like, but I'm excited to navigate it and to be along for the ride, I think.

Danny: Snaps. Snaps.

Lauren: I think a part of me was really hesitant of resolutions and things this year because it was like, oh my gosh, I'm going to have so much change anyway that I set a goal like, I just need to survive. [laughter] But I think if I want to be realistic about it, it's really about supporting folks in our community, growing our community, and making sure that people who are on this career transition or are learning to code, teaching themselves to code, attending a bootcamp, that they know that they have us as support and not only as mentors but as friends.

When they're frustrated and banging their head against the wall because of a particular error in their code or they can't make sense of why something is breaking, that we're there for them, whether it's on Twitter or...Gosh, I'm sure we will have a way for people to reach out to us @LaunchiesShow, I think on Twitter. All this will be in our show notes, the details.

Danny: The deets.

Lauren: Clearly, we have some ironing out to do.

Danny: Yeah. And just to be clear, our DMs are open. [laughs]

Lauren: Whoa. Yes. That is true, actually. I am always willing and happy to chat with folks about this particular process. And I think it's important now that we have made it into the industry. I'm speaking in the We, but I'll say it for myself. Maybe you feel the same way, Danny.

But it's our duty to help people navigate it and bring them up and make sure that they feel like that this is a collaborative effort and that there's room for all of us to succeed. And there are plenty of jobs in tech, and there are tons of different areas to be an expert in. And we really want to be supportive of that.

Danny: Yeah, absolutely. Absolutely. So, everyone, that has been Episode Zero. This is just kind of a little sample, a Costco sample, if you will. Well, now I don't think I can say Costco, but this is a small sample, if you will.

Lauren: Is that proprietary? Was Costco coming for you as a prior employee?

[laughter]

Danny: I actually have no idea how those things work.

Lauren: Well, let's look at the legality of that because I've definitely dropped that now into the episode. [laughter]

Danny: They honestly probably do not care. They're like, well, Danny was such a good employee. Talk about us.

Lauren: For sure. They're probably like, wow, he is an ambassador even now after. [laughs]

Danny: They're like one of the only few companies that doesn't use Twitter or anything. Their Facebook is run by people who shop there. [laughs]

Lauren: That's so interesting. What an opportunity.

Danny: So here I am. This is a little small sample, Costco sample, if you will, walking around, getting a little meatball in the little paper cup. [laughter] And so this is just to give you a little teaser of what we will be accomplishing this season, being lots of laughs, being lots of education. I just said being lots of education. I don't know what we're talking about at this point.

Lauren: Packed with educational resources or tools. I'm imagining each episode...I have this visual of like a little fanny pack that we --

Danny: Let me just add real quick that as Lauren is saying this, she is dancing with each word that she is saying. [laughter]

Lauren: Because I'm now close your eyes. Picture this. [laughs]

Danny: Okay. I'm waiting.

Lauren: So we have a fanny pack that's empty, and you're about to go on a hike. And we are preparing you with individual little tools that you're going to pack to it so that by the time you're ready to go off on to that...I'm picturing like by the time you're done with this season, you can be on the bus to your interview or on your commute driving to that first interview. And you feel so equipped and ready. You have all of the tools and resources in your little fanny pack all ready to go and to say, "Here I am. Hire me. You know you want to, and here's why."

Danny: Yes. Oh, I'm seeing it. For some reason, the bus stop is on the other side of this mountain. And you're climbing up this mountain, getting all the resources. And then, once you have them, you're there. You're at the bus stop.

Lauren: Smooth sailing. You're on a sled.

Danny: Smooth sailing.

Lauren: I'm now mixing --

[laughter]

Lauren: That's a great visual! Picture that!

Danny: Someone draw this out, please. That's the first call to action.

Lauren: A graphic. [laughs]

Danny: Yeah, someone draw this graphic.

Lauren: Like little badges, little Girl Scout badges, no gender scouting badges. So next episode will be to start the process, to take from the blank page and turn that into a resume or turn that into a cover letter because that is intimidating. That is a terrifar...terrifarty --

Danny: [laughs]

Lauren: Terrifying part of the process. And yeah, you might end up applying to let's go and say 100 roles, and you might not hear back from 90 of them. And four of them will maybe turn into an interview. It's like a numbers game, and we're going to be there for you, help you make sense of it. But at least you'll feel equipped to get going with it after Episode 1, I hope.

Danny: I think so.

Lauren: I mean, TBD.

Danny: TBD. But also, we're open to feedback. If you're like, hey, Episode 1, I learned this. Thank you so much. This was amazing. Wow, when can I get my badge? [laughs]

Lauren: Let's make badges.

Danny: Now I'm thinking...Did you ever play Pokémon? I feel like you didn't.

Lauren: Sure did.

Danny: You did? Yeah! I don't know why I said it that way. We are almost the same age.

Lauren: It's okay.

Danny: Maybe because you're going to be a mother and I --

Lauren: Because I'm older, so you were aging me. Oh, I see. Wow, this feels fun. Safe space.

Danny: [laughs]

Lauren: No. Your turtle's named Tortie [SP], and my turtle was named Squirtle growing up, so that feels like important information.

Danny: Oh my gosh. You're right. Oh my gosh, you're right. I'm just imagining us as little animated characters in a Game Boy like in Pokémon, and we're getting badges.

Lauren: For sure. Aw, how cute are we?

Danny: I just want...now I'm just getting...oh wow. Okay. Wow. We could have something to talk...that's a whole nother episode.

Lauren: Wow. Now he's like, now I like her, geez. [laughter] Now she's cool. We've been working together for months. And I finally earned my cool points with Danny. [laughter] Congrats, folks. You heard it here. Wow.

Danny: Oh my gosh.

Lauren: Building connection and building friendships.

Danny: That's right.

Lauren: All right. Should we wrap this up and just let folks...Episode 1 hopefully will be dropping soon if it hasn't already.

Danny: If you're listening to this, be ready. Be excited.

Lauren: Get stoked.

Danny: Get stoked.

Lauren: Feel nervous. We're nervous too.

Danny: Get that new notebook ready to write down some notes. Get some new resources in that thing.

Lauren: Maybe a fresh page on your phone. I think taking notes electronically is an important tip so that you can do a quick search for an indexing moment. If you're wanting to look up a buzzword or something, a notebook sometimes is hard to find the answer.

Danny: You're right. Whoa.

Lauren: That was controversial because it was against exactly the advice you just gave. So, apologies.

Danny: [laughs] This is yin and yang here.

Lauren: 100%.

Danny: We have conflicting ideas, and that's why we're doing this together.

Lauren: Opposite sides of the aisle.

Danny: Yeah, you can tell that we are very different personalities. [laughter] Oh wow. Okay. So thank you so much, everyone, for listening, for being here with us, and being excited with us.

Lauren: Yeah, being a part of the community.

Danny: Exactly. And we'll see you next episode.

Lauren: And that's a wrap on today's episode of Launchies. Thank you so much for listening. Be sure to go give us a follow on Twitter @LaunchiesShow.

Danny: And if you have any questions in regards to New Relic, our amazing sponsor, the place we work at, and the place that gives me free shirts, be sure to follow us on Twitter @newrelic.

Lauren: And if you want to say what's up to us online, of course, you can follow me personally @LoLoCoding.

Danny: And you can follow me @muydanny.

Lauren: And lastly, of course, please, please go give us a rate review and follow on Apple or Spotify or wherever you get your podcasts. We will so, so appreciate it and would love to hear your questions and read your ratings and reviews. Maybe tell a friend about our show. Help us spread the word about what we're trying to do.