The Scrimba Podcast

Alex Booker:
Hello, coders, welcome to be Scrimba Podcast. On this weekly show, I speak with successful developers to learn their advice on learning to code and getting your first junior developer job. My guest today is Erik Hanchett, who is a front end engineer at Amazon Web Services, author of Vue.js in Action, and the Erik behind the Programming with Erik YouTube channel. Now, if you are a Scrimba user, you might recognize one of our teachers, Dylan Israel. Well, Dylan and my guest today Erik have a podcast together called The Self-Taught or Not podcast. In one of those episodes, Dylan interviews Erik about his journey in which he toiled to become a developer.

Alex Booker:
Rather than ask Erik to repeat his story, you can check out that episode of the Self-Taught or Not podcast if you wish. Instead, here I wanted to ask Erik for his streamlined and specific advice on how he would approach getting a developer job today. We spoke about meetups and how, if you're helpful, opportunities will come your way. We spoke about how to slide into a recruiter's DMs, respectfully, to stand out. And we also spoke a little bit about Vue.j versus React, and which you should learn. Spoiler alert. It doesn't matter. Just pick one and get good at it. And with that said, let's get into it.

Alex Booker:
Hey, welcome to be a Scrimba podcast. Erik, it's so great to have you.

Erik Hanchett:
Hey, how's it going?

Alex Booker:
I listened to your whole story on the Self-Taught or Not podcast, which is a podcast that you cohost with Dylan Israel. And I think your resilience stood out to me as being super inspiring. You faced quite a lot of rejection, and honestly, some of it was out of your control, but you still stayed focused, and now you're doing really well, obviously. I think a lot of people listening to this podcast are planning or in the process of applying to their first junior developer positions. Some rejection is inevitable. How would you suggest someone listening think about rejection and mental toughness as you demonstrated in your life?

Erik Hanchett:
That podcast you listened to was just a lot about my journey of going all the way from high school, going to college, dropping out of college, going back to college, getting into tech, getting rejected a lot. So I think going to the part about rejection, it's just human nature, it's going to happen in your life. It's just common is maybe a better way to put it. Every time you get a rejection, it's a learning experience, it's a time to reflect back on what you know and what you don't know, and what you can do to get to that next step. I've definitely been rejected.

Erik Hanchett:
I think one of my first jobs, my first tech job, I was so excited, I got an interview for a large tech company. It was an all day interview and I remember being so nervous and going to their offices, which was literally a 45 minute drive from my house, and just going through one white boarding interview after another, and then halfway through they took me to lunch. So they drove me to Subway, which I don't know if that should have been a reflection of like, "Maybe this isn't the best place. They got me a cheap lunch." But I'm sitting there, everybody's talking around me, nobody's talking to me, like I wasn't even there. So I literally knew at that point, maybe this interview isn't going very well. And then the afternoon interviews were okay. I don't think I nailed them.

Erik Hanchett:
And I think the last interview of the day, the interview was with HR, and they were asking me questions about what I worked on in school. And I told them, "Oh, I worked on this project." Like, "Oh really? You're the person that... I didn't think you worked on that project." I'm like, "Yeah, yeah. I worked on this project." But they were a little dismissive of me. So I went home feeling rejected, like, "Oh my gosh." This was my dream job out of school. I thought this could have been the job that propelled me in. And I felt I didn't do very well. But I had a hope, maybe a glimmer of hope, and I had emailed them and they just blew me off. For two weeks they didn't email me back, and I was waiting to hear back from them because I was waiting to see if I got the job before I started applying for other places. And finally probably three weeks later they finally said I didn't get it. And I was crushed.

Erik Hanchett:
And I took that as my first rejection, first time trying to get a job, and just fuel of like, "Okay, why didn't I do well?" I wrote down in a notebook all the things, all the different parts of the interviews, the questions I was asked so I understood how to answer them correctly in the future. And then I took this approach at the time of just trying to get better at interviewing. And at that time I didn't do any research online. I didn't do any mock interviews. I didn't have any of that support network. My idea was like, "Let's go out there, interview with places, get better at interviewing, get better at rejection," because it doesn't mean... It doesn't reflect anything on you personally. You should never take it personally. It's just something that happens. It's a skill that you need to get better at.

