Lessons Learned Recruiting and Managing Junior Developers for 10 Years

Alex from Scrimba
Alex from Scrimba
Lessons Learned Recruiting and Managing Junior Developers for 10 Years

✍️ Want to support the podcast? Subscribe in your favourite podcast app and leave a leave a 5 star review here.

🎙 About the episode

Jason has been recruiting and supporting Junior Developers for more than a decade! He joins us to share his inspiring story breaking into tech after sustaining a head injury, and what he’s learned about how to find success as a Junior without a degree along the way.

🔗 Connect with Jason

⏰ Timestamps

  • Introduction (0:00)
  • How a head injury at 16 influenced Jason’s career path (01:27)
  • Interns vs. juniors (05:07)
  • Job titles matter, but not for the reasons you might think (08:04)
  • Are there more juniors than junior jobs? (10:35)
  • Why recruiters sometimes get it wrong and what that means for you, the candidate (11:38)
  • The job description is not a list of hard requirements (15:44)
  • How to improve your self-awareness (19:05)
  • Coding vs. programming and why it matters (22:04)
  • Justin’s favourite question to ask during interviews: What games do you play? (23:40)
  • Are you born or made a programmer? (24:56)
  • Tech is vast and has many career paths to offer (27:26)

🧰 Resources mentioned

⭐️ Leave a Review

If you enjoy this episode please leave a 5 star review here and let us know who you want to see on the next podcast.

You can also Tweet Alex from Scrimba at @bookercodes and tell them what lessons you learned from the episode so they can thank you personally for tuning in 🙏

💬 Transcript

Alex Booker (00:01): Hello, and welcome to the Scrimba Podcast. On this weekly show, I speak with successful developers about their advice on learning to code and getting your first junior developer job. I'm Alex, and today I'm joined by Jason C. McDonald from Canonical, which is the company that publishes the Ubuntu operating system. I was browsing Dev.to one day, as you do, when I saw Jason sharing some strong opinions about what it really takes to find success as a junior developer. I was keen to speak with Jason, learn and share his knowledge with you listening, but I couldn't have predicted how remarkable Jason's story is. When Jason was young, he sustained a head injury that changed the way he thinks. Despite getting good grades at school, that made it difficult for him to follow a traditional career path. And that background, combined with his disability, made it unusually difficult for Jason to find success. Yet, here Jason is, not only thriving, but bringing the next generation of coders up with him. In this episode, we talk about the differences between interns and juniors, why you do not need a computer science degree, and if companies are really looking for juniors they can train or do they really want juniors who can literally hit the ground running on day one. All that to come and more. But for now, this is the Scrimba Podcast, let's get into it.

Jason C. McDonald (01:27): I made an odd entry into the field. I first tried programming when I was 14 and hated it, and decided this was not for me. I wanted to go into the medical field. That was my goal in life. But a head injury when I was 16 changed my plans completely. I went from college level reading, 4.0 sophomore, to failing [inaudible 00:01:46] material. I fell down some stairs. So that dramatically altered my plans for my life. I had to rebuild my academic ability, and along the way discovered that my natural proficiency for biology and chemistry was pretty much gone. But I had gained a natural proficiency for math. And with that, came the ability to program. As I started learning it, as I picked it up again, at my mother's encouragement, I discovered it made sense. And so I started using that to try and prototype some ideas for some educational games, because I had used educational software, but I had some old stuff for the '90s, you probably see over my shoulder, I've got all those 1990s educational games like Carmen Sandiego, and what have you. And I had used that not only in my education when I was a kid, but also in recovering from the head injury. But there wasn't much out there. I wanted to build some high quality games that could run on older machines as well as newer ones. So I learned how to code, started prototyping some stuff. Started building some stuff. So I did graduate high school, 3.98. They were very good to expunge two years off my record, the two years I was relearning everything. Went on to college and I took programming in college. I took one class. But about halfway through the semester, my computer science professor pulls me aside and goes, "You are a book learner. Don't waste your money on the degree. You're going to learn a lot faster from books, from self-teaching." She actually said that. So she said, "You are already miles ahead of the rest of the class. And honestly, the degree program is just going to slow you down." I shifted my focus around that time towards getting a degree in communication, which I never actually got. I quit before I finished, because it's like, you know what? I'm spending $7,000 a year for what exactly? A piece of paper? I don't need this. So I got the knowledge I needed and moved on, which is life hack the way to do college. If you need the piece of paper, go for it. But [inaudible 00:03:38] you need to learn and move on. But while I was still in college, like I finished that one class, and this computer science professor had kind of become a bit of a mentor to me. I started looking at the fact that I was basically doing this project solo. And I thought, this is kind of a pity because it's a big project and I don't want to go the traditional route of starting up this big old business and getting investors and building this unicorn 10X developer empire building this game. That's just not for me, but I want to build this. And I recognize an opportunity where other people could use this project to learn how software development worked. And so I was thinking, I was playing with this idea of starting an internship. I talked to that same professor. I said, "I feel like I could start this internship, but I'm also having my doubts because like, who am I? I've been doing this for what, three years, by this point, what do I know?" She said, "Well, have you ever actually created a piece of software that you shipped?" I was like, "Yes, I have." She said, "Well, then you already know more than most college students. So you're 100% qualified to run an internship, because you've actually shipped software and most of these students have not." And so I started the MousePaw Media Internship Program around that time, and I still run it today. And that's kind of how I got into mentoring interns. So I've been running that internship since, and I'm going to date myself here, 2014. And it's been an excellent experience. I learned a lot from working with interns. You'd think me being the senior developer, I would be teaching them everything, but they bring ideas all the time that surprise me.

