How to Get Your First Dev Job: A Complete Guide

Intro 🚪

If you are reading this article, you've probably heard of a strange phenomenon.

I'm here to tell you that yes, it's true: the vast and mysterious realm of developers is accessible to you, the humble sales assistant, accountant, fast-food worker or philosophy graduate, and the price of admission is not (necessarily) four or more years of gruelling and expensive education. In fact, you need only to ask for entry.

I know, because I did it. I taught myself to code online and landed a good job at a software company.

But you may also know that the road to the door can be long, winding, and full of confusing words. You're probably wondering how best to avoid the trapdoors, navigate the mazes and tangled forests, and appear wise and knowing to the keepers of the gate.

Well, I'm going to tell you that no matter how long and hard the journey, you just need to focus on three factors. I'll tell you exactly how to do that, and also give you three secret weapons to help you along the way.

The factors 📊

The three factors you need to work on to get your first developer job are (in no particular order):

1. Your technical ability and knowledge, in the context of the job you are applying for
2. Your general employability, i.e. non-technical skills, traits and experience
3. The number of positions you are considered for

Of course there are other factors that affect whether someone is hired, such as luck, systemic issues or any number of prejudices or irrelevant considerations on the part of the employer. However, this article is about what you can do to get a job, right now. In that context (and I mean only in that context), every moment spent dwelling on these other factors is a wasted one.

A game of percentages

You need to understand the three factors above for what they are: things that increase your chances of getting a job as a developer. Being employable is not a binary state. You are not 'unemployable' as a developer, and then at some point emerge from your cocoon into an 'employable' developer butterfly.

The choice to hire you is an individual one, made by an individual company. You could be hired with next to no technical skills, or you could do everything right to get a particular job, but still not get it.

In these circumstances, the only thing you can do is anything that will positively affect one of the three factors. All other things being equal, if there is a chance to increase your technical ability, you'll take it. If there is a chance to make yourself more 'employable', you'll take it, no matter how hard it is to judge yourself, or how much you hate promoting yourself. If there is another application to be made, you'll make it, no matter how afraid of rejection you are.

The above may sound a little obvious, but if your journey to getting a developer job is like most people's (and mine), there will be plenty of opportunities for you to bemoan something outside of your control rather than taking a targeted, positive action. This is natural and only human, but you are going to need to keep picking yourself up and refocusing, time and time again.

Priorities

The caveat to the above is that you only have so much time. In this article we'll look at how to prioritise in each of the three areas so you can maximise your efficiency.

You may also be wondering, how important is each factor? There is no exact answer to this, but neglecting any one of these factors is damaging to your chances of getting a job, and it's far better to have a good level in all the factors than to have disproportionate focus on one.

Many people focus far too much on factor 1, usually because they are most comfortable with working on technical skills. But virtually no company hires someone that did not present themselves in a good light through their communication with the company, and who doesn't seem like someone who can be worked with. And no company hires someone who they haven't heard of because they never applied, or who sent one email that got lost in a packed inbox.

Some people go all in on factor 3, neglecting the other two, most commonly factor 2. But the fact is that if there is something fundamental holding you back, like poor communication skills, it's not going to matter how many companies you apply to - they are all going to react the same way. You need to be very aware of whether you have the fundamental qualities required for the positions you are applying for. This can be difficult because the companies you apply for will usually not tell you this, and mostly just ignore you. But we'll look at some ways you can improve these skills later.

How long will it take?

You may have seen articles in the form of 'how I became a developer in [x] months', with the only constraint on x seemingly being that it is greater than 0. One such article may have even inspired you to become a developer, and they often have lots of useful information in them.

However, aside from the fact that they usually focus mainly on factor 1 and neglect the other two, they also tend to obscure the fact that transitioning into a coding job is a personal journey that depends very much on your own circumstances, traits, and the amount of time you have available to dedicate to it.

The truth is that you should try to get your job as fast as possible, but no faster. Which sounds obvious, but when comparing yourself to others, you'll often feel pressure to go faster than you can. You will find it difficult, and chalk up your failings to personal deficiencies rather than seeing them as an inevitable part of the journey. You may face financial and personal pressures that make it seem like you needed to get your new job yesterday. But all you can do is keep plugging away at the three factors.

To give some kind of indication, yes, it is possible to get a developer job in a matter of months, given full-time study and efficient, focused learning. Less than 3 months is incredible, less than 6 is still remarkable and usually requires the help of a bootcamp. A more normal timescale for full-time study is 6-12 months. For anything less than full-time study, 1-2 years would be a more common timescale. All of this also depends on the requirements of the job you get at the end of it as well - there are many kinds of developer roles.

A wake-up call?

If you are already some way on the journey to your first dev job, just understanding and acting on the advice in this section will take you a long way. If you already know the best way to gain technical skills, become employable or get your foot in the door with a company, but have been neglecting one of these factors, your main take-away from this should be to just get on with working on it.

But I'll now go into a lot more detail on how to work on the 3 factors. First, I'm going to tell you your secret weapons.

Your secret weapons ⚔️

Many people know some of the things I'll tell you in the next few sections, such as where to find coding materials, what to put on your CV, and so on. What they struggle with is some more fundamental problems.

They lack confidence, they don't see themselves as good enough to be a developer. They struggle with keeping discipline and good habits. They give up too early.

But you are going to overcome those challenges. You have some secret weapons.

1. Vision

The first step to achieving anything should always be honing your vision of where you are going and how you see yourself. Below, we'll talk about getting clarity on the job you want. But ideally, you should be looking even further beyond that.