Alex Booker:
Can I just say those guys sound really rude.

Erik Hanchett:
That's one nice thing too. You can always think, "Well, maybe I dodged a bullet," if you didn't get the job.

Alex Booker:
That's a very good point. But what you're saying is that rejection isn't the be-all and end-all. If you're actually thinking about it productively, you can channel your learnings so you can make the next positive step. And that's exactly what you did.

Erik Hanchett:
Exactly.

Alex Booker:
This was happening a while ago, right? Things have changed a little bit since then. In particular, there were some factors in the economy and stuff that made it a little bit harder to get a job. You were going through a very specific stage in your life. I wonder if today, hypothetically, you were looking for a junior developer role, what strategy would you employ so that you approach it productively?

Erik Hanchett:
That's a good question. To put this in context for people listening, I graduated college in 2007 and I looked for my first role in about 2007, 2008. I had a computer science degree and I had a four year college degree. So it was a little bit different back then. FreeCodeCamp was not out. YouTube was out, but it was nothing like what it is now. Scrimba didn't exist back then, so couldn't get amazing content from Scrimba. To answer your question, if I was a junior dev, I would first just take advantage of those amazing resources, Scrimba, all these other free resources out there, to get myself up to the point where I can at least talk intelligently about these technologies. I can create my own websites. There's free hosting. You can use Vercel. I'm a big fan of AWS. Amplify is a product I work on. So you can use Amplify to host your website 100% for free and use different technologies.

Erik Hanchett:
So creating your portfolio would be important. But I also say, and this is probably something not everyone agrees with, maybe it's a little more controversial, but I think if you have the chance between working on a portfolio and doing networking, try to network first, because knowing people is going to get you a foot in that door. So if you're a junior dev nowadays, unfortunately, there's a lot of competition and you need to try to stand out to be able to even land an interview. I've seen two approaches. The spray and pray method, where junior devs just send out hundreds, if not thousands of resumes and apply for hundreds of jobs and you put a quote on yourself, like, "I'm going to apply for 20 jobs today." So you go to 20 different jobs and you just do that every single day. And if you're really ambitious, you do it from all over whatever country you're in. You're like, "I'll relocate, I'll do anything."

Erik Hanchett:
But I really like the idea of... And there's many ways of doing this, but I really like the idea of trying to come down with maybe 10, 15 jobs that you really want to go for, and then see if there's any way that you can network with the people at those jobs. That could be going to meet ups and meeting with people. Fortunately, with COVID and everything just crazy happening, all those went online, but I think they're all starting to come back in the last three or four months, and some of them are still doing it virtually. Some are hybrid, some are do virtual and in person. I would recommend if you can to go in person and just try to meet with people. I was a part of a JavaScript meetup here, where I live in Reno, and one really cool thing they did is at the beginning of every single meeting, they said, "Raise your hand if your company is hiring." And then five people would raise their hands.

Erik Hanchett:
And you could then after the meeting was over, go and talk to those people like, "Hey, I'm looking for a job. I saw your hand up. Who you looking for?" And sometimes companies would actually sponsor our JavaScript meetups, and that was another way we can get a hold of people at those companies. So look for opportunities like that. And one more thing, another quick tip. I don't think anything's wrong with trying to look up a company, especially if it's in your local area that you're interested in, and connecting with those people on LinkedIn. Don't try to be deceiving them. Just be very blunt. Like, "Hey, I saw your company's hiring. I'm Erik. I'm a brand new junior developer. I went to XYZ bootcamp. Here's my portfolio that I've done from all these different projects. Here's whatever, something that makes me stand out. Can we be friends? Could I talk to you?" And then try to network that way. As long as you're not being deceiving or you don't... I've seen people connect on LinkedIn with somebody and then connect with my manager. I don't really like that, but you can try to be creative on it.

Alex Booker:
It's mad. I've not been to an in-person meetup in so long. I remember a meetup I used to go to and the first place I ever gave a talk was the London Node user group, and they did the same thing. At the beginning of every session they say, "Raise your hand if you're looking for work, raise your hand if you're looking to hire." But yeah, there was this one guy who every week, week after week, he would raise his hand, raise his hand, and his resilience was cool. And one day he didn't raise his hand and someone asked him like, "Hey, what gives?" And he's like, "Yeah, I got a job from this guy." It paid off and he got the job.

