Breaking into Code: How to Launch Your Software Engineering Career with No Experience with Matthew Young, AWS Software Engineer (DF#109)

Ryan Maruyama [00:00:38]:

Aloha, folks, and welcome back to Degree Free, where we teach you how to get hired without a college degree. I'm your host, Ryan Maruyama. Before we get into today's episode, a couple of things. If you would like to join a free community of degree free people that are all trying to change their life by changing their work, getting jobs, getting that promotion, whatever your career goal is, go to Degreefree Co network to sign up for our free degreefree community. And also, if you would like to receive a free weekly newsletter with different degree free tips and how to get a job without a college degree, go to forward slash newsletter and sign up for our free weekly newsletter. I am super excited to have on our guest today, Matthew Young. Matthew is a software engineer at Amazon Web Services. In this conversation, we talk about how Matthew went from being a finance major in college to being a backend developer at AWS. Now Matthew even goes into and breaks down how much he made at every step of the way while he was building up his career, going from upwork all the way to where he is right now at AWS. I really love that transparency. It really gives you an idea of what you could be making if you were to follow similar career paths. We also talk about different AWS certs and different AWS services that are out there. If you would like to follow Matthew, you can follow him on TikTok at Matthew M. Young. I will put links to everything that we talked about, including his LinkedIn and other places that you can find him at our show Notes at Forward slash Podcast. And without any further ado, please enjoy this conversation with Matthew Young. Aloha, folks, and welcome back to Degree Free. I am super excited to have on Matthew Young. Matthew, thank you for taking the time.

Matthew [00:02:33]:

Thank you. Yeah, I'm very happy to be a guest on the Degree Free podcast.

Ryan Maruyama [00:02:37]:

One of the things about Degree free, right, it says it in the name, degree free people that don't have degrees. That being said, I have a college degree, and I didn't really employ know I have a degree in economics and I never worked anywhere around economics or anything like that. I don't even know what working in economics looks like. Well, I had the chief economist of ZipRecruiter on Julia Pollock, and obviously she works in economics. But then there are only so many jobs in that industry. Anyway, I know that from your past you have a degree in finance. I would love to start with a little bit of your background and how a finance major got into becoming an engineer at Amazon. How does that work?

Matthew [00:03:22]:

Absolutely. So I did graduate from the University of Tennessee with a degree in finance. I now work as a software engineer at Amazon Web Services, which is, as far as I know, the world's largest cloud computing provider by revenue. The way that I started, I originally went into school as a nuclear engineering major. I had to take a programming class in a language called MATLAB, which is very, very outdated. I didn't really think anything of it at the time. I got an internship that summer working at a nuclear power plant, and I hated it was the worst thing I've ever done in the world. It was just God awfully boring, and they didn't have enough things for me to do. And in my free time, I looked up how to code. I found a website called Code Academy. I took the intro to Python three course. I went back to school. I changed my major. I became a finance major because I have an uncle who works in the finance industry. I figured he would probably hook me up with a job if I majored in finance. And I kind of kept rolling with the computer science thing, with the programming thing. I took an entrepreneurship class. There was a local entrepreneur who owned a web development company in Knoxville where I was studying. He came into the class. He told us about his business. He told us that he was offering internships, and I went after him. After that class, I said, hey, I'm interested in your internship. How do I apply? So I did that. I'm fortunate enough that I was able to work at that internship unpaid for four months. And then after that, it was $10 an hour. I did that throughout most of college. Toward the end of college, I freelanced with a professor. I started doing jobs off of Upwork, which is a freelancing website. I also had people from previous work at that local web development company reach out to me and offer me work as well. So I had bumped up from like $10 an hour to $25 an hour. I moved across the country. After school, I went to Philadelphia, and then I started getting contract work, which was really only because my freelancing was not going well, and that's because I'm not a salesperson. To be a freelancer, you have to be a salesperson and a developer. I was only a developer, so I started getting contract work and then full time jobs and then just better and better opportunities until I ended up at Amazon.

Ryan Maruyama [00:05:33]:

Excellent, excellent. There are a couple of threads that I'd like to pull at there, but I'll start at the most recent. When you were talking about contract work and freelance work, we have talked about on the podcast before getting contract work and having that be a good start for your career change or possibly even getting into a career. Maybe you're right out of high school or you're right out of college and you're thinking about getting into a role. Contract work being a good in. Can you explain the difference between contract and freelance? Because now that you've talked about it, I don't think on this podcast we've defined our terms well.

Matthew [00:06:13]:

So when you're freelancing, it's kind of like you're your own business. You could be reaching out to people and saying like, hey, I saw your construction company. The website looks like it could be updated. Maybe you could be attracting more people to it. Maybe I could be running ads for you and I could be getting more business for you. It might be, hey, I'm pitching this custom software solution. This is something I made. Does your business potentially want to use it? And then we'll work with you and you might lease my software from me. It's basically you running your own business when you're freelancing. And that could be anything. Like I was saying, like web development, software, leasing ads, all that kind of jazz. When you are contracting, it's typically a company saying, hey, we have a role for an individual to come in and do work for us on a contract basis. And a contract versus a W. Two is you're not getting benefits if you get let go. You're not getting unemployment, you're not getting a severance package. In all likelihood, it's just you're fired. Get out the door by perfect.

Ryan Maruyama [00:07:20]:

One of the things that I liked about your story, or I'm curious about your story is starting on Upwork. When you were starting on Upwork, what was the thought process behind it? Do you think that was a good idea? Is it a good idea still for people to do that now?

Matthew [00:07:38]:

So I think it was a good idea for me at that time because I was getting work on there. I was getting anywhere from $400.01 off packages to people paying me $2,000 to people paying me $35 an hour. I was getting all kinds of different opportunities. So the way that Upwork works, really, any of these freelancing platforms is going to be employer posts a job and then all these freelancers submit a bid for this job. And then the employer picks however many people they want to work on this project. And then the work goes on based on what that employer wants from you. I made enough to sustain myself. I got a little bit of good experience. I learned the things that I didn't want out of work along the way. Like the people who pay the least expect the most, and if you do not put boundaries up, people will take advantage of you. So I'd said like $400.01 off packages. I think of one specific client who wanted to pay $400. I gave him a discount down from $500 for a website. He wanted hosting. He wanted the whole website designed. He wanted it to be informational. He wanted an ecommerce platform. He wanted a portfolio. He wanted contact form, yada, yada, yada. It was just like he had like ten different things he wanted. Nothing was ever good enough. He wanted revision after revision after revision. And I only took on the project because I had a friend who I was subcontracting at the time, and I was just trying to get him some experience. I was like, I'll give you the full $400, just handle it. And client was just a nightmare. $400 wasn't worth it for anybody.

Ryan Maruyama [00:09:13]:

I love that story because anybody that goes off on their own in the freelance or starting their own business, they realize that quickly. It's literally any business. The people that pay the least expect the most, and it goes from services, business agencies, products, you name it, it is true. It's also really awesome that you were able to figure that out early and be able to figure out where to draw the line. My question is, when you're starting out, is it beneficial to have those boundaries in place? Because when I think about learning a new skill and when I think about upskilling, everybody tells me, or everybody says, and me included, you should always say yes. Just say yes because you're trying to learn the skill. You're trying to learn the skill. At what point do you put up those boundaries and just say, hey, $400 just isn't enough for these ten requirements that you need?

Matthew [00:10:16]:

I would say that you want to put those boundaries up as soon as possible. If you've never done the work before, this is like your absolute bare minimum first experience. Sure, take it. And if you mess up, who cares? It was a $400 contract. Nobody's losing sleep about it. So take it on if it's your absolute first thing. But as soon as you have even the smallest amount of experience, you have a portfolio. And then you can say, hey, I did this project over here. I have proof that I can do it. I don't think that you should ever let yourself be exploited just because you want the experience. There are so many better ways of going about it. If I were starting over, I would rather go out and meet people who are more experienced, because I'm not getting paid that much anyway on a $400 contract. I would rather go and meet people and spend my time talking and networking and learning that way than working on a project that doesn't go anywhere.

Ryan Maruyama [00:11:13]:

Yeah, definitely. To move the story along with where you are now at AWS, I was looking at your LinkedIn, and you've really worked your way up, because when I say, work your way up, everybody and their mother, whenever they're talking about getting into tech, they're looking at getting into a fang company. Right?

Matthew [00:11:30]:

Like the big tech companies? Yeah. Yes.

Ryan Maruyama [00:11:32]:

That's the Holy Grail. Everybody just like, I want to do that. Looking at your resume, you've really kind of started at Humble Beginnings, and it looked like you were just constantly upskilling and constantly moving up. How was that? How long did it take and what were the keys there?

Matthew [00:11:53]:

The funny thing is that if you look at my LinkedIn page, you're not going to get the full story. You're getting, like, half the story. I've only included, like, half of my positions. Two of them that I've had were only one month long. I've gone through school, I did my freelancing stuff, and I'm getting my first contract position one, I only started that because I was so bad at freelancing that I could barely afford rent anymore. So I'm like, okay, let me try contracting instead. The only reason I got my first one is because it was such a bad opportunity, nobody else wanted it. It was a three month long contract, which in the contracting world means you're applying for new jobs as soon as you start working on this one. So I accept the position. They offer me a rate of 42 and a half dollars an hour, which is twice as much money as I've ever seen in my life. So I'm ecstatic about it. And I never even started the project they hired me for after one month, they never locked down the contract with their client that I was supposed to be working on the project for. So I asked my boss, I said, Can I just work from home until we actually get the contract underway? And my boss says, yeah, you don't have to come into the office anymore. And I'm like, that was a really weird way of phrasing that. So I go home, I message my boss, I'm like, I still have a job, right? Like when you said I don't have to come into the office anymore, I did not have a job. That was the end of that job. So I went back to my recruiter and I said, I don't know what's going on. I think I need a new opportunity. And I got another job at another company. I worked there for one month, and then at the end of that month, I was told, hey, we really liked you. All the ideas you're bringing in, the work you're doing, we want to invest in you long term. We want you to be a part of this team. Later that day, they fired me. And that was also on my 23rd birthday, which was kind of terrible. Neither of those positions are on my LinkedIn. But after that, I'm interviewing for another job. I'm getting to the last stages of these interviews, and then a local entrepreneur is like, hey, do you want to work with me on this real estate startup that I'm doing? I say yes to that. COVID hits. All the real estate deals are gone. So now it's like March, April 2021. I'm just like, dude, I've gotten a little bit of money from these, like, three positions that I've taken on in the last four months, but I'm just going to wait it out a little bit. So August comes around, then I get a job offer at Kohl's, which is like, a big retailer in America, and I just kind of kept going from there.

Ryan Maruyama [00:14:20]:

So when you get this job at Coles, according to your LinkedIn, I think you were a backend dev.

Matthew [00:14:27]:

Yes, that is correct. And the only reason I got the job at Coles is because I annoyed the hell out of the recruiter. The recruiter said, yeah, we don't have anything open. I said, yeah, for sure. Let me know when you do. And I message this recruiter at least once a week.

Ryan Maruyama [00:14:39]:

The one thing that I want to emphasize here for a lot of people that are listening is the roundabout way that you ended up getting into tech and you went and you got experience in very nontraditional tech companies. A lot of people that are listening to this. The problem is you don't know what you don't know, right? I always say this in this podcast. If you don't have a target, you don't know what to aim for. You have nothing to aim for. And so a good way of getting experience in tech is going to non tech companies because Kohl's, at least from the consumer standpoint, you don't think of it as a tech company. Like, what do they really have? And you're like, well, they have a website, okay, there's some online ordering, probably maybe some logistics in the backside, but I don't know. They can't employ that. Too many engineers, right? But those are some opportunities that you could take advantage of to make your transition. And like you did. Would you say yes to this real estate startup? I mean, it kind of crapped out on you, but it could have been more experience, and it was more experience for you in the bag. And for those listening, that's a really important key, is it's not always going to be you're going to go straight to Amazon, you're going to go straight to Meta, you're going to go straight to all of these tech companies. You can take a non traditional and I'm using that in air quotes route.

Matthew [00:16:04]:

Yeah. The way that you would go straight into big tech is you go to Stanford and you study computer science and you come out and get a job at big Tech. Those are the kind of people who go there straight away. The first two, like the one month positions I had, the first one was a health and life sciences software, and the second one was a financial ratings company. I don't recommend to anybody that they start in a technology company because the bar is so much higher. It's exactly what you're saying. Start at a retailer, started a telecommunications company. The examples I always give are know Target is not a technology company, but they use technology. They use software. They need software engineers. So does Home Depot. Home Depot is as far away as you can get from a technology company, but they have software engineers. Go to at t go to bank of America. All these companies are not tech companies, but they all use tech.

Ryan Maruyama [00:16:54]:

Yeah, absolutely. Where a lot of people know big compensation, big numbers at these other places. And they're like, I need that now. Which fair, right? I mean, everybody would like that. But you have to put in your time and learn the skills. Acquire those skills, learn them, and then you can skill up. I was just saying this the other day. In two to three years, if you do this all the time, you go and get work, you study this, you keep skilling up, you're going to be in a completely different place than you were. You're going to look up and your whole life is going to be changed.

Matthew [00:17:29]:

This is super true. It's not about your first job either. A lot of people like you're saying, want the big bucks, but you have to be patient for it. You're probably not going to get it in your first job. You may not even get it in your second job. Your third job may be the one where you're like, oh, wow, this is actually really good money. I didn't think I could make this much money. Then you get your fourth and your fifth and your 6th job over the course of 1015 years, however long it takes you, or if you're a job hopper, maybe you're getting in six to eight years, whatever it is. But the more experience you have in the industry, the more you get paid. But also the system you're in, how valuable are you to that system? How close are you to the money? So we were talking about these retail, these telecommunications companies. They do use tech, that is true. But you're a little farther away from the money, and because of that, you're going to get paid a little less. Whereas if you work at a company like Google, Amazon, Facebook, all these big tech companies, they directly make money off of your work. You are so close to the money. That's why you get paid big bucks.

Ryan Maruyama [00:18:28]:

I would really love to double click on this because this is a theme that is popping up multiple times. My last guest that I just recorded an episode with, he is an engineer at Twitch, and he was talking about this, but we never really got to get into this. I would love for you to talk a little bit more about what being close to the money means.

Matthew [00:18:52]:

Yeah. So the epitome of being close to the money is sales. Because if you do your job as a salesperson, you make money, you close the deal, you get money. That's as close as you can possibly get. It's literally in your hands. The next step away might be marketing, where you're channeling people directly to the salespeople. In a tech company where the product is something built out of software, if you are building the software and the salesperson is selling your software, you're just one step away from the money. And because of that, you're going to get paid very highly. Whereas if you're in a retail company, the product isn't the technology. The product is going to be. Let's say it's kohl's. Let's say we're selling know I'm a customer, I'm coming in, I'm buying bedsheets. But there's a little sign above the bedsheets that says, hey, this is a buy one, get one free. Maybe I'm the software who works on the technology that allows a business analyst to create the sale that is on the sign for the bedsheets that the customer buys. You see how the separation between the money and the technology is there. You're still going to get paid well, just not as well.

Ryan Maruyama [00:20:00]:

Perfect. Love it. Thank you. And that's really crucial to understand for everybody there. And that's what we've talked about before on this podcast. There's also this term profit centers, cost centers for those listening. When layoffs happen, you want to make yourself more valuable. Traditionally, you would look for places where you would make the company money and you're not just costing the company money. And those are a lot of really important points to take into account when you're making these transitions. You're just jumping off of a like, all I know is bartending. All I know is flipping bottles upside down. I don't know anything about tech. I'm just trusting Matthew here that he knows what the hell he's talking about and he's going to steer me in the right direction. And if you want to be steered in the right direction, going somewhere that you're close to the actual product and close to the money really makes sense. Speaking about money and talking about how much money we're going to make and having goals to shoot for. I would love to talk about different pay ranges at these different places that you've worked, because you've worked at a variety of different places, starting from upwork going through Kohl's, and then at least on your LinkedIn it says Deloitte. And then now at AWS, I'd love to kind of talk about what the pay scale and what the pay ranges look like at those different companies and with that experience that you had.

Matthew [00:21:25]:

Yeah, absolutely. So I would personally lead on a website called Levels FYI, and you can find a lot of information about pay in the tech industry from that website. So I actually just posted a video about this earlier today. Wasn't the best executed video because the screen dimensions weren't exactly right. But in that video I walked through, how much does a Software Engineer at Amazon make? You go on the Levels FYI, you look up Amazon as a company, you click Software Engineer, you click Entry Level Software Engineer and you see that they're getting paid anywhere from seventy three thousand dollars to three hundred and seventy three thousand dollars, mostly depending on location. Also depending on what kind of software Engineer they are, an API developer in Memphis, Tennessee is not getting paid as well as a Distributed Systems Engineer in Seattle. It's going to be very dependent. Also if you have zero years of experience, or if you have four years of experience going into this role. If you want to talk about not big tech companies, before that I was at Deloitte, and I had worked there for just about two years. I was making 100 and 2125 thousand dollars after bonuses, something like that. In my first year, I made 110,000. Before that I was working at Kohl's where I was making $50 an hour, which is roughly $100,000. But that was on contract, so no benefits or anything. And then before that, my two one month jobs where I was making 90,000 and then 42, 50 an hour. So it just kind of like went up incrementally from the equivalent of $85,000 a year to $120,000 a year until I got to Amazon, and then it was 205,000. So that's really where the big jump was for me.

Ryan Maruyama [00:23:14]:

That's awesome. And thank you for being so transparent. It really helps people that are listening to this. Like I said, just have a bearing, have an idea of what this looks like because you don't know what you don't know. And I remember when I was still a bartender and I was trying to get out $200,000. I don't know anybody that makes that amount of money. I don't even know what I could possibly do where somebody would pay me, never mind what skills I have to learn to do that, but what jobs pay that amount of money? And I couldn't tell you. And so the pay transparency really helps everybody listening to this.

Matthew [00:23:54]:

Yeah, of course. I'm a big supporter of pay transparency. I grew up in a household where it's like, hey, I'll tell you how much I make because you're my kid, but do not tell anybody how much I make. And I don't really understand that mentality because if you tell somebody and they have a negative reaction to how much you make, they're like, oh, you make more than me. I don't like that. That's weird. And personally, I wouldn't want to be friends with somebody who doesn't support their friends doing well. But also, we're all part of the working class. I don't know if people agree with this or not, but I think if you're making $10 an hour, or you're making $200,000 a year, I am much closer to you than I am to Jeff Bezos or the current CEO, Andy Jassey, because those guys are making $20 million a year. I can't possibly understand what their life is like. But I do understand, because I've been there, what it's like to barely be able to afford rent and to buy the cheapest food that you can at Walmart, because that's what you can afford for groceries. And I don't think that infighting at the lower levels is the best thing. I think the more information we can spread amongst each other, the more that we can help each other again as the working class.

Ryan Maruyama [00:25:10]:

Absolutely. I couldn't agree more. One of the biggest reasons why I was excited to have you on is because you are an AWS engineer. We talked a little bit about this offline whenever anybody is getting into tech, people are just like, get into tech. And then you're like, okay, well, what does that mean? And then your eyes just glaze over once they start giving you different options. Right? You could be somebody that's technical. You could be somebody that's not technical, and then you could be anything in between. There's product managers, there's project managers, there's It, and within it, there's all these things. Within a software engineer, there's plenty of, like you were saying, there's API, and there's distributed systems. There's backend, front end, all these different things. One of the things that you hear all the time is getting AWS certified for entry level tech roles. As somebody who works for AWS, and I'm not sure if you work on the code that builds these products, can we talk a little bit about AWS certs? And can we give a little bit of guidance of, like, are they useful? Is it something that people should learn?

Matthew [00:26:27]:

So I'm personally not the best person to answer that question, because I work on the code for the AWS Athena service. I am not an end user of AWS services. Well, at least not for my own AWS service. The way that AWS works on the inside is we actually do use each other's services a lot. So if I need to store data, I would use, like, DynamoDB, or if I needed to store something, I would use Amazon S three for the most part. I have never worked for a company that uses AWS services, although there are a lot of them out there. What I would imagine is that credentials are like school, right? You don't go to school to come out and be an expert in the field. That doesn't happen with anybody. You talked about EMTs and paramedics in a. Previous episode, and I actually was an EMT for a brief period. Nobody comes out of EMT school a good EMT. What you do when you go through this certification process is you come out with the bare essentials that say, when I begin learning, I will begin learning efficiently, whereas more efficiently than if I didn't have the base knowledge about what I'm even working with here. If you don't have experience, then having those credentials of, I know how to learn this, if you give me the opportunity, I can do well. That, I think, is a good sign, especially if you build upon that proof of learning, especially with certifications. The time period of how long I would view that as valuable is going to be a little shorter, maybe like six months after you got it or something. And then if you haven't utilized that information, you've probably forgotten it. If you have built personal projects using the information that you are certified for, that goes even further. Now it's like, you know how to learn it. You've demonstrated you know how to implement it. Of course I'm going to hire you.

Ryan Maruyama [00:28:17]:

Absolutely. With creating projects. You're not an end user of the product. We've established that. But maybe you did have an idea as far as projects in that ecosystem. Where would somebody even start with that? Because it seems like it would be difficult to think about the AWS ecosystem if you don't know anything about it.

Matthew [00:28:46]:

I would probably go online, and I would steal an idea from somebody else. What I have seen that is really good because there's no need to reinvent the wheel. If you come up with an idea that's valuable to you that you can use in your own life, that's going to be the best thing you can do. But you don't need to rack your brain spending like a week or days on end or however long just thinking of the idea. Go online. Look up ten cloud computing, personal project ideas. Somebody asked me this question on Live Stream yesterday. They said, how do I come up with a personal project or idea or what should I do as a personal project? So what I did is I said, Dude, I'm going to go online right now. I'm going to look up GitHub repo project ideas. I clicked on the link. It brought me to a search page on GitHub, and I clicked on a repo that said a thousand project ideas or whatever it was. I just skimmed through them. I picked a couple of them. A couple of them looked good. A couple of them looked a little too advanced. But you just do some research into what even are these projects, and now you're learning about how is this technology implemented, and you're gauging, what can I do? Right? You're like, can I do that? Well, you look into a little further. Okay, I know how to do the first part. The second part. I don't know how to do the third part. But then maybe that's an opportunity for you to grow and you determine, can I learn how to do that? And if you do, then you have a great story to tell to your employer. Like, hey, so this is my certification. Here's a project that I made. I knew how to do the first two parts from the certification. The third part was where it got really tricky for me. So this is how I sourced my information and how I experimented with it, the troubles that I overcame when I was doing it. And now this is what it is. And I know that's very general and broad, but it all comes down to utilizing the resources available to you.

Ryan Maruyama [00:30:32]:

No, that is very useful. When people are in the dark and they have no idea where to start, that is very helpful. So thank you very much.

Matthew [00:30:45]:

Yeah, I would also say go on chat GPT. Chat GPT is great and free.

Ryan Maruyama [00:30:49]:

I am glad that you talked about chat GPT because that is where I was going to head next, at least with large language models or AI. And just talking about one, do you use it for work? Maybe not chat GBT because of internal things, but rather do you use some sort of AI in your everyday for being a developer? And then a secondary question, kind of unrelated, which is what does it look like in the future for software engineers, software developers with the advent of AI, when you can literally just put in to chat GPT, make me this and then it'll do it, what does it look like?

Matthew [00:31:32]:

So, for work, I do not use chat CPT. And a lot of companies are telling employees like do not use chat CPT or any kind of generative AI for work. And the reason for that is that as soon as you put some kind of proprietary information of the company into this generative AI, it's using that information to then answer questions for other people. I forget which company this was, but somebody's confirmed already that it did happen. You don't want to do that. You don't want other companies being able to steal your information because your employees wanted their jobs to be a little easier. That trade off in value isn't beneficial to the company. What I do use chat CPT for, as far as coding does, is I use it in my personal project that I'm working on right now. I'm a backend developer. I'm not a front end developer. I'm using chat CPT to generate tons of front end code. I've used it for a little bit of backend code. I mean, it's worked great every time I've done it. I'm learning by using it too. I do have the background to be able to say like, that's not what I want it to do. Let me tweak this a little bit. And that's ultimately what chat GPT or all generative AI is going to be. It's not going to everybody's fear mongering about, oh no, this is a terrible time to study computer science or to become a software engineer. That job is going to become obsolete because Chat CPT can do it. It's a tool. That's like saying that when nails were originally made, what I've heard is that they were originally created one by one by hand by a blacksmith, and then they were created by factories. And when you were able to create nails in factories, this enabled carpenters to build houses out of smaller pieces of wood because nails were so much more available and so much less expensive. You could put wood together in different ways. This didn't get rid of carpentry. It increased the efficiency and the amount of possibilities that carpenters could use and build with. And that's exactly what Chat CPT is with software developers. It's a new tool. It's going to allow us to focus less on coding and more on engineering and architecture. It's an evolution. It's the same thing as when spreadsheets came out before the data analyst. You had people who were just inputting numbers all day and doing manual calculations and coming up with patterns on their own. And then spreadsheet came out and the position evolved to what we know as a data analyst today. It's only a good thing. It's not taking away jobs. It's making our jobs easier.

Ryan Maruyama [00:33:55]:

I couldn't agree with you more. I agree with your analogy. I've said it on this podcast before about there's a similar analogy to ATMs. Like when the ATMs first came out, they thought that that was going to take the jobs of tellers. And it turns out that ATMs actually made it cheaper to open more branches. So they opened more branches and then more tellers were employed than ever before because the unit economics were such that it became so cheap. When you think about it, it blows your mind because you wouldn't think, or at least I wouldn't think that that would be the case. And I suppose I would be in the camp if I was around during the era when the nails were handmade versus factory, I'd probably be in the camp of like, oh my God, it's going to take all of our jobs. But then you see the second order effects. You're like, oh, wait, actually I'm getting more work because I can finish my work quicker. Or you know what I mean, maybe that one person's job to make the nails. Maybe his job went away or maybe he had to retool to go to the factory. But overall, the construction industry flourished and more economic value was made. But that one individual maybe had to retool their job.

Matthew [00:35:01]:

Yeah, exactly. You didn't hear the horses complaining about being out of work when the car was invented. It's not like, actually, I don't know, maybe we have a lot less horses now that might be a maybe.

Ryan Maruyama [00:35:12]:

Maybe. I have no idea. I'm going to guess if somebody knows, put it in the YouTube comments. I'm going to guess though that we have less horses mean it has to be because it's not utility.

Matthew [00:35:26]:

But the other thing about that is that the world is always changing. If you're holding on to this idea that we as people or as a society should not progress because some people are going to be left behind, one, it's selfish. Two, it's just not going to happen. We as a species have never ceased to progress simply because a group of people didn't want to move forward. And maybe I'm wrong about that too. I'm not a history buff. Maybe when the Dark Ages happened, it's because people didn't like something and that's how the Library of Alexandria was burned or something. But in modern day society, you're not going to stop the advancement of technology. It's not going to happen.

Ryan Maruyama [00:36:05]:

Yeah, I agree with that. And what you were talking about with you're a backend developer and you're using it and you're prompting chat GBT to create all of this front end code. But you're looking at it through your eyes and through your lens of what you want this code to do and what you need it to accomplish at the end goal and then tweaking it. That is at least right now, this iteration that we have right now for those people listening to it. And you're thinking, okay, well I keep hearing about this AI. Keep hearing about this AI. Well how do I learn about it and where can I bring value in my personal life? Or if your company allows you to use it and use it for work, how can I become proficient at these things? And that's the best way to do it. Even if you're doing something like creating cold emails or like some marketing or you're trying to figure out how to concatenate things in Excel, you're just like, I have a vision of what I want and so I'm going to prompt it to make it do something. And then you're just going to look at it, be like, does that make sense? No, that sales email doesn't fit with our brand. And then you put your brand's voice inside of that.

Matthew [00:37:16]:

You could also, if you wanted to use chat CPT for that, you could say, hey, here are a few examples of emails that my company has sent in the past. And it'll use the wording or the voice of the company, but you can give it more context as well. I use chat CPT to plan my honeymoon. You can say, hey, make this change, or what if I don't want to do this? Or what if I want to add this part to it? It'll go back, it'll make new iterations. It's crazy.

Ryan Maruyama [00:37:42]:

That is exactly right. And people that are listening to the podcast are going to be sick of me saying this by now, but I did a very similar thing with my workout routine. I was struggling with getting a workout routine planned out. And I have a bunch of equipment down in my garage. I have seven pieces of different equipment. And I was sick of going on all these different websites and googling like, how can I figure out how to utilize all this equipment that I have? So I just told Chachi BT, in like a two paragraph prompt, like, here are my goals. Here's the equipment that I have. Here's the time constraint that I want to do. It create a workout plan for seven days a week that takes less than an hour, that utilizes all this equipment. And then it did it. And then I saw the output and I was just like, okay, well, that one sucks, that one sucks, that one sucks. So I asked it again to do it again. Subbing in those exercise and basically doing exactly what you're doing, that is how you are going to really see value for your company. I think for companies, it really makes sense to have it. And there's privacy concerns like you were talking about, about this. But really where I see it being very helpful is ingesting data, like what you were saying, right? And if there was a way to silo that in a perfect world and I'm getting way outside of my pay grade here, but just if there was a way to like, this is my bot and this is my AI. And I can query it to do whatever that seems to me like the most valuable use case, at least with the application that we have now.

Matthew [00:39:14]:

You can absolutely do that. There's open source code to make a generative AI bot. And if you wanted to do that and just have it cut off from the internet or cut off from the main source, you can do that. I personally haven't played around with it too much to know the specifics, but I also see that being the best way for chat GPT to make money is going around to these individual companies and saying, hey, we'll make it so that your proprietary data doesn't get leaked. Here's your version of the app.

Ryan Maruyama [00:39:43]:

Yeah, I completely agree with you. I've actually had conversations with people that are trying to figure out that problem. They're in the very beginning stages of ideating it, but they're highly technical. I don't know.

Matthew [00:39:55]:

They're talking it's okay. It's outside of my pay grade too. Don't worry.

Ryan Maruyama [00:39:59]:

Okay. Can we talk about AWS, Athena? One, can we talk about what it is and then what your job right now actually is further along from that? What does a day look like? What is the day to day of a software engineer that works at AWS on the Athena product? What does that look like?

Matthew [00:40:20]:

Sure. So AWS Athena is an AWS service, and if you don't know what AWS is it's Amazon Web Services. It's basically a conglomeration of cloud computing services. It's much more simple than people think. Cloud computing is just you are using somebody else's server. So it feels like magic because you don't have to manage any hardware. Right? It's just like the Wi Fi or I'm connected to this app. What you're doing is you're connecting to a company's server. And Amazon is the world's largest cloud computing provider by revenue. Very closely behind is Microsoft with Azure, and then kind of farther behind is Google Cloud Computing. But on these cloud computing services, right, on Amazon servers, we have services like Storage. You might think of Google Drive. We have Amazon S three. You might think of storing data like databases. So we have AWS RDS, which is relational database service. We have DynamoDB, which is a NoSQL database. And I work on Athena, which is a SQL query engine for non database storage locations. And what that means is that instead of managing a database where I have millions of records and just tons of data, and I have to manage the database itself, you can run SQL queries, which is how you search through a database on something like an individual file. So it might be a Parquet file, it might be an Apache Iceberg file. There's a whole list of file types you can search through, and it makes it easier for a company to manage their data and then run data analytics on it.

Ryan Maruyama [00:42:02]:

Perfect. With your day to day, as far as your job, do you go into the office? Are you in a big campus or not campus, but like your big server room? What does the day to day look like?

Matthew [00:42:17]:

I don't go into server rooms. That would be for something more like a network engineer where they're actually dealing with the hardware. As a backend software engineer, I really only deal with writing code and then deploying that code, which fortunately, I'm separated from the hardware. I do have to go into the office three days a week because Amazon had the RTO return to Office policy back in May, and then two days a week, Monday and Friday, I get to work from home. You're supposed to work 40 hours a week. I don't think most people work a full it depends on which team you're on. From the people that I know, not everybody works a full 40 hours a week, every single week. Sometimes you're working 30. Sometimes. But the catch to that is that the on call for Amazon is kind of brutal. So for a full week, you have to be available 24/7. If something goes wrong at two in the morning on a Saturday, you have to be ready and available to fix it. And you have to be ready and available within I think it's 25 minutes. It's kind of rough, especially if you're working with a service that has a lot of instability. I've been woken up at three in the morning multiple times throughout the same week. And that's where it gets kind of weird between where is your work time and your non work time, because you basically can't even have a social life during that week. You can't go out because you have to bring your laptop with you and you need to have WiFi. You can't go out and experience nature or go on a drive that's going to be too long because if you get caught where something goes wrong, you need to be available. And if you are not available, you're going to be in a lot of trouble. There is a culture that we call Pipping performance Improvement Plans, which is basically plight speak for pack your bag, start looking for a new job. I personally don't know anybody who's been Pipped, but I've heard a lot of conversations about it and I'm just happy that my team is very pleasant. I love the people on my team. I enjoy the work that I do on my service. The code that I write on a daily basis might have to do with making my service faster or fixing things that are breaking or creating new features that are going to improve security, that kind of thing.

Ryan Maruyama [00:44:31]:

I wanted to go back when we were talking about generative AI and we were talking about using it in the future, it's going to allow more code and then people will not have to code as much and they can focus on engineering and architecture. Can we talk about what the difference is of engineering and architecture versus coding? Because for a lot of people, for myself too, you think about it and a coder is a developer, is a software engineer, is an architect. It's all the same to me.

Matthew [00:45:07]:

Yeah, a software engineer is supposed to be that. It's supposed to be more than just someone who writes code. It wasn't really until this job at Amazon that difference between programming and engineering became very apparent to me because at all my previous jobs, it was really just, here's what we need done, write the code for it. But at Amazon it's, here's what we're trying to figure out. Can you write a design doc for this? And then when you write the design doc, and that might include diagrams and then the flow of data and the different services that are going to be needed and the resources and the accounts and you need to know how everything is connected, you write a diagram for that. And then you also have a design review meeting with your peers where people leave comments. And then you have to defend parts of your design or you have to say, hey, you're right, that's a good point, I need to look further into this. And you just kind of as a group, dive into the technical aspects, the details, and then you come up with an end result. That is what you actually implement, that's what you actually write the code for. So the design process can oftentimes be much, much longer than the actual code writing portion itself.

Ryan Maruyama [00:46:16]:

With the design process, are you guys actually creating software within a sandbox? Or is it literally you guys are still writing requirements on paper or wireframe? I don't know, however you guys do it, or are you guys actually making something? It's like, this is what it's going to be.

Matthew [00:46:34]:

It's the latter where you are writing out the requirements and you're trying to figure out, how do we meet these? So let's say I'm writing a design for AWS IAM, which is the authentication service that Amazon has. IAM has something called Roles, and roles can be assigned to different accounts underneath the user hierarchy. So if I'm looking at, okay, I need something called a role, I need to know how is that role defined, what are the permissions associated with it? Who's going to have the permission to add permissions or assign roles to other users? And then what if I want to have a permission for a specific service or a specific part of a service or a specific thing that was created within this service? I have to think of all these different moving parts and how they're actually going to be implemented in a way that is fast, what the user expects to happen. So intuitive, like fast intuitive, and it needs to work in a way that's useful and functional. I'm probably not hitting all the product management terms, but I think you can kind of get the picture.

Ryan Maruyama [00:47:46]:

So when you're doing all of this design and it's taking longer than the actual coding portion of it, do you find that when it's time to get fingers on keyboards because you've done all this design work, that it is quicker? And then also is there less bugs? Is there less problems with it?

Matthew [00:48:07]:

Ideally, it should be very fast. You should know exactly what you're doing after the design process. However, that's not realistically. Always what happens frequently what will happen is you'll go to implementation and then you'll figure out, oh, this actually doesn't work the way that we thought it did when we were creating the design. So here's a way that actually works, and now we can go back and modify the design to fit what the implementation actually is. And it's this back and forth of design implement, design, implement. It's not just design, implement, done. What you do after you do the implementation is you also write testing for it. And there are different kinds of tests. You have tests that run when you try to merge the code, so certain tests have to pass for you to even get your code into the pipeline. You have tests that run in the pipeline, which is like as it's deploying, does it pass your deployment tests? And then you have tests that run after it's been deployed, making sure that it's still functioning the way that it's expected to every five minutes.

Ryan Maruyama [00:49:05]:

Awesome. That was a little technical. More technical than we normally get into this for the listeners. So I apologize there, but this is endlessly fascinating to me, and I hope that that was useful to people listening. Matthew, I wanted to switch gears just a little bit and talking about you are now a backend engineer, and you said you don't really do frontend stuff anymore, or you don't really enjoy it. Is that what you were saying?

Matthew [00:49:27]:

I would only brand myself as a back end engineer. I have never worked professionally as a front end engineer. I've done in personal projects, but I also don't want to open the door for my employer to be like, oh, you know, both do you want to be a full stack developer? I like my niche. I want to continue down that route.

Ryan Maruyama [00:49:44]:

Can we talk a little bit about how you ended up going that route? Because you started on Upwork, you started with that entrepreneur class, getting that internship. You were making websites, right? I mean, you found an entrepreneur, you're making websites, the forms and things like that. How from general web dev stuff did you end up becoming a back end engineer? And the reason why I'm asking the question is for how do other people also go down this journey? What are the questions that you have to ask yourself to get to where you are?

Matthew [00:50:20]:

I would say that I just kind of fell into it, honestly. It wasn't very much so by design when I took that first Intro to Python course the summer after my freshman year in college. Python is a strictly backend language. You cannot use Python. I think you can use Python for front end. Now, I think somebody may have made that possible, but it's not fast, and people do not use it professionally. But I did that, and then I had the web development job. You are right. And I don't know, I never really got into web development the same way that I enjoyed writing Python code. So I started writing more projects like that, and then I figured out, like, oh, okay, this is more software development, not web development. And I kind of learned the difference there, and I just kind of started pursuing more software development because I'm like, I think this makes more money. And I also enjoyed doing it more. I continued down that route. I figured out, oh, this is called a back end engineer, and I just kind of kept doing it. But when I talk to people now who are going through the dilemma you described earlier of I don't know what all it even means to be in the tech industry, what are all these hundreds of different positions? I ask people if they want to write code, I guess, in the first place, do you want to write code or do you want to do something technically adjacent, like, would you rather be a product manager or are you artsy? Do you want to design things? But if they want to write code, I'll ask them, would you rather solve a complex problem or would you rather have something tangible where you can see the results of your code? Or are you interested in something like analyzing data and finding patterns in large amounts of data from there, if they can give a clear answer, like, oh, definitely. I want to be able to see what I make because that tangible. Like, I can see the change right in front of me is a big thing for me. Well, then you want to be a front end developer. If somebody's like, I really want to solve complex problems, that sounds really cool. You're a back end developer. If it's I really want to identify patterns, that sounds really cool. You want to be a data analyst or a data scientist?

Ryan Maruyama [00:52:22]:

That is an amazing framework to think about, which is, what do you want your day to day to look like or what do you enjoy? One of the common threads that I've seen with software engineers and maybe you could speak to this because you know more software engineers than I do, but is that they enjoy what they do, or at least they enjoy the process of really just wrestling with whatever problem you're doing. It might not even be the code, necessarily, but just whatever the problem is, they really enjoy that battle, I think.

Matthew [00:53:02]:

As software engineers, as professional problem solvers. Because the same way as we were discussing the design process where you think about all your requirements. You break down all the parts and how they all connect to each other. And then you write the code right when you solve a problem. It's the same way. Let's say we were a carpenter again, if I want to build a chair, I'm not going to just cut up some pieces of wood and start, like, jamming them together until I finally get a chair. And it's like, kind of kind of a chair. I'm going to take out a piece of paper. I'm going to draw what I think a chair looks like. I'm going to write out the measurements for what I think it should be, and then I'm going to cut up my wood, and then I'm going to connect to everything. If you enjoy that process of thinking through it and thinking through all the problems and going through iteration after iteration of like, no, that doesn't work. Why doesn't that work, though? Oh, I could do this. If you enjoy that process and you get that high of, I finally did it, I figured it out, and you can go through the pain of struggling with something for days on end or weeks on end sometimes, then software engineering is a good profession for you. And I personally enjoy that.

Ryan Maruyama [00:54:12]:

I really amazing. Amazing. Matthew, I don't want to take up your whole day. I do have a couple of questions left for you though. One, if people wanted to follow along with your career, with everything that you're doing, where are the best places that I can send them?

Matthew [00:54:30]:

It would be my TikTok at Matthew M. Young. I'm trying to be more active on YouTube. You can find a link to it on my TikTok, but I haven't gotten to a point where I'm able to differentiate my TikTok and my YouTube content yet. So TikTok is definitely the best place for definitely, definitely.

Ryan Maruyama [00:54:44]:

And I will have links to everything. For those listening at our Show Notes degreefreefree, Codcast, I'll have links to your TikTok and to your YouTube and then your LinkedIn as well. Last question for you. Is there anything else that you would like to say? Is there any other asks of the audience or final thoughts that you would like to give before we go?

Matthew [00:55:05]:

I would say that the biggest thing you should know if you're considering software engineering or the tech industry in general or really any kind of job transition is talk to people. There's no reason that you should fully commit to something that you don't have enough information about, especially something that could take you a year or longer to transition into. And you can meet people pretty easily. Reach out to them on LinkedIn, reach out to them on social media. There are so many people who are just so happy to talk to you because you're curious and you're genuine about your questions. Obviously. Don't be the person who's like, hey, can you get me a job? Can you give me a referral? It's like, Do I know you? But if you want to know more like, hey, I'm considering transitioning into the tech industry, would you be able to maybe hop on a call with me sometime and give me your thoughts and opinions? So many people are so happy to do that.

Ryan Maruyama [00:56:00]:

I love that you said that because it is also a common thing. I think it's for everybody. The more people that I speak to, I think it's for everybody. Everybody had somebody that helped them at some point. It might not have been in the software realm, it might not have been in tech to get you to where you are. For me, it might not have been anybody in the entrepreneur space or in the content making space or anything like that, but at one point in your life you had somebody that helped you. Surprisingly, most people are pretty willing to help as long as you are, as you said, just genuinely curious. And you don't want to just be extractive of you like, hey, before I even know you, before I even really know your name, can you give me a referral?

Matthew [00:56:46]:

Yeah, can you put your name on the line to refer me?

Ryan Maruyama [00:56:50]:

Yeah, that would be great. It would be great for you to help me get a job.

Matthew [00:56:56]:

Exactly. And nobody would question, like, why did you put this guy in front of me? He doesn't have any experience or any credentials at all, but everybody, I think, is happy to offer guidance. And if I knew half the stuff I knew six years ago, I'd be so much further in my career, but I didn't realize how many things I just didn't know.

Ryan Maruyama [00:57:17]:

That really is the rub. That's it. I think that's for most things and for almost everything, you don't know what you don't know, and you really have to get out there and ask people, find resources online. For me, I knew it became really obvious for me, at like, 25 years old, I had a little bit of a professional career, but I was still bartending because I ended up hating my professional career. I really, really hated it. I was just like, I have no idea what's going on and I don't know what I don't know. So I started listening to podcasts, which is one of the biggest reasons why I started a podcast. Pay it forward, you know what I mean? Like, oh, this is a free resource that I could just listen to and steep myself in and then take the lessons and change my life. Okay, that sounds great, which is the reason why I do this now. But in the same vein, you can find all of these things and steep yourself in anything nowadays. I mean, you can use Chat GPT like we were talking about to help you with all of this and help you make your change.

Matthew [00:58:22]:

They have an app now, I just downloaded it. You can do it right on your phone.

Ryan Maruyama [00:58:25]:

The iPhone app you're talking about?

Matthew [00:58:27]:

Yeah, for yeah, right, right.

Ryan Maruyama [00:58:29]:

I have committed on my phone to only using Chat GPT instead of Google this week just to see if it will do everything that I needed to do. Instead of going to Google and having to go through all the blue links and everything like that and then having to press on one and then read it, I was like, what if I can just do all of this stuff, like this recipe that I'm looking for? What if I could just do all of that in Chat TPT? Let's just see how that works. And I don't know, it's been working so far. Not dead yet.

Matthew [00:59:01]:

Maybe I should try that.

Ryan Maruyama [00:59:03]:

Yeah. But yes. Matthew, thank you so much for your time. Really appreciate it. Hopefully we can do around two sometime.

Matthew [00:59:09]:

Yeah, absolutely. This was a great conversation, Ryan. I appreciate your time as well.

Ryan Maruyama [00:59:13]:

All right, have a good one. Bye.

Matthew [00:59:14]:

You too. Bye.

Ryan Maruyama [00:59:15]:

I hope you guys liked that episode and got a lot out of it. If you want to follow Matthew, follow him on TikTok at matthew M. Young. If you would like links to everything that we're talking about here, go to forward slash podcast to get all of the links. And once again, if you would like to join a free community of degree free people that are trying to change their lives by changing their work, trying to get better pay, try to get that promotion, try to make that career change, go to Degreefree Co Network to sign up there. And if you would like to receive a free weekly newsletter that has different degree free jobs, how to get hired and how to level up in your career, then go to Degreefree Co news letter and sign up. And that's pretty much it for this week, guys. Until next week. Aloha.