How to Get Your First Job as a Self-Taught Programmer
Tags: beginners, programming, career, codenewbie
Published: 2023-03-17 07:00:54

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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kuhm1ohbt3fw4wh3l4zy.jpeg)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i3w91dvlacfz8yeh0u6j.jpg)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9whvj4kw2tvpjczvazcd.png)
## 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.)
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1j09xh70wp856919nlmw.png)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m7jl95ify8xcz2hyck3n.jpg)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dctmdz7r2xx4hcxb5z8z.jpg)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5upaho6dq0alyt9ky7vh.jpg)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jxt77vn3mim2dp4vxix9.jpg)
## 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".
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vzfs4jgdi611w9fh98x4.png)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s85l73amf1w449zwccaf.png)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/diurr5sryf2uvnn9srtq.png)
## 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!