Erik Hanchett:
That's awesome. There's so many cool success stories from that. That's a good point. Having that resilience and going and trying over and over again, because you may find out if you just go to a meetup once may not happen, nothing might happen. But if you go to multiple meetups and probably any large city has, lots and lots of meetups, especially in the tech side, you might have a JavaScript, might have a PHP, it might have React. So maybe try a few.

Alex Booker:
And there's a playbook, almost. It's not so ambiguous how you are successful at a local meetup, endeavor to give a talk, that puts you front and center, and you get a chance to demonstrate your knowledge. And also people will come up to you afterwards and ask you questions, typically. That's really great. Meetups struggle for help when it comes to even recording the videos or organizing, or just cleaning up afterwards and stuff like that. Just by being helpful, you'll get some opportunities. But the other thing you mentioned, Erik, which I really liked was utilizing LinkedIn to network with someone. Yeah, I don't when that person you described there going above one level, but if you can figure out who the hiring manager is, or the person involved in the interview process is and make a personal connection and maybe show the enthusiasm that you have that won't necessarily come across in a cover letter, how would someone go about doing that, do you think?

Erik Hanchett:
I've done it, and I've had other people do it to me and the way they did it is they just researched the company online that they were interested in. A lot of times, when you go on LinkedIn, you can look up company names and you can see lists of employees from there. Or if the company is any way public, they have a blog or they have... A lot of those developers might be on Twitter. You might be able to connect with them through there. You don't have to necessarily do LinkedIn, but there might be a few other ways to connect with them.

Erik Hanchett:
One thing I I've seen work and I've heard other people do too, is you could try to create a very focused application that demonstrates what that company's all about. So if you were trying to get a job at a company that did testing, testing software, maybe use their testing software, create a blog post about it, put it out there, tag them on Twitter or whatever social media platform it is. Try to get on their radar, follow them back, and then see who responds. You might be able to get ahold of a hiring manager, might be able to get ahold of some people that weren't there. So that's another way.

Erik Hanchett:
You have to do... I don't want to call it stalking, but you have to stalking in a good way to figure out this company that you want to work for, who is working there and how you can get on their radar. Another approach I've heard is... There's this idea that you can work in public. I think this term has been been thrown around in the last year or two, a couple of people have been talking about this. Swyx, if you look his name up, he's a guy that's been talking a lot about this.

Alex Booker:
Funnily enough, Erik, Swyx was on the podcast two episodes ago.

Erik Hanchett:
Oh wow, that's awesome. I did not know that. So he has this idea of... One of his many ideas. He has this idea of creating content online and also being very specific about who you want to target on that content. So instead of just trying to build an audience, which you could use later on, and that's not a bad strategy, that's something I've done. You can also call it building a personal brand, where people know, like, and trust you and it helps you get opportunities. And I've had many opportunities because I've written blog posts, I've done YouTube videos and things like that. But you could also create content specifically for a specific company or a specific person at that company that might find interesting.

Erik Hanchett:
So if there's a very prolific, I don't want to call them internet famous, but a lot of companies have pretty internet famous people or developer advocates that are always out there who are talking about their company. If you can get on their radar, if you see them talking about, I'll say AWS, and they're talking about one of their suite of products, and then you create an app, you create a blog post, you create a video specifically on that piece of product and you make it even better than that's aided and then you share it online, you tag them in it, that will definitely get you on your radar, and that might open up their DMs and you can then DM them, ask them, contact them on Twitter. But if you can get the respect of some of these people, the companies, that might get you an in that you can then apply for them.

Alex Booker:
Funnily enough, that's part of how I got my first developer job. I was working for a developer tool a company that creates a real-time publish and subscribe API, which is suitable for building chat applications. So I built a group and one-on-one chat application using their API and they followed me and we got to talking and stuff that. So I guess I have my own hypothesis about why it's so effective, but what do you think? Why do you think this works so well? How does it make the people in the company feel?