Alex Booker (05:07): What is the difference then between an intern and a junior developer? From my impression, someone who does an internship normally goes through the degree route. And there's a placement for a period. And they get a lot of handholding. They really have very little expectation in terms of what they know. They just need to be on the right track. Whereas juniors, maybe they get paid a salary and have slightly higher expectations to get their foot in the door in the first place, since there's a bit more of an expectation that they start to contribute a bit earlier in the process. How would you compare the two?

Jason C. McDonald (05:39): I would largely say it's all arbitrary because if you want to talk about like an intern at Google or an intern at Valve or something like that, from everything I've ever been told, they're fighting tooth and claws just to get in the door. And it's like a really intense thing. Whereas a junior developer at some companies can be basically just slightly above fetching coffee. Titles in this industry are so stinking arbitrary, it's hilarious. We make things up. We just make crap up. Really, at the end of the day, what's important is what that job description actually is. Because for me, I picked the term intern only because it was the most familiar to the college students who were going to be applying. They were looking for an internship per se. And so this would be more recognizable to them as being the opportunity they were wanting. But especially given the fact that I don't even get paid, MousePaw media's not in a position to make money. We're making an open source game engine. If we ever make money, it's years, years, years out, which is fine. I didn't start this to make money. But it means that nobody gets paid, including myself. And so it's not exactly junior developer by some standards, but it is by other standards. And typically, the job title is junior software engineer. Again, those job titles are so arbitrary. I think the important thing to look for when you're looking at any internship or junior developer or any entry level opportunity is to talk about what is the job description? What are the expectations? Because every company's different. The thing you want to make sure is that you're going to be working on real code. If they're going to have you go off and do some little unimportant side project, or basically just sweep the cobwebs off someone else's code, and you don't really have any opportunity to contribute, you're not really developer at that point. At that point, you're basically just a gopher. And that's not the sort of opportunity you want to immerse yourself in because, I mean, unless you don't have any options, it might look good on paper, but it's really not a good opportunity in most cases, because when you're just doing that, you don't really get to gain any practical, real world experience with coding. You want to work somewhere where, even if it's a small contribution, where you're going to be doing something that actually has a meaning to the project. And if the company struggles to define what that is, then they may not be in a good position to mentor.

Alex Booker (08:04): I've worked at startups where one role was not getting very many applications. So they just changed the job title to something trendier where the market was going, because it's just a marketing tool, a way to attract candidates. And then yes, it's also kind of arbitrary because I've also seen people change that job title in the email signature, depending on who they're emailing to get the best result. And the reason why I say all this is because a lot of aspiring developers, they will stress about what do I write in my LinkedIn description? When actually, if you've written code, you are a developer, you want to choose the title that recruiters are looking for, coming full circle here, because a title is just the marketing tool, essentially. It's there to attract and connect people. And then what happens next is, you look at the job description, you do the interview, you kind of explore from there. So couldn't agree more basically.

