The 5 Steps to Getting Your First Job as a Software Developer
Today we're going to talk about the five steps to getting your first job as a software developer.
The five steps I'm going to teach you will give you the clarity you need to get that first job as a developer. You'll know exactly what to study, and exactly what to build to impress a hiring manager.
I'm going to take you step-by-step in this process - no more confusion or spinning your wheels. No more false starts, half finished projects, and no more $10 courses that you buy and never look at.
If you've been trying for weeks or month to learn how to code, but don't know feel any further along, then these five steps are for you.
My team has taught these steps to hundreds of students as Coder Foundry.
I've seen people from all walks of life stick to this process and come out with a new job on the other end.
Usually you'd have to attend Coder Foundry or register for our workshop to learn this, but I thought I'd lay it out to all, for anyone to use and benefit from.
Why? It's because I see so much misinformation about having a coding career out there.
Some of it is from people who are trying to be helpful, but they are junior devs and they don't have a big picture view. And some of it is from the cranky older devs who think you have to learn 50 things and have a PHD before you can even hope to apply for a job.
What I don't see is a lot of employers like me weighing in. I don't care about the programming language wars. I just build software that solves business problems. If that sounds like you then you're at the right place and these five steps will help you.
Before I started teaching the five steps at Coder Foundry, I launched two successful software companies. We were growing fast, but I couldn't find enough developers to fill my positions.
I interviewed everybody. I interviewed computer science grads, but they didn't have the real world skills to handle the work I would give them.
Then I heard of a new way people were learning how to code.
Instead of going to college for four years, people were using something called “Immersive Learning”.
You've seen Immersive Learning before. It's how a soldier learns how to go to war or how a pilot learns how to fly.
I thought, if I put people through a “workplace simulation”, and get them to build real-world projects, I could create the coders that I needed.
I was sure the method would work, but I thought it would be useful only for people already in IT. If you're a comp sci grad and just graduated, or if you're a pro and you need a refresher, or if you did hardware and you just want to switch to software - I thought the program would work for those people.
To my surprise, using a “workplace simulation” works on people who are brand new to software development.
We had one early class with a few people who were completely green. They wanted jobs in software, but they weren't experienced or naturally gifted with it.
After about two weeks, I pulled six of them aside and said,
"We've messed up. We see that you're struggling and that's our fault. But I'll tell you what, if you want your money back, I'll give it to you right now. But if you want to stay, we'll figure out how to get you through this class and teach you how to be a software developer."
To my surprise, only one person took me up on that offer and left. The rest of the five stayed, and we worked with them on how to learn.
I'm proud to say that all five are working today as software developers, and one of them works for one of the largest tech companies on the planet. I'm as surprised as anyone that this style of learning can help so many different types of people.
It's borderline amazing.
It's funny, whenever I hire a new teacher, they go through what I went through.
First they complain and say, "There are newbies in my class, how are they supposed to learn all this stuff?"
And I tell them, just teach and watch what happens. And eventually that teacher gets their own Mr. Miyagi moment and they witness their most inexperienced student kicking the teeth out of some code.
The process that we teach to Coder Foundry students is “the Coding job roadmap” I will teach you.
I've seen it work for them, and I know that it can work for you.
Take out your phone, write some notes, we have a lot to cover.
Let's dive in!
Step #1: Choose the Right Programming Stack.
A stack is a collection of software and tooling for you to build a web application.
Now, what most people do is go online and search:
"What programing language should I learn?"
And so they'll ask a developer, or they'll go on Reddit.
I was watching on YouTube the other day, and saw a video titled, the top 15 languages I should learn in 2019.
And so when you look at all of this advice, you get really confused you get really confused about what you should do.
You don't know which language to pick!
Now, when you're asking a developer what language you should learn, sometimes they'll pick their favorite language. And that's funny because it's the language they like the most, but it's not the one they're paid to do.
Sometimes you can look at these programming lists, and they're picking “the most popular” language. You really don't know what makes a language more or less popular.
For example, you can look at Java as the most sought after language, and you'll see that it’s primarily driven by Android development. It has nothing to do with web dev.
You may pick that language, and then you figure out that to build web dev no one wants you to learn Java. They want you to learn something else.
You could pick other stacks that people are trying to push out and promote, but maybe they're the loudest voice in the wilderness and you pick something that no one’s using.
You look around and you say:
"I just spent six months learning something and now I can't get a job with that because there are no jobs available."
What you should do is pick a stack based on the amount of jobs that are available.
How do you do that?
Simply go to something like Indeed.com or some kind of job search, and type in the different stacks that you're looking at. See how many jobs are available in your area that you could qualify for once you learn it.
I think that's the best way to pick a stack.
Now, to bring to this home, I want to tell you a story about a student we had here at the Coder Foundry.
When she was coming inbound she told us her story. What she wanted to do was break into financial trading. She was working as an analyst but she wanted to move over to the IT side.
She said, "Oh, I must learn how to code to be able to do that."
She went out and searched out for the most popular language that she could find to learn. And she was targeting coding bootcamps, and she decided that I'm going to learn Ruby.
She went to a bootcamp, she learned Ruby, and she's very intelligent, and did very well in the class.
She went back to her employer and they said,
"Well, that's great that you learned Ruby, but here all our stuff is written in .NET."
And so she suddenly realized that what she learned wasn't applicable to the job that she was trying to get.
She had to come to us so that we could teach her .NET, and then she moved into the job that she wanted.
Here's what you should do, when you're picking your stack.
Look at what employers want and listen to what employers are hiring for.
That may vary between the areas that you live in, but go to something like Indeed and just look and see how many open positions there are for say a “.NET developer”, and see how that ranks with other languages.
Pick the language that's most wanted or most desired by employers. If you do, then that focuses your entire learning, and tell you what you should learn next. You can have a definitive path that leads to your goal to get a software development job.
Step #2: Use Immersive Learning
Now, in step one we talked about what you should learn, and now let's talk about how you learn it.
Now most people out there are buying lots of books, or they're taking some online tutorials, or some offline classes.
And what happens is they usually end up quitting, because they're either confused or undisciplined.
They don't know which route to take and they're really overwhelmed with all the choices out there. What happens when you're self-learning is you take “this course” and “this little course here”, and a “little course” here.
But let me ask you a question:
What if you bought a book and you want to become a professional fighter?
And you bought Mike Tyson's book on boxing, and you read it from cover to cover. You digested the entire thing. You actually read the entire book.
Do you think you'd be ready to fight?
Would you get in the ring with a professional boxer? Probably not.
What if you took his online course and you looked at every single fight Mike Tyson had, and you studied everything that he did, and he gave you all the techniques online - do you think you'd be ready to fight?
No! It would lead to a knock out!
Here's the thing that you need to understand about immersive learning. Immersive learning is more than just a class that you take in person. With immersive learning you get a coach.
See, Mike Tyson had a coach in the early years of his career, and that coach made him stay on the right path. Made him do the right things. Eat the right things. Train the right way.
And early on in his career Mike Tyson was un-freaking stoppable. Because that coach kept him on the right path.
With immersive learning, when you learn how to code, you get that coach who will encourage you when you want to quit.
To keep you on the right path, to keep you doing the right things. To make sure that your learning path isn't fractured, it is down the road towards one goal, which is to get a software job. And so what I want you to learn from this if you get anything, is that immersive learning is more than a class, it is getting a teacher, a mentor or a coach, because we all need one. The people at the highest levels in society have coaches or mentors that tell them what to do, how to do and how to be, to be the best at their job.
If you want to learn how to code, you need to have a coach that has coded before, not just an online video. Because that coach can tell you when I'm confused, he'll un-confuse you. When I want to give up, he'll keep you on the path and say, "Hey, don't quit. You're doing well, you can do this, you can keep after it." Because in the online course there is no encouragement, you're just watching a course. And you don't really know what to do because sometimes a course doesn't cover everything. Or the thing that you have the mental block on, the coach can come in and provide his expertise and speak into your situation and say, "You know what, this is what you're missing, this is what you need to do." And that gets you right back on the path.
If you really want to change your life and you really want to be a software developer. What we think is the best way to do that is through immersive learning, and that involves a teacher, a coach or a mentor in your life that knows how to code that can teach you the things that you need to know, so that you can that jobs as a software developer.
Step #3: Build Professional Projects
Now, what most people that I see online and on Twitter and these things, is they're building projects and they're writing code, but they're not what I call pro level projects, or professional projects, or they really don't do anything at all. I see a lot of things like a Tic-tac-toe site, or is a hotdog, I've seen that coming out of boot camps.
Build a professional project that solves a business problem. Now, there's a couple of reasons why you do this, and the first one is, imagine if you're like me, you're a Cubs fan. And you're walking down the city street out on the corner, and you see another person wearing a Cubs hat. Now what you can do, is you can immediately strike up a conversation with that person because you share a common passion for the same thing. It's instantly recognizable when you see another Cubs fan. And so you can talk about the W flag or you can talk about the last world series. You can talk about all of these things and you have an immediate kind of rapport with that person. And the same thing can happen in a interview if you build professional projects.
Now, what is a professional project? A professional project should be something that has a professional UI. Let's talk about UI for a second. UI could be anything that looks like a standard application. If your UI is kind of like super trendy, or it's got a lot of backgrounds, or it's not really pro, it looks really playful and funny, then that's not what lends itself to getting hired. What you want to do is build a UI that is very pro level.
The second thing is, it must solve a business problem, and third it must be connected to some type of database. Now, at the Coder Foundry we teach something called a bug track, or a issue tracker, and the issue tracker does a lot of things. Number one it has, authorization, authentication, so the user can log in. It supports roles, and so that the user when they log in they have certain roles, they have certain things they can see, a dev role, a admin role and these kind of things, these very complex business problems. And so this bug tracker tracks issues of software projects. Now the reason we teach this, is when you get to an interview situation, the dev manager, the tech lead or the interviewer already has a bug tracker in his organization, and therefore when they look at your project, they instantly know what that piece of software is supposed to do.
They will also look at this bug tracker very visually, so let's go back to the UI. If the UI on it is attractive and professional. They're going to assume the code is professional and the person who wrote it is professional. If it's kind of got a lot of misspellings, or it's not lined up, or it's kind of janky. They're going to assume the person behind the code doesn't know what they're doing. But if you can present it in a professional way, then the person can really buy based on seeing that. People are visual buyers, which means if you show them something, they're going to look at it, and based on its attractiveness and when they look at it, that will influence their decision to a great degree.
For example, we have a Coder Foundry student walk into a organization. He showed his bug tracker to the hiring manager, and the hiring manager remarked, "Can we use that here when we hire you?" If you think about that for a segment, he already said I'm going to hire the guy, because he showed him something that was working. We had another guy that showed his bug tracker, and he said, "Wow you can give JIRA a run for your money with that." Immediately, he put that developer into the category of professional developer, and equated to JIRA, because he showed him a working bug tracker.
Now, let that sink in for a second. If you build professional software projects, it's attractive, it's well designed, it solves a business problem that's immediately recognizable, it connects to a database. It has authorization, authentications, all these kind of features built in, you're well on your way to getting a software job. Because you know why? Because you know how to code, and if you know how to code, they will hire you.
Step #4: Control the Technical Interview
You've picked your right stack, you've been learning immersively, and you've built a professional project, and now it's time to actually interview for that job, so you're almost there. Interviewing for tech jobs can be kind of scary, it can invoke a range of emotions. You can go on the Internet and you can search all the horror stories of people totally bombing these tech interviews. And they kind of follow the same problem, and we teach these at Coder Foundry of how to avoid and don't go into these pitfalls.
I think what I'm about to say is not well known, these are actual secrets I think to winning the tech interview. And these come from my personal experience as a contractor when I won a lot of tech interviews. It also comes from me running a consulting company, when I'm talking to clients about how we win projects. In other words you got to think about this, I am selling myself into the company, and that's step one. That you've got to get over the fact that I'm selling myself into the company.
The second thing is that most people make is they try to memorize code trivia, and there's a legitimate reason for that. Because when you go into most tech interviews, the tech lead ... The hiring manager will typically find his tech lead, his tech lead doesn't want to interview you. He goes out and he gets to ASP and he says, "Top 10 ASP.NET questions every programmer should know." He'll type that in there and he'll just print those off, and he'll start at number one, and he'll go down one, two, three, four, five, and ask you those in order. Until you can't remember or the code trivia, your short term memory fails you, and then decides, "Look, he should have known that, and he can't work here." And that has nothing to do if you can code or not.
The step one is this, when they ask you that code trivia question, you have to relate that to your portfolio that you built in step three. In fact, before they even ask you a question, you should ask them this, "Hey, how are you doing today? Thanks for interviewing me. Do you mind if I show you my portfolio, because I really think that would allow you to see what I can do, and we can talk together to see if I'm a fit for your position." And so right away you said I want to work here, I've got something to show you, do you mind looking at it?
Now, there may be a few that says, "I don't want to see that, I want to ask my questions." But for the most part, you can get them to look at your portfolio. You got your portfolio on your screen, or you've got it on laptop and you've spun it around, and they're looking at it. If you can get them off the code trivia questions and start asking questions about the project that you've won, you have no controlled the interview. Now they're going to ask you questions about your bug tracker or whatever, and you should be able to answer those.
The second thing that you can do is actually, "Hey you know what, that's a great question, let's look at the code." When you show them the code on the screen, now you've done another kind of what I would call a very meta strat or something very deep, is that now you don't have to do it from memory. You can show it on the screen and you can look at that code and walk them through that code. And that is a whole lot better than trying to memorize the top ASP.NET interview questions of 2019. I mean, you don't want to know all of those things, you want to be able to show them the project that you're building.
Ask this question, "Hey, what are you guys trying to build?" And you're like, "That's an odd question to ask at a interview." Well, let's put it this way, let's say you went on a date, and you went on a date with someone, and all you did was talk about yourself for an hour, do you think you're getting a second date? Probably not, 'cause you'd be self consumed, self absorbed. What you can do is you can ask them, what are you trying to do here? What are the projects you're building, what are you trying to do? What's the goal of this job that you're kind of hiring me in for.
Let me give you a personal example, I interviewed at a very large manufacturing company. I can remember walking in there to the interview as a contractor, and I opened up my thing and I said, "Hey, what are you guys trying to build here?" And the dev manager and the tech lead talked about work the entire interview. And when they were talking I would interject and say, "Wow, that's really cool, that's neat, I wish I could work on that, I'm really excited to be working on that." And then 30 minutes later, they shook my hand, I walked out, the recruiter calls me back and says, "You know what, you got the job. What did you say in there?" And I'm like, "Nothing at all, all I did was ask him about work, and then they talked about work."
To sum it up, the first thing you should do is have a portfolio, ask them to look at it. And then if they ask you what I would call a code trivia question, take that question and relate it to your portfolio. If they ask you about classes or objects you want to object oriented program, show them something in that project that demonstrates that knowledge in being proficient. What you want them to do is to get them to ask a question about your portfolio and off the 50 questions on the paper. The second thing you do is ask them about the job. Ask them what they're building, what are you going to be working on? That show initiatives, it shows that you want to be there, and if you do those two things, you can take control of the interview.
You may not well win any interview, but we need to win one so to get you a job. And these techniques have been proven over and over and over again at Coder Foundry to work. In fact when people come back to Coder Foundry as a student, and they fail a interview, I'll ask them, "Did you show your portfolio?" And without exception, they'll say, "No, I didn't." And I'll say, "At the next interview, show that portfolio." And when they show that portfolio, they get a job." To take control of the interview, show your portfolio, talk about your portfolio. Be interested in their job and ask them for work.
Step #5 Work with Tech Recruiters
I think that once you understand the relationship between the recruiter and the employer and yourself, you need to get over the fact that they don't know how to code. If they did, they'd probably be coding just like you're trying to get into. What they can do is, get you an opportunity that isn't posted on Indeed.com. That's the other thing I want you to understand, is that sometimes, and a lot of the times, employers simply call the recruiting firm and say, "I need a developer. I need a NVC a C# developer." And then from there, that recruiter is finding candidates for that job. That job is never posted on Indeed.com or Monster, or any of the other job sites. And a lot of the dev positions aren't posted, because they simple don't want to have the time to go through all the resumes, and they want the recruiter to do that work, and so that's great.
The second thing the misunderstanding is, the recruiters aren't taking money from you. It's free to use them, and this is how it works. When they place you to a job, the hiring fee, the employer is charged the hiring fee by the recruiting firm. And that means the recruiting firm pays the fee, this doesn't reduce your salary, it doesn't reduce your offer. It doesn't do anything to restrict how much money you can make in this industry. It just says that the fees are paid by the employer to hire you. If the employer comes in here and says, "I'd like you pay you out, okay, but I got to pay this fee. So like you know, you only can pay 78." That's not happening, if you're going to make 100K, they're going to pay you 100K, and they're going to pay the 20% of the first year annual to the recruitment fee.
But they're also in the same note is, you wouldn't of made 120 either, they look at these as different transactions, and they look at what my salaries are, and then they also have a fee bucket. I want you to understand that recruiters aren't costing you money, it's actually very free to do. Now, the other thing that I see is, devs are mean to recruiters and I also don't understand this as well. The first step with working with recruiters is this, be nice. If a recruiter reaches out to you, take the call and listen to them. Be nice, courteous and professional. After all they're just trying to find you an opportunity.
Now if you're already working a recruiter, you can tell them, I'm already working with a recruiter but you can call me back in six months or eight months, or something like that. If you're not, listen to them. Now the second thing you want to do if you're trying to break into this market, and that's the majority of the people watching this, is you're trying to get your first software development job. You must reach out to these recruiting firms. There's probably eight or ten, and there's four or five really large national ones. You get them to look at your portfolio. What this does is it allows the recruiter to see your skills in a way, just like step four where we're showing our portfolio to our employer. In this step, we want to show the portfolio to the recruiter.
We had a Coder Foundry student who was older, and he was transitioning form a different sector of the economy. His job experience had nothing to do with IT and nothing to do with coding. The only experience he had in coding was his .NET boot camp. And so the recruiter said, "I don't understand this, how can you learn to code in 12 weeks?" And he said, "Do you mind if I show you my portfolio." And once he showed the portfolio, the recruiter says, "I know how to sell you now in the industry." And that's what happens, you build a relationship, and if you're nice and build a relationship, be professional, follow up. These recruiters are going to work very hard at finding you opportunities to interview. Once you get the interview, you apply the steps one through four to win that interview and get that job.
To sum it up, be nice, be courteous, always take the call from recruiter, and then show them your portfolio, show them what you can do, show them that you're ready to work. And if you do all those things together and apply the steps we previously taught, you're well on your way to getting your first software development job.