Erik Hanchett:
It kind of helps everybody, I think. So if you create a huge blog article. I'm talking about blogs because I think people get a little intimidated by doing YouTube right away, especially if you're a junior dev. You'd be like, "Oh my God, now I have to learn a product and get in front of a camera and be able to talk coherently? That's really scary." But maybe you can do a really in-depth blog. And by the way, there's lots of tools out there. If you're not a great writer, you can use different tools to help you write. But maybe you can create a great blog tutorial on something from that company, and then it helps... If you share that out there, it's going to help other people that use their product, get to know that better. It shows that you have initiative to the people that you're trying to get in touch with or trying to get on their radar. It tells them at the minimum that you know how to write and that you can explain technical topics and that you understand their product.

Erik Hanchett:
And you probably could understand it better than someone to just randomly put their CV in and cover letter a day before. Cause you've actually used their product and you're willing to go that extra mile. It's not going to always work, too, and you shouldn't always expect something in return. So you should always be like, "Hey, I'm going to put this out in the world, and I'm going to try to target this company or this people, and maybe they'll like it, maybe they won't." The worst thing you want to do is expect something in return. But if you go [inaudible 00:15:32] with a better attitude than it could work.

Alex Booker:
If you're enjoying this episode of the Scrimba Podcast, please do us at Scrimba a favor and recommend this episode with your friends. Word of mouth is the single best way to support a podcast that you like, so thanks in advance. Next Tuesday on the Scrimba Podcast, Cassidy Williams, AKA Cassidoo joins me to talk about her tips on creating a convincing resume and compelling cover letter, as well as advice about where to find jobs and what attitude to bring to the job search.

Cassidy Williams:
Learning different things and building different projects and growing, you could use the hashtag a hundred days of code on Twitter. As you put out all of this stuff, you might be able to write blog posts on dev.to. Heck, you might be able to make a screencast on Scrimba. As you do all of these things, more and more people start to notice the skills that you have. And when you are applying for a job, you have a track record. So when someone starts to Google you, or as they're looking at your resume, you can say, "Look at this series of tweets, look at this series of blog posts, look at these projects that I've built, look at these screencasts that I've made." That sort of thing. And because you have a paper trail of all the things that you've done, it shows that you haven't just been farting around, took an online course, and now you're trying to get a job. You've been learning over time and people know about it and there's evidence of it all over the internet.

Alex Booker:
That's next Tuesday on the weekly Scrimba Podcast, so make sure you subscribe to see it in your feed and support the show. If you are genuinely enthusiastic about the projects and the content, that probably means you're going to be genuinely enthusiastic about the company. So even if they don't happen to open the door, at least you've managed to explore something interesting. And yeah, it could be practice for the next time you do it. But most people want to work with other people that care, at least on the product side, and want to make it better and want to collaborate to improve the product. And if you've gone to that effort, then it means you probably care, it means you'll probably be a good person to work with. Worth a shot, right? Worth an interview.

Erik Hanchett:
Yeah, absolutely. And you may find working on that product is awful or you don't like it. And maybe that could be either... If you don't like working on it, then it'll be like, "Okay, maybe I don't want to do it," but maybe that'll give you initiative to be like, "I want to make this product better. So if I could work on this team... I already have ideas that I know we can make this better by doing X, Y, and Z," and you can really impress them. Because really when you go for an interview, it is a two-way street. Essentially they're interviewing you, but you're sort of interviewing them too. But I still always think that they have the advantage at the end of the day, unfortunately. Even though you're technically interviewing them, they still have more of a say and they're the ones that are going to be paying you.

Erik Hanchett:
So you want to impress your employer. You want to impress the people that you're trying to work for. You don't want to come in with an attitude that you're too good or that they need to cater to you and all your whims. Unless you're some amazing rock star developer that you have 20 companies that have offers in for you, and you would laugh, but there are definitely developers out there that every company will go for. But for the most part, you're going to be one of many and you need to really impress them. And I think it's just a good practice to work for a company that you respect, that they respect you and that you're genuinely interested in than maybe you're just application 1,432 that you sent out this last month.