Jason C. McDonald (08:50): Exactly. And on that note, I should mention, I was looking for work for many years. In addition to MousePaw, I work full-time. But I was looking for work for a number of years. And ultimately came down to two things for me at that point, looking for work as a senior developer. Two things I discovered, one was, unfortunately, discrimination is a very real thing in this industry. I have a disability. And ultimately, I figured out that a lot of times I was turned down because of that disability. They come up with all sorts of cacamamie excuses, but it's just a matter that they don't want to hire somebody who has a nontraditional background. The only reason I have a nontraditional background is because of my head injury. And there's a lot of companies that will, they want you to have 10 years experience on a five year old platform. I wish that were just an internet meme. It's not. It is actually not. There was actually a guy who posted that he saw a job description for, I think he said, "Required, minimum five years experience with FastAPI." He said, "I wouldn't be able to apply because I only have 2.5 years experience with FastAPI, being the creator of it." So there's that little issue that unfortunately bias comes in all sorts of forms. Indirect bias is a thing. It's like, "Well, we're not ruling you out because of your disability. We're ruling you out because of your unusual experience because of your disability." And that's still discrimination. But then on the other hand, I found that I had to changed my title because I had senior software developer on my LinkedIn and on my resume. And it was weird because as soon as I changed that from senior software developer to senior software engineer, then I started getting contacted by recruiters.

Alex Booker (10:31): Just like that. That's crazy.

Jason C. McDonald (10:33): It's like, how arbitrary is that?

Alex Booker (10:35): I don't know what your impression is, but I get the feeling, and I'm very reluctant to say this because it is a feeling. I don't have data. And it can be a very discouraging thing to hear in a sense. But I do get the feeling that there are more candidates than there are job openings. And in a market sense, what that means is that the onus is on the candidates to make themselves discoverable and to standout. The employers back then, they could have been searching for engineer or developer. They just didn't need to, maybe. Whereas once you changed it and satisfied what they were looking for, that put you in a more favorable position, i.e., the onus was on you.

Jason C. McDonald (11:10): I would estimate there's probably roughly as many openings as there are candidates. The problem is that we have this little obstructionist layer we call recruiters. And the problem is, recruiters, whether they're HR employees internal to the company, or whether they're third party recruiters that were hired as contractors, don't know how to code. They don't understand coding. These are the ones who are making up the five years experience required with FastAPI requirements.

Alex Booker (11:36): No developer is writing that. Yeah, fair enough.

Jason C. McDonald (11:38): They don't know what they're looking for. So they think, okay, we need somebody who is an expert in Java and Spring and this, because we're working on a Java Spring application, therefore we have to have someone who knows Java and Spring. And of course, that's nonsense because developers know, it doesn't matter if they know Java or Spring. If they know how to code and have worked with a GUI framework, they can pick up Java and Spring. There are some exceptions. Sometimes you need an experienced senior developer who knows that language inside and out, but that's not the lions share of applications. Most of the time, you just need someone who can craft computational logic effectively and knows how to engineer code. And that's all they really need. And so, they wind up weeding out all of the qualified candidates, and then they're left with the pool of candidates who know how to lie really, really well. And then, of course, they don't make it through the gauntlet when they actually have to interview with the real developers. And so you wind up with all of these unfilled positions. And actually there are companies that I'm familiar with that are hiring and have hundreds, literally hundreds of open positions that they cannot fill despite the fact that they have thousands of applications a month. And they cannot fill these hundreds of positions because the recruiting processes are actually eliminating the qualified candidates. That's frustrating to hear when you're searching for a job, but it's also helpful because you know that if you know the recruiting process is broken, then you know the only way you're going to get in to a position, 9 times out of 10, is to know somebody on the engineering team, which is why networking is so important. If you know somebody on the engineering team and you can form a relationship with them, that can get you in, even if there's no way into that particular team. If you have a rapport with an engineer, engineers talk. Go to the local user group, for whatever language you're in, get involved with the community, make connections, make contacts, and make it known you're looking for work. My current job, I got through my Python user group. And it was a referral of a referral of a referral. It was like a third level referral into the company. That's not atypical.