Where do you want to be, ultimately? What would you be doing if money was no object, really? It doesn't even matter if the answer is not 'being a developer', if becoming a good, well-paid developer is how you get there. It also doesn't matter if the answer is just a guess (you're not a soothsayer), so long as it helps to focus and motivate you.

Supercharged motivation

Once you have a long-term vision, you should already be even more excited about your journey. Work backwards from there to the short-term. Roughly plot out some points on the journey - where will you be in ten years, five years, one year. Just guesses that don't seem totally unreasonable. This should lead you to a better idea of the first developer job you want to get.

Once you've done this, everything you do from now on should have a clear why behind it. When you have to do hard things like sit down to code, make another job application or attend a networking event, and you wonder why bother?, your answer is right there staring at you: because it will directly lead you to the thing you most want to do in the world. Then you have a simple choice: do something a bit hard now for limitless gain in the future, or give up on what you really want.

You 2.0

Having a clear vision also goes to the core of how you see yourself. If you can see and believe (even just a little bit) a vision of yourself achieving something you would be really proud of, you can start to see how you could change and become the sort of person that can achieve that result. Then simply start trying to be that person a little more every day - the more you practise, the better you get.

Start thinking of yourself as whatever you want to be - an entrepreneur or freelancer, a problem-solver, a leader - and let your actions slowly start to fit the role a little better. And, of course, start thinking of yourself as a developer. As soon as you write some code that does something, you're not an aspiring developer, you are a developer, by definition. Just not a professional one. So embrace it. Put it on your CV. This is the new you!

2. Habit

Habit is the key to achieving any goal. Once you have a big, long-term vision, you need to link it to a small, focused, consistent habit.

Scientifically speaking, a habit is more of an automatic reaction. It doesn't cover a conscious and deliberate action like coding for an hour. But the secret is to master the automatic behaviours that put you in the right place, with the right environment, at the right time, to do the activity you want to do. Once you practise this for a while, nine or more times out of ten, you will do the activity you intend.

Let's say you want to practise sitting down to code at a certain time. Here are some factors you need to think about:

• You need to be in the right frame of mind for focusing. Carving out some time at the beginning of the day rather than leaving it to the end will probably be better for most people. There is evidence that your willpower and ability to focus is sapped as the day goes on (see sources at the end of this article).
• Your environment needs to be as comfortable as possible, e.g. a proper desk with good ergonomics, preferably clean and tidy - a place that makes you want to spend time there.
• Minimise distractions. Just leave your phone in another room, seriously. It's the biggest productivity killer imaginable. If there are other people around, they need to know not to disturb you if possible.
• Have a clear time period with breaks. E.g. study in 20 minute bursts with breaks, or 45 minutes, whatever works for you. Use a timer for best results.

Slow and steady

When you start a new habit, you have to start small. You need small wins. If you say you're going to fit in 4 hours a day of coding that you barely have time for, you're setting yourself up to miss your target, and the negative self-talk most of us are very familiar with will happily step in.

Instead, focus on that small behaviour. It could be as simple as just sitting down at the computer at the right time. Every day, for a month. Or studying without getting distracted for an hour (breaks not included). Simple, quantifiable actions. It doesn't really matter if the study session went great, or it was really hard and confusing, and you didn't feel like you made progress. What matters is that you did what you intended, and that's all you can do. It will all add up.

Other tips

There's lots more I could say about habits, but here's just a few more tips to follow if you can:

• Accountability is a great tool. Tell one or two people you respect what you are going to do (don't only announce it on social media - no one there will chase you up if you don't follow through). For best results, write it down in the form of a promise.
• Be flexible. If something's not working, tweak it. You don't want to change your habit all the time, but you don't want to stick with something that's not achievable. Find what works for your schedule, your life, your personality, so you can do it consistently.
• Keep a chart on your wall of your progress. Set mini-goals and celebrate when you achieve these landmarks. It doesn't matter how much of the mountain is still ahead of you - always remind yourself of how far you've come and be proud.

3. Persistence

Most of us are guilty of a poor understanding of results. We expect results to happen steadily as a direct proportion of effort - a perfectly diagonal line on a graph. In most cases, it's actually a curve that starts off very gentle for a long time and then starts to curve sharply upwards.

Once we accept this (and it is very hard to accept), we have to commit to simply doing the actions, and have faith that the results will come later. If you've ever learnt a musical instrument, you know that in the beginning, after the initial rush of your first few little achievements, you start to feel like you've plateaued at a really low level, and that you're not making any progress despite your practise. Then, one day, like magic, you suddenly realise you can play something that you've been struggling with for ages.

Learning to code is no different. Getting a job is no different. These things are hard for a long time, until suddenly, they're not. You finally understand a concept. You finally get to grips with a language. You finally get the knack of job applications. You finally get the job.

It's easy to get discouraged in the thick of it. But if you have your clear vision, you have your simple, well-defined habit, and you have the commitment to just seeing it through until you are successful, then there will be no stopping you.

With all that said, let's finally look more closely at the three factors I mentioned at the beginning.

Factor 1: Technical ability 👨🏽‍💻

Factor 1 is: "Your technical ability and knowledge, in the context of the job you are applying for."

Note the second part - in the context of the job you are applying for. If your goal is to get hired, and time is of the essence, then everything you learn needs to be relevant to getting hired.

Naturally, if you don't know what sort of job you are looking for, you will struggle with knowing what to learn. So step 1 is to target a specific kind of job - the more specific, the better.

Targeting a job

How do you know what job you want? First you need to do a little research on what is out there. Google and YouTube are your friends here. Also try to speak directly to developers if possible, for example at the company where you work, or through social media like Twitter.

You don't want to drag out this stage too long - get some understanding of web dev vs. software dev, front end vs. back end and so on, just enough to start to feel some kind of preference, then choose. The important thing is just to make a decision. It's not for life. After you've gotten your first dev job, you can branch out or switch tracks - it happens all the time.

If you are really struggling with the decision, you may want to go further into a few different paths, for example by trying out a few different programming languages and seeing what you prefer. It certainly is never going to hurt to be learning something about coding. However, the longer you put off deciding what to focus on, the less efficient your journey will be.

Narrowing it down further

Once you've chosen your path, you will need to do some further research to understand the technologies involved, the type of jobs available, and to narrow your focus down even further. For example, you may have decided to become a front-end web developer. Even within this path, there is a lot of variety.

Do you want to build websites, for example as a freelancer or at a web design agency, focusing mostly on HTML and CSS, maybe doing some design work, and probably working with a content management system? Or do you want to work on web applications, focusing more on JavaScript and using a JavaScript framework? (for related discussion see: https://css-tricks.com/the-great-divide/). And which framework - React, Vue, Angular?

Look at job listings in your area to get a better idea of this. You should narrow it down to the point where there is a just a handful of job titles you are looking for (although some companies will use titles inaccurately) and you can instantly recognise the sort of job description that suits you.

When we talk about narrowing down the jobs you are eligible for, you may be concerned that you are reducing your chances of getting a job. The opposite is true. You are applying for fewer jobs, but have a much better chance of getting them, because everything you have been learning is relevant to those jobs. If you cast your net wider, you will be overlooked in favour of people with more relevant skills.

A note about job adverts

It's well known that many developer job adverts are not very realistic or helpful. They may list skills that are not really required, overemphasise certain aspects or ask for a computer science degree regardless of whether the role requires it.

Companies often advertise for their ideal candidate, and there can be quite a gap between the job description and the skills of the person they will actually hire. In other cases, the advert may be written by someone that doesn't fully understand the role.

It's very important to bear this in mind to avoid being discouraged. Focus on whether the main gist of the role suits you. Then apply.

Learning

This is the best part of the journey. If you don't enjoy learning, you probably shouldn't become a developer.

But how should you do it? First, keep in mind two main principles, which we'll come back to:

1. Learn from a reputable source of information
2. Make sure you are getting value for money

Two options

Let's assume you are not going to do a computer science degree, since the main topics of study are not immediately relevant to the typical new developer.

You then have the choice between some other paid course, most commonly at a coding 'bootcamp', or 'teaching yourself' with online resources. As someone who did the latter, I'm a bit biased towards it, but you have to choose the option that's right for you.

Teaching yourself is very difficult - you have fewer people to go to for help, it can be hard to learn the right topic at the right time, and you have to be very driven and self-motivated. You are alone with the mountain of information on the internet. On the other hand, you'll save a hefty amount of money, and if you get through it, you'll also come out of it with bucket-loads of resilience, research skills and problem-solving ability to brag to employers about.

If you feel like you probably need a bit more of a push and a guiding hand, a bootcamp could be for you. Your learning will be efficiently packaged up for you, you will have a cohort to get through it with, teachers to ask questions of, and probably be given the opportunity to network with some local companies. It's not uncommon for people to go straight from a bootcamp into a job, though it depends on the individual.

Just bear in mind that bootcamps are not currently regulated, and they usually ask for a lot of money for a relatively short period of education, so you should do thorough research and make your own judgement, keeping in mind the two principles mentioned above.

Teaching yourself

We'll now talk about how to go about teaching yourself, but this is not just for the non-bootcamp route. As a developer you will always be teaching yourself to some extent. Technology is always changing and the web is your instruction manual.

Here's three points to consider.

1. What you learn

This part should be fairly straightforward for getting your first dev job - you should know from your research where you need to start, and you can add some things to the list as you go.

However, the aim is to keep the list as short as possible to get your first developer job. As you start learning you will come across many, many different technologies and aspects of development. There will be a lot of temptations to stray off course. You need to build the habit of sticking with what is on your list.

2. Where you learn

There is no shortage of resources online to learn development, but they do vary in quality and price. You need to again bear in mind the two principles above.

I won't list them all here, because there is plenty of info out there if you google what resources are best in your chosen area of development. But I'll explain the types of content you will see:

• Interactive tutorial websites

Websites such as freeCodeCamp (free!) and codecademy (free/paid) offer tutorials where you can code in your browser, along with other kinds of content. You will probably want to make use of one of these kinds of courses at least once in your journey.

• Video tutorials

Video tutorials are great resources which I personally like a lot, and they're especially useful for beginners because you can see how professional developers write code and learn a lot from them. As well as teaching particular topics, there are lots of videos teaching you to build a particular project which you can code along with.

There are lots of great programming video creators, and I really strongly advise that you do some googling to find out who they are first, to avoid missing out on content you might miss if you just search for content on a particular topic. Many of them have free videos on YouTube, either on a single topic or a free sample of a paid-for course, so make use of these.

You can also buy courses on sites like Udemy (just be aware of Udemy's marketing tactics of hiking up prices then having an almost constant 'sale'). Don't shy away from buying a course from a reputable creator, because you will usually get what you pay for and get a lot more value than free resources. However, this shouldn't be your default option and you shouldn't need more than a handful of paid courses. Personally, I got a job after spending a grand total of £45 on Udemy courses (I bought three).

• Plain text information

You will find a lot of good content in the form of technical documentation, books and online references. For example, if you are learning JavaScript there is the MDN documentation and tutorials, sites like javascript.info and books like You Don't Know JS. Personally, I didn't use any physical books to learn to code - there was enough info available free online. But if you prefer textbooks, there are plenty, such as O'Reilly books.

• The stuff you find when you google a question...

Here is where you really need to pay special attention to the reputable source of information point. When you google a programming question you will usually find lots of articles on it, and lots of answers on the programming Q&A site StackOverflow. Usually the cream rises to the top. Just be careful. Make a habit of cross-checking information with documentation where possible and don't just believe someone because they used some big words.

• Audio

There are quite a lot of podcasts related to development which you may find useful when you are away from your computer. Because of the nature of the medium, they often aren't focused on strictly technical information but on related discussions.

My experience was that early on, I found it useful and encouraging to listen to podcasts such as CodeNewbie podcast and hear stories of people who transitioned into tech. But afterwards, I wanted technical information and found it hard to find. I also found that a lot of podcasts were aimed at more experienced developers and I found the discussions alienating and discouraging because I didn't understand them.

I did find a couple of podcasts that were right for me, and I encourage you to do some digging to find the ones that are relevant to you. But I don't subscribe to the theory that you should be trying to absorb as much development information as possible, regardless of whether you understand it - I think this can often do more harm than good.

3. How you learn

Most people don't think about this factor, but it's vitally important. It's a huge topic in itself, on which there is decades of scientific research, but I will mention just a few key principles that will drastically improve your learning efficiency. (Sources to back up these points are listed at the end of this article).

1. The holy grail: Active learning

This is a very simple idea, but it takes effort, so it's often ignored. The truth is, if you sit and passively watch a video or scroll through some information, you are not going to remember most of it. We are exposed to a cacophony of stimulus every second of our lives - if we remembered everything, we just wouldn't be able to function. Our brain is designed to discard most information.

So if you want to remember something, you need to make your brain know it's important. Anything you can do to get your brain working will help you learn, such as:

• Testing yourself. For example, make something by following a coding tutorial, then try to make it without the tutorial. It doesn't really matter how often you have to check the tutorial for answers - just trying to think for yourself will still be beneficial to your retention of the information.
• Asking questions ('what does that mean?', 'is that what I expected?', 'what do I think is going to be the answer here?', etc.)
• Coding along with a video (but trying to fully understand the information rather than just copying it out)
• Being creative - applying your knowledge in a new context by making something new or customising something that exists
• Cross-checking information
• Trying to explain the information to someone else, e.g. in a blog post (one of my personal favourites!)

You don't have to wait until halfway through learning to do these things, you can do them from the beginning. For example, it has been shown that testing yourself on a topic you know nothing about improves your subsequent retention of information on that topic.

Bear in mind that active learning is harder. It will feel uncomfortable. In learning science this is often called 'desirable difficulty'. You will come to recognise the right level of discomfort, which is somewhere between comfort and feeling completely clueless. If you are feeling completely clueless you need to break the task down into smaller pieces or try something a bit simpler first.

Because it's harder, you need to take regular breaks. Breaks have been shown to reduce stress and improve productivity anyway, so it's all good. And active learning with breaks will still be more efficient in the long-term than passive learning without breaks.

2. Rehearsal

Even taking all the advice above, your retention of the information will still degrade naturally over time, for the reason mentioned above (we can't remember everything). You need to rehearse information to make it stick.

The maximally efficient method is to rehearse information just before you are about to forget it, but this is very difficult, as the timing of that point has been shown to depend on a lot of factors. So don't worry too much about this. When you are learning to code on a need-to-know basis, there are natural points for rehearsal: when you need to use something you learned and you realise you've forgotten it. In my experience, I usually learn the info quicker the second time, so the time I originally spent wasn't wasted, and that's good enough.

Just be aware that if you are taking the time to study certain concepts, it could be worth also going over some that you learned a week or a month ago. The main thing is, don't feel bad about forgetting things. It's not a personal failing - it's just how the brain works.

3. Variety

Variety is good for a few reasons. First, doing relatively short bursts of varied activities (called interleaving in cognitive science) has been shown across many fields of study to be more effective than studying one concept for a longer period. So if you were planning for example to learn about loops in JavaScript for an hour, you will probably be better splitting the time between loops, if statements and scope etc. instead, even if it doesn't feel as helpful at the time.

Second, you want to get a diversity of perspectives. In an age of free-flowing but not necessarily correct information, you need to make sure the info you hear is actually correct. And when it comes to matters of opinion, the world of development is rife with these, so all you can do is hear a variety of perspectives and make up your own mind. So vary your learning materials as well as your activities. If you always stick with the same teacher or resource, you are missing the opportunity to become a better developer.

Finally, varying the context of learning has been shown to improve learning. Learn in different places, in different ways, with different music, and so on, and you have a better chance of it sticking.

Troubleshooting

Almost as important as your ability to learn is your ability to find solutions when things go wrong.

Writing code for computers is hard, because they do exactly what we wrote, not just what we meant. An unintended effect of your code is called a bug. Debugging is a huge time sap and a crucial skill for developers, which is often neglected. Many developers don't think too much about their approach and just try lots of things until it works. Here's a quick summary of some steps I usually take.

Googling

The web is full of answers to development problems. People have written about them in countless blog articles or discussed them in forums. All developers, from junior to senior, google stuff all the time. There is simply far, far too much to know and no point reinventing the wheel when so many have been there before you.

For example, if you have a problem with a specific library, you may find answers or at least better explanation of the problem on the Issues page of the library's repository on GitHub. But your most common source for answers will probably be StackOverflow, an invaluable Q&A site for development questions.

When googling, you need to bear a few things in mind:

• Phrasing is crucial. Don't ask the question one way then give up. Try a number of different possible keywords. Sometimes you will not know the word for the issue, but it will pop up in one of the search results. Then use that word in your search, and voilà! You find what you were looking for.
• Don't expect to find the exact answer you need for your use case. Often you can get what you need from the answer to a somewhat similar problem, which will inspire you to try something that solves your problem, or you come across some code that can be adapted a bit to suit your use case.
• As mentioned already, think critically about the answer you find. For example, don't just find one answer on StackOverflow and immediately copy some code. Look at the other answers and reaction. Cross-check what the person is saying and see if it is reliable, or if there are problems with the solution. If you don't, you will probably just cause yourself more headaches in the future.

While Google is often your first port of call, it isn't always. Some problems simply require basic programming knowledge to fix, or are very specific to your use case, and Google will be of less help here. I've found that when my code doesn't work and I find nothing via Google, it's either because I've just made some basic error somewhere, or my case is so niche that no-one has written about it.

Check the obvious things

Checking you haven't done something really stupid before you proceed will save you a lot of time as a developer. Check for typos. Check little things like whether your greater-than/less-than signs and true and false conditions are the wrong way around. Always assume there could be something really simple going wrong because this is quite often the case!

The next thing to check is the few things you think are most likely to be causing the problem. Just jump straight in investigating what is going on in those areas and you might get lucky.

In-depth debugging

If you've exhausted your other options, I find the best approach is a very methodical one. This is time-consuming but usually gets to the root of the problem. Problems usually arise in complicated, niche use cases. So first, create a more simplified version of the scenario where everything does work as expected. Then add things one by one, to get it closer to your real-life use case. Sooner or later you'll identify the thing that causes the issue.

Factor 2: Employability 👩‍💼

'Soft' skills are not really any less important for a developer than any other job, despite the stereotype of the unsociable programmer. True, you will probably escape being tested on these aspects, but you may be asked questions about them, and it will also greatly affect your application and how you come across at interview.

Let's look at how to develop and use these skills before and during interviews.

Getting an interview

Before you get an interview, you have one, simple goal: to get an interview. Forget about whether you'll get the job, forget about how the interview might go, forget about technical questions. Just do everything you can to make yourself stand out in a positive light - that means your CV, portfolio site and customised cover letter.

Of course, you don't technically have to do any of this (though you'll probably always need a CV). For example, you could get lucky and land an interview through someone you know. But if you don't, then you have no excuse not to do everything you can to sell yourself.

CV

CVs are still very relevant for developer jobs, and you should assume the employer will look carefully at it even if you have an online portfolio. You want your CV to be a simple, at-a-glance reflection of your best qualities and technical skills. Keep it to one page.

If you are a design-focused developer you can design something nice, but otherwise, don't fret about details like layout - it's window dressing. Use a nice, clean template that displays the information clearly and has a bit of colour.

Assuming you don't have much or any work experience that is relevant to development, I suggest you do a skills-based CV that has the following sections:

Title

The title can just be your name, and the subtitle is the job title you are after, or the specific one you are applying to. For example, my subtitle was usually Front-End Developer.

Don't say 'junior' developer. The company may or may not end up labelling you that way, but there's no point lowering your status yourself. Just calling yourself a 'developer' shows more confidence and is by no means inaccurate.

Profile

This is a bullet-point style tagline reflecting the key selling points - a couple of sentences at most. Here is the one I used: "Highly motivated, self-disciplined, self-taught developer. I create modern, responsive and accessible websites and applications."

Skills

List the technologies you are familiar with and other desirable skills e.g. test-driven development, responsive design etc.

Experience

Employers want to see experience that is relevant to a developer job. That means writing about the app you taught yourself to make is more relevant than some unrelated paid job. There's no rule that says you have to list all your paid work in your experience section - it's your CV, you can do what you want.

So create a sub-section for your self-teaching or bootcamp and summarise the key things you did. Any extra things you did like making something at a hackathon or contributing to open-source are good here too. Then you can add a brief sub-section on your most recent job, and put the rest of your work history on your LinkedIn so you aren't hiding anything.

Education

This can go last - just your most recent qualifications.

Finally, you will need your contact information somewhere, other website links (covered below) and a link to your portfolio.

Portfolio

An online portfolio is a chance to stand out a bit more to the employer, and a good place to show off the stuff you've built. It doesn't have to be complicated.

If your main focus is building websites (as opposed to web applications, apps or backend programming), you should arguably make the whole thing yourself, or at least heavily customise it using the CMS you intend to mainly work with professionally.

If not, I'd recommend using something a little more off-the-shelf and doing a bit of customisation, since you are going to need most of your time for working on the stuff to showcase. For example, I made a WordPress site for mine and integrated a paid theme. There was some hassle involved in learning to use WordPress, but I still ended up with an attractive, reliable site with a functioning blog in a relatively short space of time.

You want your portfolio to do three main things - emphasise your key selling points, showcase your projects and host your blog. This can be done in three sections or pages (depending on how your portfolio is laid out). Remember to also include a contact form or contact details.

Home / About

This will rehash some of the key points from your CV, but hopefully with a bit more style. So highlight who you are, your main attributes and skills, but add some nicer design into the mix. Look at other developer portfolios for some inspiration. Bear in mind, if you google for this you'll find some insanely good ones which aren't the most realistic examples for you - it's better to just find some good developers - blog authors, devs on Twitter etc. and look at their personal site.

You can also add a (brief) element of story about who you are to make it more interesting, e.g. briefly explaining what you used to do and why and how you are transitioning to tech - but remember to sell yourself along the way - emphasise why your skills suit tech and the characteristics and skills that helped you learn.

Projects

Secondly, you want a page to show off your projects. As well as linking to the deployed project and the code, talk a little about the project, why you made it, why you made the choices you did and what you learned. This will really show you can think and communicate intelligently about tech and give insight into your learning process, which is important to employers.

Blog

Thirdly, you ideally want a blog where you can write a little about tech and things you've learned. Yes, this is even more work, but it will show employers that you are enthusiastic, knowledgeable and eager to share that knowledge, which is a triple win.

Of course, you can and should blog on other platforms. For example, Dev, freeCodeCamp news and hashnode are popular platforms for free tech articles, and Medium is also still popular, though they have a paywall system. However, the best strategy is to have any articles you publish on these platforms be copies that link back to the original your own website via the canonical url section ('This article was originally published on...'). That way employers can see your writing on your own site and your site gets a SEO boost, plus you have full control of your original articles.

Many newcomers, and even experienced developers feel self-conscious about posting an article on technology. You could get something wrong, and some people might not like your article. However, if you use reliable sources of information and are not pretending to be an expert in the subject matter, you should publish it anyway. If something needs corrected you can make a correction, and anyone who responds with unconstructive criticism can safely be ignored.

Remember, this is helping you get a job, and getting a job is about putting yourself out there. The greater the exposure, the greater the chance of reward. And the majority of people in the developer community will be supportive of you sharing your knowledge.

Cover Letter

Cover letters are important - they highlight why you are right for this specific job, unlike your CV or portfolio. It's fine to have a rough template, but you need to tailor it for every application you make. Here are some key points to consider.

Format

Many people use the traditional Word-processed document approach, and so did I, but you may prefer to just write your pitch in the body of your email. It does seem a little antiquated to produce a 'letter' with the company address when you aren't actually posting it, though on the other hand it does show some effort and give it a little gravitas. Different employers will have different preferences so you just need to pick one approach - either will probably do fine.

Style

I see no reason to be formal in the content of the letter and I think an informal, natural style works best in this day and age. I start my letters with 'Hi,' and end with something like 'Thanks for your time', sidestepping those awkward old-fashioned introductions like 'To whom it may concern', or worse, 'Dear Sir/Madam'.

Content

You can find plenty of good pointers and inspiration online for this, and hopefully you already understand the main points (sell yourself, be persuasive, use evidence etc.) so I just want to emphasise some key points:

• Be specific. It's pretty obvious when you've copied a template and changed the company name. Yes, you may have never heard of the company before but you need to mention something that attracts you to the company and shows you do know who they are.
• Pitch you, not just your knowledge. Yes, you should mention that you tick off the main requirements for the job, but you are not going to be able to compete with someone with more experience on a purely technical level. You may as well acknowledge this, because you can bet the employer will already be thinking it. You have to argue that your drive, ability to learn and other personal attributes are what set you apart and will add more value to the company.
• Be real and honest. You are asking the employer to take a punt on someone with no professional experience - it's not unusual in the world of development, but it's still a big ask. Your letter really needs to get across your genuine enthusiasm for coding, and hopefully remind the employer of when they were first starting out. Just using lots of buzzwords and jargon won't cut it. You need to get your story into their head.

Other websites

Since you have been creating personal projects, you should have a GitHub account set up so that employers can see the code. Ideally, the code will be clean and tidy and the commits will have sensible descriptions.

As for social media, at a minimum you should be on LinkedIn as this will expose you to some opportunities, though not all good quality ones by any means. The setup is pretty simple - add the info from your CV, add a slightly longer work history if you want, and make sure to check the option for showing recruiters you're open to work.

Other social media is optional but may be useful. Yes, building a following on a site like Twitter takes time and effort, but just being on there, making some connections and following some good people may still expose you to opportunities and useful information. Many people on there are doing the #100DaysOfCode challenge so you may find it useful to do that or follow some people who are.

Commercial experience

Some of you may wonder if you should take an internship of some kind to gain extra experience to bolster your application for a full-time job. I'm not going to say don't do this, especially if the opportunity presents itself to you, but I do think you should focus your effort on getting a full-time job straight away, since it is possible.

The position you start off with will affect how employers see you, and if you start off at a very low level, it might be quite difficult to advance quickly to a higher level. Focusing all your efforts on building very in-demand skills instead might take a bit longer, but you improve your chances of getting a good-quality job at the end of it.

That said, if freelancing is something you are interested in and you have an opportunity to do it, getting some paid development work under your belt will certainly improve your standing in the eyes of an employer.

Interviews

The interview process is different for each company, but there are some key things you'll definitely need to do and prepare.

Coding exercises

You may be asked to build something according to a set of instructions and then submit the code. This could be later on in the interview process but in my experience it was quite early on, to weed out candidates.

On paper, this is great for you because you have the chance to prove your skills, despite your lack of professional experience. In reality, you may not actually have the time to do the assignment to the best of your ability, or the requirements may be unreasonable.

Nevertheless, I suggest you treat these exercises as good experience at professional development tasks and give it your best shot. Submit it unfinished if you have to, and always ask for feedback (though you might not get it). With any luck, you'll get a task you can complete well in time, and pass this stage.

Company research

You will have done a little of this already, but obviously, you need to do some more before interview. Look at the company website, social media, linkedIn if possible. You know the drill.

Preparing answers

The main part of your interview preparation should be preparing answers to general interview questions about your skills and experience. How you communicate in general is so much more important than whether you know the answer to some technical trivia.

On paper

I like to get my talking points for a potential interview question down on paper first.

You probably want to start by preparing some raw material that might be useful for a variety of questions. For example, the story of the main application or website that you worked on - what was the task, what were the specific actions that you took, what was the result, plus any lessons learned.

You probably also want to look at common questions and make sure you have something for it. So you could cover all the main topics likely to come up, and allocate specific examples and talking points to them. This also ensures you don't end up talking about the same example over and over.

Topics that might come up are things like communication, teamworking, working under pressure and time management. Remember these 'soft' skills are still important for dev jobs and you need to be able to talk about them.

Out loud

This is really useful and I suspect a lot of people overlook it: you should practise actually saying the stuff you've prepared. First of all, because you need to make sure you actually remember it and don't end up rambling in interview, but also, you need to make sure it comes across well - your body language as well as your words. Saying answers you've prepared that promote your positive qualities probably doesn't come naturally to you, so you need to practise.

While practising alone or with someone you know (or better, don't know very well) is good, I find it really helpful to record myself practising on my laptop, so I can watch it back and see exactly what impression the employer will get of me. This is definitely uncomfortable, but I find it helps me identify lots of things I can improve on.

Preparing questions

There is no easier thing you can do to improve your performance at interview than asking lots of questions. It will show that you are enthusiastic, that you understand and are interested in the company, and you are thorough and focused on details. So once you've done your company research, jot down lots of questions.

You can get a lot of inspiration for this online. Asking about the tech is definitely worthwhile, and the opportunities for your development. There are also plenty of things you can ask about the company values, practices and strategy.

Be genuine with this - if you are going to start your dev career with this company, you do need to make sure they are a good fit and will support you and help you grow - otherwise you are hurting your long-term potential for short-term gain.

Preparing for technical questions

Full disclosure - in the four proper interviews I did before getting my first dev job, I wasn't really asked any 'quiz' or 'whiteboarding' questions, as such. Yeah, I got a bit lucky.

There is plenty of material online to help you prepare for these questions. But I think the best preparation is actually knowing your stuff by just coding regularly, reading around the subject and trying to improve as a programmer.

Yes, you may gain a short-term advantage by practising specific algorithm exercises and looking up commonly asked technical questions, but I still think your main focus as a new developer should be learning in the context of building something, rather than in the abstract.

The interview itself

There are 101 interview tips that people give, but let's focus on a few key things.

Confidence

Confidence is so crucial. The employer is really looking for someone that tells them with their tone and body language, "Yes, I could definitely do this job well, you don't need to worry about me". How do you get this confidence if you don't naturally feel that way?

Firstly, remind yourself of your positive traits. The things you've overcome. If you're coming into development from an unrelated field and stuck with it, then you've got a lot of things going for you and a lot of reasons to feel confident.

Secondly, imagine that you're going to get the job. If you don't believe that can happen, you probably shouldn't be going for the interview. Then keep that frame of mind throughout the interview - think of the interview almost like a formality before you will be given the job (without being arrogant, obviously).

Positivity

This is also crucial - employers want someone who will contribute positively to the team and relishes challenges. I find the above trick - imaging you're going to get the job - works really well for this too, because it allows your genuine excitement about the job to trump your nerves about the interview.

Also remember that you can learn anything. Whatever doubts you have about your ability, whatever tough questions you might be asked, you have a safety net, which is that with a positive attitude, you could learn whatever you need to know, even if you don't know it right now. And that is more valuable to most employers than someone who knows quite a lot but seems difficult to work with.

Salesmanship

At the end of the day, the interview is an exercise in persuasion. There's no scope for being modest or reticent. Drive the key points home. Add an extra sentence at the end of your examples that highlights how your unique strengths were crucial.

The best opportunity for salesmanship is the beginning of the interview, especially when a 'tell us about yourself' style question is asked. This is your chance to highlight your key selling points. Have something prepared that you know by heart. First impressions are very important. Nail it, and you'll set yourself up for success.

Factor 3: Number of applications 🧮

Now you have the technical skills, and you know how to impress employers. What next?

The only remaining variable at this point is how many shots you take. In general, more applications = greater chance of success. But, you have a problem. Applications take time, and it's not as if you can't also still improve your technical and soft skills at this point. Therefore, you need to prioritise your applications and give the ones you do make the greatest chance of success.

Good quality jobs

You should already have a narrow idea of the job you're looking for, as discussed above. You also want to make sure that the prospective job is worth your time.

Many developer job listings come through recruitment agencies, and they barely even tell you anything about the job. My advice is don't waste your time on these. If you don't know what you're applying to, you can't make a good application. Personally, I found that Glassdoor Jobs and LinkedIn Jobs were good sites for better quality job adverts.

Find a job advert that you can apply to directly and has a clear, relatively short list of requirements where it sounds like the company knows what they are talking about. Ideally, they sound like they have a good company ethos or even specify that self-taught developers are welcome. You want to spend a lot of time on this application and make sure it's very personalised and as good as it can be.

If you find the job advert on a third-party website, see if the job is advertised on the company's site and apply there instead, ideally via an email address. As a general rule of thumb, the more direct to the company your application is, the better.

Of course, most job adverts won't be ideal. Sometimes you have to play the numbers game with jobs that don't seem quite as promising - they might actually turn out to be good opportunities once you get further along in the process. And even if you don't think you want the job, you should never turn down interview process experience at this stage in your development career - the practise will help you get the job you do want.

Following up

The advantage of applying very directly to the company is that you can follow up. Following up is key. An application doesn't count for much if it is ignored. But don't take it personally. Often you just need to give the employer a nudge.

If you can find the email address for the company's HR department or general enquiries, follow up your application, say a week later, asking if they received it and re-emphasising how keen you are on the opportunity. If you still get no reply, there is no harm in trying again after another week or so has passed.

Personally, I only got my current job because I followed up on my application submission with an email. If you don't ask, you don't get, and if you don't get, ask again!

Networking

Using your network is a great way to hear about good quality jobs, and being referred for a job by someone else is a great way to ensure your application isn't ignored.

Most of us aren't very comfortable with networking, but since it can help you get a job, you should give it your best shot. At the most basic level, it just means letting your family and friends, or really just as many people as possible, know that you are looking for a specific type of position.

You should also be able to find various tech events and meetups in your area (less so during the pandemic, but there should be some online events at least). These can be useful just for your general knowledge of tech and the tech industry, but with the added bonus of making connections with people. The worst that can happen is you have wasted an hour or so.

Also try to make the most of sites like LinkedIn and Twitter for making connections - you never know how it might pay off, so it's worth putting a bit of work in.

The obstacles 🌩️

You should know now what you need to do to get your first developer job. But every journey has obstacles. You should be prepared for the long haul.

Articles like this one lay things out in a straightforward way, but the journey of learning to code is rarely straightforward and linear. Inefficiency is inevitable, especially if you are completely self-taught. You'll sometimes try to learn something at the wrong time and not succeed. You'll 'waste' time on silly mistakes or trying to get something set up that should have been simple. You'll seem to 'fail' countless times and probably feel 'not cut out for this'.

I can't tell you what other global or personal calamities or inconveniences might befall you along your journey. You probably won't have any control over them, and you'll almost certainly experience certain 'negative' emotions in response.

Luckily, there is usually something you can do about your internal world. You can train your mindset and responses to the emotional challenges of a big task like this one. The key here is that you've made a commitment to achieving the goal, and to continuing with the actions you need to do until you succeed, whenever that may be. Your secret weapons: vision, habit and persistence, can see you through.

Of course, it's much easier to give up and say 'I'm no good'. It's your brain's defence mechanism against having to do hard and challenging things. But there's no use in letting one bad day turn into two. You have to get up the next day and try again. Because eventually you'll see that "I'm no good" was never the reality of the situation. The reality was: "this is a learning process".

Overwhelm and stress

Programming for modern computers dates back to the 1950s and the technology has developed and changed at breakneck speed since then. Even in the field of web development, which is under 30 years old, enough technology has developed that you could spend a lifetime learning it.

The fact that most of the information (and misinformation) on this, plus millions of people's thoughts and opinions on it, is all on the web, unfiltered, for you to find with a simple google search, can be just as much a curse as a blessing.

You will encounter more information than you've ever found on a topic before, and more topics than you ever imagined there would be. It's natural to be daunted by the sheer amount of information, and the content of it, especially when much of it is aimed at more experienced developers and uses a lot of terminology you don't understand.

Combine this with the pressure and difficulties of building new habits, job-seeking, the interview process and any time and financial pressures you have, and you have a recipe for potential stress, overwhelm and burnout.

The best thing you can do is just try to look after yourself, listen to your needs, take breaks, keep doing things you like, try to stay healthy, and exercise. Not ground-breaking advice, but sensible nonetheless. You will get to the end of the path in your own time, and it will be worth it.

I can also give you a few words of comfort as you start out on your journey:

• You will find good teachers and resources that explain things in terms you can understand, and make you feel at home in the world of development. You will also find friendly and welcoming people in the development community that want to help and mentor you, if you look for them.
• If you accept that there will always be a vast amount of things that you don't know in development, but find your own corners of knowledge that you can master and feel comfortable in, you'll be happier.
• When you do finally find yourself in the right developer job, a lot of the pressure will be relieved, and you'll be able to enjoy the fruits of your labour, safe in the knowledge that despite all the obstacles, you finally made it!

Thanks for reading, and feel free to contact me here or via Twitter if you have a question about this that I haven't covered here 🙂

Sources

Some of the tips on habit are derived from information in The Power of Habit by Charles Duhigg (Random House, 2012) and The Chimp Paradox by Prof Steve Peters (Vermilion, 2012).

The idea that you lose willpower as the day goes on is known as ego depletion and various studies have shown this effect, though the exact causes and nature of the effect are still up for debate. This article provides a good overview:

• What Is Ego Depletion? - verywellmind

The information on learning science comes from the book How We Learn by Benedict Carey (Macmillan, 2014). But I've included some online articles on the relevant topics here if you want to explore the ideas further:

• Desirable Difficulties in the Classroom - Psychology Today
• Desirable difficulty - Wikipedia
• Forgetting Helps You Remember: Why Spaced Learning Works - Learning Solutions
• The Interleaving Effect: Mixing It Up Boosts Learning - Scientific American