Alex Booker:
I think this is great advice, and I think it could apply to any developer from junior to senior to staff and so on. I wonder if as a junior developer, by showing how teachable you are and how enthusiastic you are, maybe that's another way you can stand out compared to other junior devs.

Erik Hanchett:
Yeah, I think you can sum those two up, enthusiasm, teachability, and the potential the person has. So being able to understand concepts and be able to soak it in quickly and understand. I think all employers know when they hire a junior developer that there's going to be a ramp up time, even mid-level or senior level, there's going to be a ramp up time. Usually it's shorter. So you really want to hire someone... And I've done some hiring at the companies I've worked for. You really want to hire someone that can understand the concepts quickly, can learn on their own, that don't need hand-holding. We expect junior developers to ask questions. I think that's a really good sign. But you also don't want a junior developer to take the time of the senior developer's time all day, every day. So you have to take initiative, you have to be able to learn on your own, unfortunately, but you do have the backup of the senior developers.

Erik Hanchett:
So to see someone that has that potential, that can learn is great. Having completed courses from Scrimba or freeCodeCamp or some of these other places is great to see, because then you know they've learned these things themselves. They've taught themselves these things. We talked a little bit about my podcast I do with Dylan Israel. You can look at all the breadth of work he's done when he got his first junior developer job, and if I was hiring a person, I would see like, "Wow, he's learned all these concepts by himself. He's created these... Not just learned it, but he's actually created products. He's taught other people." I always think one of the best ways of learning something is to teach other people. So if you can learn a concept well enough to teach it, that's a good sign to me that you're one of these people that has a lot of potential and that has enthusiasm.

Erik Hanchett:
Enthusiasm is hard to gauge. People can fake enthusiasm during interviews. Sometimes people just have bad days, so they may not be as enthusiastic as other people. I've actually lost a job once because I was told I didn't have enough enthusiasm during the interview. That specifically was one of the feedbacks I got. So maybe just try to get a good night's sleep the night before, try to clear out your head, whatever you need to do so when you come into the interview, you're focused and that you can be enthusiastic. You might have to play it up a little bit, especially when you're... Maybe you're applying for an insurance company and it's really boring tech. But yeah, that's probably not a bad idea.

Alex Booker:
I'm so intrigued that you mentioned teaching is a great way to learn, because this is something that I've believed since I was first learning to code. More or less every guest I have on the podcast in one form or another says something to that effect. If you can't explain it simply and clearly you probably don't understand it that well. As you solidify it, you will not only improve your understanding, but now you're creating a blog where people can discover you. You can use this to get in the door. But then the other thing I can do in my position at Scrimba is I see hundreds of developers learning, and remarkably few focus on these things.

Alex Booker:
I'm now starting to think it's worth looking into why. You have a YouTube channel where you enable self-taught developers. I think there's almost a sub-community there, like the comments are always active and there are people looking forward to your new videos, sharing the challenges and things like that. Is that just an experience unique to me and the Scrimba community or is it a broader thing among junior developers? What do you think the barrier is there and why do people struggle to cross that barrier?

Erik Hanchett:
Maybe it's just scary. It's just scary to put yourself out there. It's scary to have other people critique what you're doing. It also doesn't have always a direct feedback of what you're doing. A lot of times when you start blogging or start putting yourself out there, you're just talking into the void for a little while until you get some momentum or you get enough tweets or retweets or the YouTube algorithm picks you up, for example. So it doesn't have a great feedback loop right away. So that's why I'm thinking sharing it with people that you're really interested in and trying to get feedback from them and then realizing you're doing a lot of this for yourself at first, so you can learn yourself by teaching others. That might be a good thought process at the beginning.

Erik Hanchett:
Just realize that you're at one level and believe it or not. There's some people below you in terms of knowledge of whatever particular topic that you're working on. So even if you are a junior developer and you've only been studying for a couple of months, there's probably tons of things that you've noticed that you could teach to others. So take the time to put that together in a blog post and put it out there, and then you can also just use it as a reference for yourself later on. I've done plenty of times. I've looked back at my older YouTube videos or blog posts and used that as like, "Oh, that's how I did that." Now I can grab it and use it in this project. Maybe it's more psychological.

Alex Booker:
What do you think separates successful self-taught developers from self-taught developers that struggle typically?