Alex Booker (13:46): If you are enjoying this episode of the Scrimba Podcast, can you lets us know? I mean, seriously, sometimes when you make a podcast, it feels like you are shouting into the void. There's no comment section, and the analytics aren't that great. If you are enjoying this episode, please share it with your friends on social media or in your communities. And remember to @ mention me, Alex, my handle is in the show notes and/or Scrimba. I want to thank you personally for tuning in. Seriously, try me. And yes, word of mouth is the single best way to support a podcast that you like. So thanks in advance. Back to the interview with Jason. You spoke about, from your perspective, how most of programming is about the methodology. So an if statement in JavaScript is the same as if statement in Java, data types and things. A lot of it transfers. your problem solving skills, your ability to work on a team, your appreciation for how software is built and how to collaborate, this has nothing to do with the technology stack, right? And these are actually the hard things. These are the things that take the most time to build. But you're saying that recruiters, especially, don't necessarily appreciate that these skills parlay and transfer. And so, from my perspective, there are companies that just want to build more software as quickly as possible to make more money. So they might take the school of thought that, well, we'd rather just find someone who can get the job done on day one or day 10, whatever. Whereas there are other companies who are a bit more passionate about software, I think. They are actually hiring for their team. There is an engineering team, want to work with great people, they want to bring each other up, they want to create a difference. I know there's a lot in between. I'm just kind of painting polar opposites here, I think. Are companies mostly looking for juniors they can train up or are they looking for juniors who can hit the ground running already?

Jason C. McDonald (15:30): I do have to say, really quick, on the note of what I mentioned earlier about referrals. Once you get past that, the recruiters, the HR trolls, and that's not to say all of HR is bad, but-

Alex Booker (15:41): No, no. We like recruiters on the Scrimba podcast.

Jason C. McDonald (15:44): But the trollish ones. Once you get past the bridge troll, and you get to talk to the developers, you will discover really quickly what I've heard and over again is, oh, the job description. Those aren't hard requirements. They may be prepared to dismiss many or all of them because they didn't write those requirements. And most of them aren't going to matter. So knowing that when you're looking at jobs, especially. And even though the recruiting process is broken, you know what? Apply anyway. Apply if you think that the job sounds interesting and you're anywhere near the ballpark. Even if it says, degree required. Well, I don't have a degree. You must know JavaScript. I don't know JavaScript. Whatever. If you think it's interesting, apply anyway. Seriously, just apply anyway, because sometimes you will wind up getting one of those good HR people, or you'll get one of those companies where it's actually developers who are screening the applications. And you may actually have a shot at that. So don't let the job description deter you. Worst thing they could say is no. And then you're in the same position you're already in. I think the important thing from a developer's perspective is to become proficient in the language that you're in, or the language that you're working with already. And if you discover that you enjoy it, that you enjoy the tech space you're in, dig your heels in, get good at it. If you don't like it, go looking. Find something else. Experiment. Play with different things. Find a sector you enjoy, dig in and learn that stack well. Because a lot of times, there's a bit of a risk reward kind of situation with companies and training. And you can get away with more of this when you're a junior developer, because they're assuming they're going to train you anyway. Basically they don't want to have to teach you basics of coding. If they have to teach you programming 101, they're not going to be happy. But if you know the essentials, if you know the basics of the field that you're working in or the specialty you're working in, then a lot of times I think companies are willing to put in some training effort. That goes down the higher up in the ranks you move. So they're going to be willing to put less training in on a senior developer than on a junior. That said, it doesn't mean it's none. And it varies from one company to the next. There are companies out there with completely unrealistic expectations who, when they say junior developer, what they really mean is a senior developer that we can pay $10 an hour.

Alex Booker (17:56): Yeah, that's not okay.

Jason C. McDonald (17:57): And then there are other companies that when they say junior developer, they mean you know the absolute bare basics, and you're willing to let us mentor you. So again, it's part of that conversation. When you're interviewing with the company, it's important to remember that you're interviewing them too. They need to prove themselves worthy of you because you actually have something to contribute to that team, to that company while you are proving that you're a good fit for them, and that you have something to offer their specific team. And remember too, every team has a very specific puzzle piece, shape, hole that they're looking for somebody to fill. And if it's not you, it's not personal. They're looking for somebody with some specific traits and skills that are sometimes hard to describe. And so, bearing that in mind helps deal with what sometimes feels like continuous rejection. But at the same time, this is a two-way relationship, and recognizing what you need as a developer. If you're the type who needs to be given an assignment and given the latitude to work on it yourself, or whether you're the type who needs more collaboration and mentorship, knowing that is helpful when you're applying, because different teams handle that in different ways.

Alex Booker (19:05): That's hard, by the way, to be that self-aware, especially when you haven't done the job already.

