How to Get Your First Job as a Self-Taught Programmer

A few years ago, I wrote an article right here on Dev.to called One Crazy Trick to Become a Programmer. (You can read it here: https://dev.to/bytebodger/one-crazy-trick-to-become-a-programmer-j8k) Since that time, I've received numerous emails and comments from aspiring coders who are still asking me how to break into the world of professional coding. So I've finally decided to take this a step further and provide some more-detailed suggestions on how to get started as a professional developer.

To be absolutely clear, I still stand behind everything I wrote in that original article. The "soul" of that article is just as applicable today as it was in 2020. But I'll also admit that the original article was a bit... glib. It was also very general - pounding away on the simple (but useful!) mantra of, "WRITE MORE CODE".

Recently, it's become apparent that some people just aren't sure how to translate the general bromides in that article into specific, actionable steps toward fulltime employment. So I'm gonna take it a step further by trying to provide more-targeted advice.

I'm also going to target this article specifically toward the self-taught crowd. I'm doing this for one simple reason:

I myself am entirely self-taught. I've never attended a code camp. I've never taken a single course (college or otherwise) on coding. Everything in my modest brain is there because, at some point, I had to sit down, by myself, and figure out how all this stuff works. So I guess you could say that I have a bit of a soft spot for other self-taught devs.

Of course, I realize that there are people with comp-sci degrees who are also struggling to get their first real programming jobs. And if you're in that crowd, there will still be some actionable nuggets of wisdom for you in this article. But my target audience is all the people who received no formal training in application development.

I'm also gonna write this mostly from the perspective of frontend development. But I think the lessons would apply equally if you're a self-taught backend dev. Just swap out some of the technologies that I mention for those that are more applicable to your scenario.

So... let's dive in.

Skills vs. Experience

The whole point of my "WRITE MORE CODE" mantra (from the original article) was that no one can magically give you experience. Experience only comes over time. But you can give yourself skills. And the only way you get more skilled as a programmer is to... write more code.

But I'm not gonna take all of this article to just keep hammering away on that mantra. I'm gonna suggest some things you can do to bolster your skills while you're searching for that first company that will grant you some experience.

The first thing is to tailor your employer-facing persona to focus on your skills, and not on your experience. This means that your resume should be skill-centric. Your website should be skill-centric (more on this later...). Any personal projects you take on should be focused on broadening your skills. Basically, you should be constantly thinking about what you can do to add more tools to your toolbelt.

For example, I see many newbies who've been diving into React. And that's great! There's broad demand for React devs and it's wise to have a solid grasp of the library. But many of these devs can do little else besides React.

Have you worked at all with jQuery? (Yes, that technology is getting a little long-in-the-tooth, but it's still massively used and it can teach you a lot about certain core JavaScript concepts - such as anonymous functions.)

How comfortable are you with JavaScript and TypeScript? They're used almost interchangeably today in the workplace and it can be a liability if you're a TypeScript wizard but you get uncomfortable if someone asks you to code something up in plain JavaScript (or vice versa).

Have you experimented, at all, with other frameworks like Angular? Or Vue? Or Svelte?

How about Node? It is, afterall, JavaScript. But it's amazing how many freshly-minted, so-called JavaScript devs can seize up at the site of a Node application.

I fully realize that, as a newbie in the field, it can feel incredibly daunting to have to tackle all these different "angles" of frontend/JavaScript development. And I'm not asking you to become a JS/TS/React/Angular/jQuery/Node/Vue/Svelte superhero all on your own. But the more of these skills that you can confidently boast about on your resume (and hopefully, during interviews), the better off you'll be.

The point here is that you can't make up a robust job history out of whole cloth. So you'll need to do everything you can to ensure that you can at least boast a well-rounded skillset. You're gonna need to find ways to build up a resume without relying on the one thing that shines in most resumes - a robust job history. That's why you need to focus so hard on bolstering your list of skills.

Do NOT Skimp On HTML/CSS

I could've shoved this under the prior section, but I'm listing it here separately because the modern code camp culture has, IMHO, spawned a small army of new devs who feel pretty good about their JavaScript skills - but have only basic knowledge of HTML/CSS. It's easy for HTML/CSS to feel almost like an afterthought. But it should be your first thought.

Without HTML/CSS, you have no web app. And if your answer to every presentation challenge is to throw everything into a <div> and slap a few style attributes on it, potential employers are gonna spot this right away.

How confident are you with Flexbox? How about Bootstrap? Do you know what "responsive design" means? Can you build a responsive site? There was a time when some of these challenges could be shunted to the design team. But nowadays, employers expect their frontend devs to be completely comfortable with all aspects of HTML/CSS.

Have a GitHub Presence

If you don't already have a GitHub account, you need to do so. Now.

No... seriously. If you don't have a GitHub account, stop reading this article and go create one. RIGHT. NOW.

You may be thinking, "I don't have anything to put in a GitHub account." I don't care. The first step is to have a GitHub account.

Why is this important? Because you don't have any job history to speak of. So the only thing you can do is to start documenting your code history.

Maybe you don't have any repos right now. But from this day forward, every time you complete a coding challenge or spin up some bare-bones web demo, I want you to create a new repo under your GitHub account and store it there. The code in those repos may not be the prettiest or the most advanced. Heck, it may look downright amateurish to a seasoned dev. But you know what looks even worse? Having no public code presence to point potential employers to.

To be frank, I delayed opening a GitHub account for many years. (Although it wasn't a huge problem for me because I was already an established dev before GitHub even existed.) I used to have dozens of little test/demo apps on my local machine that I played around with, but I never put them on GitHub. But those little apps at least provide some evidence of your skillset and the type of work you can do.

A GitHub account also has another (seemingly obvious) benefit. It forces you to get more comfortable with git (if you're not already). In modern dev, git is not a "nice to have". It's a core skillset. As a dev manager, a JavaScript savant who struggles with basic git commands is borderline-useless to me.

(Side note: Last year, at Amazon, there was a guy on our team who somehow managed to get hired without having basic git skills. He lasted all of two months. Quite frankly, I'm surprised he lasted that long.)

Open an AWS Account

Now that you have a GitHub presence, take the next step and open an AWS account. If you're worried about the cost, don't be. It's free to open an account. Most of their services are free to use for the first year. Even after that first year, any costs to you should be extremely minimal unless you start hosting torrents or doing some other kinda high-traffic activity.

I currently have four sites in AWS. And my monthly bill is usually about $8.

Maybe you're thinking that you have no need for AWS because you're not hosting/building public websites/apps. But I'm telling you, it makes life sooooo much easier when you decide to launch even your first little utility.

Using AWS Amplify, I can create a new GitHub repo, throw up some bare-bones code, then hook that repo up to Amplify and have it published, on the web, in minutes. If you want your own domain name for the app, you can purchase that right in AWS with Route 53 and have it live in less than an hour. Amplify even provisions an SSL certificate for free for all of your Amplify sites.

Once you have a GitHub repo hooked up to an AWS Amplify account, every single time you push new code to the repo, it will automatically build-and-deploy your latest code to the public website. It's sooooo easy. And cheap.

Not only does this give you a quick-and-easy (and cheap) path to launch anything, but it will also get you acclimated with the AWS ecosystem, which is a huge selling point with many potential employers. Even if the company you're aiming to work for doesn't use AWS, it looks good on your resume to be able to say that you're familiar with it.

To be clear, AWS is a massive beast in itself. And I'm not telling you to become an AWS Ninja. I'm just suggesting this as one potential way to A) bolster your resume, and B) have a swift path to launch anything that you'd like to publicly display. Of course, you don't have to use AWS. There are other cloud-computing solutions that will give you similar capabilities and experience. The exact platform you choose is up to you.

Build Stuff

Now that you have a GitHub account to house your code, and you have an AWS account to deploy your code, you need to have some... code. Yes, this is basically an extension of my "WRITE MORE CODE" mantra. But again, if you don't have a formal work history, you're gonna need some way to at least demonstrate your skill history.

If you're not sure what to build, start with your personal portfolio site. Maybe you haven't done that because you don't have any kinda meaningful portfolio to speak of. But even if your site contains nothing but your resume and a few other trivia facts about yourself, it's a good "first step" to getting a public coding presence.

One important note here: Do NOT half-ass your personal site. Spend some time on it. Try to make it look nice, even if it's weak on content. Pay attention to details like performance and accessibility. (HINT: You can use Lighthouse to generate performance/accessibility reports for your site.) Just last week, a hiring manager at a place where I'm interviewing (and I expect to receive an offer in the next coupla days) told me, during our interview, that he pulled up my site and he was amazed at how well it scored. He said that he frequently does this for candidates and usually the scores are abysmal.

But don't stop building stuff once you have a personal site up-and-running. Build more stuff. I don't even care what you build. The purpose here is not to illustrate that you are The World's Greatest Coder. The purpose is simply to demonstrate to potential employers that you are, in fact, a coder.

I don't even care if you're launching static sites. Put up a site for your church, or your D&D group, or... whatever. It may not be incredibly fun or engaging. But you gotta start somewhere. And you'll learn things - even if the stuff you're building isn't all that challenging.

Of course, if you can build something that better demonstrates your full coding skillset, then all the better. You can launch some simple utilities. You can launch something that leverages/extends a public API. You can even launch a site that contains tutorials on how to code. I don't care what you build. Just build something. And make sure that it's available for you to brag about when talking to potential employers.

Use Everything You're Building to Bolster Your Resume

Let's imagine that you've been trying to get a "real" programming job for the last two years. During that time, you've been working on personal coding projects and developing websites/apps for friends/colleagues. During the same period, you've also been working as a waiter to pay the bills. Many people would represent that on their resume like this:

EXPERIENCE:

2021-Present
Waiter @ Joe's Chicken Hut
Responsibilities: Spitting in food; Angering customers; Taking smoke 
breaks;

In other words, they wouldn't put anything on their resume that pertains to coding because they don't have a "real" coding job. But here's how this should be represented on your resume:

EXPERIENCE:

2021-Present
Self-Employed @ My Awesome Digital Solutions, LLC
Responsibilities: Launched a new website for a local faith-based 
organization; Forked ChatGPT to create an interactive tool for 
interview preparation; Developed a utility for managing Spotify 
playlists; Partnered with local dev users group to craft coding 
tutorials;
Technologies Used: TypeScript, JavaScript, HTML/CSS, Bootstrap, 
jQuery, GitHub, AWS, REST, GraphQL, React, Redux

2021-Present
Waiter @ Joe's Chicken Hut
Responsibilities: Spitting in food; Angering customers; Taking smoke 
breaks;

If you're thinking, "But I didn't get paid for those projects," you're missing the entire point. It doesn't matter if your total income from My Awesome Digital Solutions, LLC over the last two years was $27.83. As long as you actually did the projects listed under that resume entry, you're not lying - not at all. Also, there's absolutely nothing wrong with having concurrent work histories on your resume. People do it all the time.

And how does anyone know that you actually did those projects, with the technologies that you've cited? Well, because they're in GitHub, and probably viewable at some public URL.

Contribute To Open Source Projects

I'm gonna open this section by freely admitting that this suggestion is hard. Most open source projects are maintained by a core group of dedicated senior devs who know the package inside-and-out. Not only can some of those communities be incredibly insular, but it can be extremely difficult for someone who's not already deeply ingrained in the package to even know where to begin. While it's great, in theory, to say that we should all be doing our part to contribute to open source, in practice, it can be daunting to get even a single line of code approved and merged into an open source project if you're not already deeply ensconced in it.

So why am I telling you to do this? Especially if you're not deeply experienced yourself? Two reasons:

First, diving into established open source projects is one of the only ways that you can see what "production code" looks like before you've ever had a chance to work in an official programming role. What do I mean by "production code"?

Well, there's a nasty little secret that most people don't tell you when you're first learning to code: The "production code" that you typically see in most live codebases usually looks nothing like any of the code that you've yet been exposed to. That may sound like a scary fact. But it's true.

When you're going through tutorials, everything is "dumbed down" to the simplest possible level. This is done on purpose because, if I'm trying to demonstrate a single, targeted principle, I don't want the tutorial to be "muddied up" by the myriad bells-and-whistles that you'd often find in a large-scale app. I only want to illustrate the targeted principle that I'm trying to demo.

That makes perfect sense when you're trying to teach a single, simple concept. But it can cause someone's head to spin the first time they're ever exposed to "real" code out-in-the-wild.

I've seen this firsthand. I've witnessed newbies who managed to get hired, and they showed up on the first day thinking that they know what "real" code looks like. Then they get exposed to the Big Hairy Real Life App that we work on. And... they're lost. In fact, I've seen some of these guys quit a job within days because they felt completely out of their depth.

Sometimes live apps look insanely complex because they're legacy apps that've been cobbled together over many years, and by many different devs, to the point where they've become a certified mess. But even in new apps, or even in apps that are fastidiously maintained, the code can still be insanely difficult for a newbie to grok. This is because that new code isn't some simplified tutorial. It's a real-live app that has a lot of different "hooks" and dependencies embedded within it.

If you wanna avoid that massive shellshock the first time someone drops you in the middle of a live codebase (or a coding interview), there are few options. Because companies aren't just gonna hand over their codebase for you to learn from.

But there is one fabulous way to see what "real" code looks like without having to be hired at some company. That way is to jump into an open source project. Open source projects often have just as much complexity as you would expect to find in corporate apps. And you don't need to be hired anywhere to start acclimating yourself to it. It's all right there, publicly available, in GitHub.

The second reason that I want you to start wading into the open source waters is that it can be a great boost to your resume. For example, let's imagine that you manage to get a pull request, with a single line of code, merged into the React project. Now, to be perfectly frank, even accomplishing that would be quite a challenge. But if you did??? Well, you could say, with perfect honesty, that you are now a contributor to the React project. That'd be quite a nice chit on your resume, dontcha think??

Sure, your "contribution" would consist of a single line of code. But who cares? You could still say with total integrity that you are, in fact, a contributor to the React project.

Consider Code-Adjacent Roles

This suggestion may sting a bit. If you've had your sights set on a programming role, you probably don't wanna think about getting hired in QA, or as a business analyst, or as a data analyst, or in desktop support, or as a PM. But sometimes this can be a way for you to get your foot in the door.

I've been on many dev teams where I never saw a single newbie hired from outside the company. This doesn't happen because someone's trying to punish you. This happens because newbies can be a liability on the team - draining time from other devs and potentially introducing bad code.

But I have seen, on multiple occasions, where someone within the company who's not technically in a coding role, gets approved to join a dev team once they've shown that A) they're really a great employee in another role, and B) they actually have coding skills.

Think about it. If Joe's coming to us "off the street" and his resume clearly shows that he's never worked as a programmer before, it's actually pretty reasonable to believe that he may not be cut out for this environment and we may need to escort him out in a frighteningly-short period of time.

But if Joe already works for our company (in some other role) and we interact with him on a regular basis, we have the freedom to talk with him whenever we want. We can see if he's doing any coding-like work in his current role. Even if he's not doing any coding at all, we'll probably be much more comfortable with the risk because we already know this guy and we can see how he works.

I'm not just telling you this in theory. My first corporate role was as a "Web Content Editor". Sure, I was technically working on the website. But I wasn't (initially) allowed to make any code changes. I was just an editor. I updated static text.

But at the point that I was hired into this role, I'd already been coding - on my own - for a number of years. And when problems cropped up on the site that would normally take weeks/months to get IT to fix, I told them, "Well, you know... I could actually fix this for you if you want?" It took a little while, but eventually they realized that I actually knew what I was doing. By the time I left that company, my official title was "Application Developer".

Blog

I realize that this suggestion will not suit everybody. Writing is a proclivity that some just don't care for. But blogging can be incredibly useful.

First, it expands your public presence. The never-been-hired candidate that no one's ever heard of is often less valuable than the one who has a rich history of blogging about tech issues.

Second, the mere act of blogging often leads to deeper understanding on the issues that you're writing about. The blog-reading community is your "rubber ducky". I can tell you that, on numerous occasions, I've sat down to write a Dev.to blog on some software concept that I thought I fully understood - but by the time that I tried to crank out the explanation in a formal article, I realized that there were flaws in my logic.

Even if the act of explaining an issue doesn't highlight the flaws in your logic, you can bet that the commenters probably will. And you know what? That's a good thing. I've learned some great tips by reading the comments that were made on my own blogs! That expanded knowledge will only help you in your quest for a dev job.

You may be thinking that it's silly to blog about programming precisely because you're so new. But blogs don't even need to consist of you telling the world how it's done. Blogs can even be fashioned as open questions for problems that you're struggling with.

Pitch Your Services

When you're applying to open positions, you're already at a massive disadvantage. Job postings are typically created by companies who have significant salaries to offer, so they can afford to be picky. And the mere fact that the job is advertised means that there will inevitably be a large number of applicants. And nearly all of those applicants will be more qualified (at least, on paper) than you.

But not all jobs start with advertised openings. If you're paying close attention, sometimes you can pitch someone on the idea of hiring you. In such a scenario, you're not competing with All The Other Applicants - because there are no other applicants.

Imagine that you know a small business owner and you can see him struggling with manual processes. Then imagine you propose that you could build some tools for him that will automate those processes - assuming that he hires you.

Is that likely to work? No. But it can't hurt to ask. You never know...

And to be clear, even if that small business owner actually does agree to hire you, the pay may be abysmal. But it's probably still more than you're making in your current job. And after a year-or-so of proving yourself in that type of role, your resume will look stronger and you can leverage it into a better role with a company that pays more.

Don't Give Up

In conclusion, I just wanna say that, I get it. I really do. Finding your first programming gig can be really tough. Especially when you've got that "self-taught" millstone hanging around your neck. And I know that I haven't written anything here that's a silver-bullet answer. Even if you do everything I'm suggesting, it's still gonna be... hard.

All I can say is: Keep working on your skills, your public "footprint", and your projects. There are opportunities out there, even if they're pretty hard to see at times.

Best of luck!