Erik Hanchett:
That's a good question. I'm guessing it's a lot of persistence. It's a lot of just going out there every day. I like this concept of trying to get a little better every day. It doesn't always happen, but if you can become a little bit better more than the previous day, it's better. Maybe this isn't the best example, but I moved recently to an area that has a bunch of foothills behind me and there's a bunch of hiking paths. And the first day I went, "I'm like, I'm going to do this." I downloaded an app and I made it like half a mile and I was exhausted and winded and like, "Okay, I can't do this," and I came back. And then the next day I made a little bit further. And the next day I made it a little further. And now, being here a few weeks, I made almost four miles on one of my walks the other day. And I would never have done that if I tried to do that in the first day, it would have been impossible.

Erik Hanchett:
So I feel sort of like junior developers who think of that when they start. "Okay, I'm learning the basics of HTML, CSS, and JavaScript. This is overwhelming. Now people are telling me about DevOps and I got to learn this thing called React. And now I have to worry about accessibility. And what about Webpack and how do I host my site and I have to learn about the internet." It's super overwhelming, but maybe if you just take it in successful little things at a time, maybe one day you've learned the basics of semantic HTML, and then the next day you move on to little bit more of JavaScript and then CSS, and then you try to do your first React project. So this incremental and getting better every day, and then just continue on realize that you're going to have setbacks and it's going to take a while, and you're going to get those rejections. There's just no way, no doubt about it.

Alex Booker:
Just life.

Erik Hanchett:
Yeah, that's life.

Alex Booker:
I'm thinking of the book Atomic Habits. I think what the author introduces is this idea of getting 1% better every day, and as a result, the effect compounds, so the end result is insane... I'm just wondering if that applies to developers. I'm not sure if it does.

Erik Hanchett:
I've read that book from James Clear too, and it's pretty awesome. It's a pretty awesome concept. I think it's now required reading for every podcast and entrepreneur and I think it's good for even people outside those circles, because it just talks about creating good habits and how to keep going with it. And a lot of useful examples of how to do that. But I think it somewhat applies to developers, especially when you're learning something. You can take that approach of just getting 1% better every day by learning. It's objectively hard to measure your progress. There's not a test that you can take at the end of every day to realize if you're getting a little bit better. But I think as long as you keep putting the effort in every day and changing and trying to go back to those topics.

Erik Hanchett:
Because all these topics, too, build upon themselves. When you're starting to learn for junior developer, I mean, even as a senior developer, you're still going to be using those basics to build your apps. You're still going to have to figure out how to create HTML elements on your page and how to create a form and how to create inputs. Those things come up over and over and over again. And you're going to have to learn the basics of JavaScript and put everything together. I think it somewhat applies in some things. Maybe not a perfect one-to-one as much as learning the guitar or something like that.

Alex Booker:
I'm sure you've been asked this question more than a hundred times, which is along the lines of which should I learn, React or Vue.js, and whilst they are different, there's a lot of underlying concepts in terms of how you might manage data or how you separate logic from the view and things that. So maybe this isn't my segue into something I've been wanting to ask you, which is not about the specifics of react versus Vue. I feel that could be a podcast episode in and of itself, but it's about the question because I'm sure people ask it a lot.

Alex Booker:
It is kind of a cause of anxiety. It's like, "Oh, am I learning the right thing?" And I'm sure there's a whole bunch of schools of thought regarding it. Like for example, if there are 100 jobs and 50 required Vue and 50 require React, you may be tempted as a junior to learn a little bit of both because now you can apply to twice as many jobs, but then someone else could reason, "Well actually just learn one, get to know that one in depth, and that will be the best chance you have of finding success." Very, very broad question, but I'd love to know your thoughts. What comes to mind when people ask this question?

Erik Hanchett:
Vue and React are probably the, if not the two most popular frameworks slash libraries out there, and people always to say, "Well, React's not a framework." Well yeah, I know, but it's a library, and once you add everything in, I consider it as a framework. But you're still right. There is a big choice a lot of new developers have to make at some point. I come from a background where I learned Vue.js as one of the first frameworks I learned. Well, technically I learned a few others before that, but is one of the big ones that I learned at the beginning. And I really like the community, I really thought it was easier for me, and I've heard this from other junior developers, that Vue is a very easy framework to pick up. It doesn't have the complexities of HTML and JavaScript mixed together like you have in JSX, and you don't typically need to know as much JavaScript.