Jason C. McDonald (19:10): It can be. And this is one of the reasons why it's important to get experiences outside of a full-time job early. One of the reasons why I run the MousePaw Media Internship is because this is six hours a week, it's fully remote, and it's an opportunity for people to basically try the career on for size, and discover who they are as a software engineer, and where they fit in the larger space, or sometimes discover that they don't want to do this at all, and that they would really rather be an accountant. And that's okay. That is a healthy and normal part of the junior process. You're evaluating the career too. But that aside, internships like that could be hard to get sometimes. There's like three month internships. There's longer ones. There's junior developer positions or summer jobs. But then there's also open source projects. There are programming communities, there are hackathons, places like Dev.to. And getting involved in as many of these sorts of things as you can, especially early in your journey, is helpful because it helps you learn who you are as a developer, the sorts of problems you like solving, and the sorts of team dynamics that you like working in. And it's really important to figure that out before you wind up in a 40 hour week job. Because once you're in that 40 hour week job, you're kind of stuck more or less. Yes, you could technically leave, but you really don't want to at that point. You want to get at least some time out of that job, because it looks really strange on a resume when you have like four full-time jobs in a year.

Alex Booker (20:39): It is such an interesting thing about our industry. And it's both a blessing and a curse. There is very little barrier to entry in the sense that you need a computer, an internet connection, and some aptitude for programming. There are free resources. And I think as you're demonstrating today, as a reflection of our community, a lot of self-taught developers want to support other self-taught developers. It's a fantastic place to be. The sharp edge of that is that, because the barrier to entry is so low, many people can try their hand at it. And also, it results in something called experience inflation where every year the barriers to entry level jobs get a little bit harder. And that can be tricky. But if you are to go to meetups and you are to work on open source projects, you're not just learning about yourself and how you like to work, to your point, Jason, but you're also getting better, presumably. You're learning how to collaborate. And that's important. And if you're documenting in any sense, maybe on Dev.to, maybe leaving what we sometimes call a learning exhaust trail on Twitter, or Polywork is a more modern version where you just kind of document what you've been working on. This is going to help you get your foot in the door, so to speak, because you now have a way of demonstrating that this isn't just a hobby for you, something you picked up and dabbled with in 90 days. By the way, just on the slight tangent, I love how there are so many books about learning to code in three weeks or boot camps that give you a job in 90 days. I spoke with Danny Thompson on the podcast a few weeks ago, and he was like, "You know that show, 90 Day Fiance, they can't even get a fiance in 90 days."

Jason C. McDonald (22:04): The reason there's so many of those learn coding in 30 days type situations, and the reason so many people kind of, I hate to use the term, but fall for it is because it's attacking the wrong half of the problem. It is literally taking the easiest part of the job to wit writing computer code, which is the easiest part of the job. And it is making it the main and plain thing. We're programmers, so we should be programming, right? It's like, well, in my 12 years of coding, I have spent over half of my time communicating. That's more than half the job. Communicating with other people, expectations from clients, ideas with coworkers, needs and timelines with managers. You are communicating. Effectively, you're a translator for this pile of rocks we call a computer. And so you have to translate from all of these non coders and all these people who aren't on your project, or maybe are on your project, you have to translate all of that into computer code, and then the realities of what the computer's doing back to those people. That's most of the job. That's like 60% of the job. The other 40% of the job is debugging, which by the way, there's a question that I always ask in interviews. Most don't, strangely. I've never actually encountered this question in any other job interview. I always ask, "What sort of games do you play?" And I find that's helpful because one commonality I found with software developers, young software developers who are starting out but have a natural proficiency and are going to do well in this, typically, not always, but typically, like puzzle games and strategy games. And interestingly, I've noticed beginnings of correlations between the types of games they like and the type of coding, because there are different specialties. But I've noticed a lot of developers like Sudoku. And if you like Sudoku, you're going to love debugging because it's process of elimination. But that's most of the job right there.

Alex Booker (23:56): I'm just going to say, if somebody asked me about my video games in an interview, I don't think I would get the job. Because I don't think Call of Duty counts as logical thinking, to be honest.

Jason C. McDonald (23:56): It's strategy. It can be.

Alex Booker (24:09): That's so interesting you mentioned that, because my favorite part was always learning the map and figuring out clever ways to trap your opponent and things rather than relying on aim and all that kind of stuff. And teamwork, by the way, because I always felt better playing with four or five people with their microphones on, where we could work as a unit. So I don't know, maybe you're onto something.