Erik Hanchett:
For example, we have directives in view. So you have something like a V4. You don't have to learn a JavaScript map to map over things. So there's definitely some advantages there and it has a pretty quick ramp up time to learn. I think a lot of junior devs can learn it pretty quickly. So overall I think it's an excellent framework to learn. They do call Vue.js the progressive framework because they've come from the point of view that you can incrementally add it into your existing applications, starting off with the CDN tag and then move up to using something called the CLI, the command line interface tools, to build your whole project up.

Erik Hanchett:
And you can do something similar in React. You can use the command line. You can use link tag or script tags to add in your React code. Although with JSX, it's a little bit more complicated and it's not really as recommended. But I still think that Vue has a little bit advantage in that way of being in more incrementally adopted and has a pretty good ramp up time. Now, purely off of numbers, it's clear that React has more NPM downloads, it has a pretty huge community, and there's more jobs out there. So that's clear from everything I've seen out there, from all the different surveys, more companies use React. But I don't think it's a bad idea to learn Vue at all, because I think there's plenty of jobs for Vue out there too. But you may want to consider, if you're a junior developer, to see what jobs are in the immediate area that you're in. I would say it would be a good idea to do some research of the local area that you're in to figure out what framework, library, what technology you should learn and work on that.

Erik Hanchett:
And I think if you pick Vue in general, you're going to be fine. I'd still say, if you find out there's a lot of React jobs, that's no problem with picking React. And there's also really, I think this happens quite often, is as your career progressed, you're going to be finding out that one company you're going to be working in React, but the next company you might be working in View or Angular, and it's always good to have more than one stack, more than one framework under your belt so you can more easily move from one job to the other and that you can talk intelligently about it. And you can start seeing patterns between these different frameworks too, which is awesome. You can see how you can do components and Vue versus React and so forth. React is great framework, but I don't think you should discount Vue and learning it and trying to understand it as well.

Alex Booker:
Say someone's learning React and they're listening to this podcast, are you advocating that they should stick with React or try Vue or do both?

Erik Hanchett:
Continue on, definitely. I would not say divert off your React path. So yeah, if that's the curriculum you're going through, many bootcamps teach React as the first and only framework that they teach. Scrimba teaches that, but I know you guys have content in other frameworks too. So no, I think that's perfectly fine. I'm just saying that there is opportunities out there outside the React ecosystem. It feels like React... These frameworks, it's almost like a religious war. I don't want to get into religion, but there's definitely strong feelings on all these sides about these frameworks. When I was growing up, used to be between Linux and Windows. Like, "Oh my God, Linux is trying to take over Windows," and there was camps on both sides.

Erik Hanchett:
Now it feels like as I've grown up, I've seen these parallels between these different frameworks and people religiously going through one or the other, or maybe dogmatic is a better word. I think it's definitely perfectly fine to go and learn React and get out there. There's a lot of jobs out there for React. That's good. In my company we use tons of React, but we also have Vue and Angular, but you also have Flutter and we have iOS and we also have React Native. So we have all of them, and I'm trying to learn a little bit of everything right now. In my last job we did Angular, so Angular is also really popular, especially the enterprise companies out there, a lot of companies that have Java, they moved to Angular as their front end.

Alex Booker:
Erik, thank you so much for coming on the podcast.

Erik Hanchett:
Thank you.

Alex Booker:
That was Erik Hanchett, front end engineer at AWS and content creator. You can find all Erik's links in the show notes. Coming up next time on the Scrimba podcast, Cassidy Williams joins me to talk about her advice for junior programmers and frankly programmers in general in 2021, based on her wealth of experience. Make sure you subscribe to the show to see that episode in your feed and support the podcast. This episode was edited by [inaudible 00:33:49], and I'm your host, Alex Booker. You can follow me on Twitter @BookerCodes, where I share highlights from the podcast and other news by Scrimba. See you next week.