Jason C. McDonald (24:29): I notice there are a lot of developers who like that too. And if you think about it, strategy is really just applying the algorithms. You're figuring out the most efficient way to use what you have to solve the problem. And that's all you're really doing with coding. You have these tools, you have these options. Given the toolbox you have, how do you most effectively solve the problem? It's strategy. I would have to do some research, this just kind of anecdotal. But I do think there is some correlation there.

Alex Booker (24:56): Do you think that some people are just kind of born with better potential to be programmers than others, or has anybody got a chance of becoming a developer?

Jason C. McDonald (25:04): What I don't want to get into is, I don't want to get into gate keeping and saying, well, you have to be a certain type of person to be a programmer. But to borrow from the movie Ratatouille, where the main chef is talking about anybody can cook, anyone can cook. Well, if you've eaten some [inaudible 00:25:20], you know that it's not exactly what it says on the label. Not everybody can cook, but a great chef can come from anywhere. And so it's important to bear that in mind, is that you may not actually be a good programmer. I just want to throw that out there. And sometimes it takes some pressure off. You may not be good at programming. I've encountered people who are not good at it. And it's okay, because they don't like it either. You may even kind of enjoy it, but just not have a proficiency for it. But you also might. A good programmer can come from absolutely anywhere. But the things that I notice programmers typically have is they have a love of problem solving. They have an ability to communicate. By the way, if you don't like communicating with other people, this is not the industry for you. Because like I said, more than half the job is communicating. You may enjoy programming as a hobby, but don't become a developer.

Alex Booker (26:07): It's ironic, isn't it? Because the original image of programmers was like basement dwellers and things like that, just you and your computer code monkeying away. But that couldn't be further from the truth of our industry.

Jason C. McDonald (26:17): Very damaging stereotype, in fact. Yeah. But then the other thing is, I would say numeracy. We hear a lot about, well, you should be good at math. Not necessarily. You don't necessarily have to be good at maths right now. But you should have numeracy. You should have the capability of learning and working with numbers. So if you can play with numbers at whatever level you're at, if you enjoy mucking about with numbers, and you have the ability to learn new ways to do that, that's what you need in terms of mathematics. You can learn calculus, trigonometry, linear algebra, whatever, statistics, as you need it, you don't necessarily need it right now. The important thing is to have that numeracy. So with problem solving, communication and numeracy. And if those are things that speak to you, that you have, then you have the potential to be a good developer. If those are things you don't like, but you like computers, there are things like developer advocates and other roles in the industry that aren't as tech heavy. There's also some things you can do that aren't as communication heavy that can let you play with computers and code without having to be a software developer. But if you want to be a software developer, those are like three very important pillars.

Alex Booker (27:26): I think the key takeaway there is just how broad the developer industry is. There are lots of different types of tech stacks that require different specialties. I've certainly never needed to use calculus to build a React application, say. But you certainly have relied on things like trig and calculus to build a game engine. Some people, they get into tech and they realize, huh, my passion was actually being part of the sales calls, helping customers. And they go into like sales tech. Or they give that actually they like talking with other developers and they do developer relations. Or maybe they have a very methodical way to approaching projects. And they would like to become a project manager of some kind. Likewise, you might just get exposed in that workplace to something that surprised you, like design, and realize that your passion was for design, not for development after all. Just opening the door is the most important thing. And I hope sincerely that in this episode we've given you some ideas about how to do exactly that.

Jason C. McDonald (28:18): And remember, tech companies have more than just developer roles. If you have the basic ability to just kind of understand what's going on with coding, but you want to go into one of these other fields. There are jobs for you. Because it is endlessly frustrating working with sales people or hiring people or recruiters, managers, whatever, who don't know coding. So if you understand and can kind of speak the language, that is a huge asset. You don't have to just become a developer if you like to code. There are so many options.

Alex Booker (28:47): A hundred percent. Jason, thank you so much.

Jason C. McDonald (28:50): Thank you. This has been fun.

Alex Booker (28:52): That was Jason C. McDonald. Thank you for listening. By the way, if you made it this far, you might want to subscribe for more helpful and uplifting episodes with recently hired juniors and industry experts alike. You can also tweet me, your host, Alex, my link is in the show notes, and share what lessons you learned from this episode so I can thank you personally for tuning in. Again, my handle along with Scrimba's is in the show notes. See you next week.