So, you finished your bootcamp. You learned to code, built some apps, and practiced coding interviews. You were told you would now be an employable junior developer, ready to start your job search.
But things didn't quite work out that way.
Maybe you made it to a phone screen, but were told you were just too junior for what they were looking for.
Or perhaps you were invited for some in-person interviews, where you showed the interviewers your projects only to be met with unimpressed expressions—or tried but failed to solve a coding challenge on a whiteboard, while they stared on awkwardly.
But most likely, you've sent a whole lot of applications out into the ether of the online job portal, and heard a deafening silence back.
Bootcamps love to massage the data in any way they can to make their hiring stats look impressive.
But in 2018, Stack Overflow's Developer Survey asked bootcamp grads how long it took them to find a job. The response? Nearly 30% of those with the goal of a career change didn't find work in the 6 months following graduation.
A 2016 Bloomberg article suggested something even more concerning. From Google’s director of education and university relations:
Most graduates from these [bootcamp] programs are not quite prepared for software engineering roles at Google without additional training or previous programming roles in the industry.
Sadly, as you may have experienced yourself, this sentiment is not unique to Google.
After struggling through the process of getting my first job after a bootcamp, I eventually realized my problem: The Post-Bootcamp Skill Gap.
What is The Post-Bootcamp Skill Gap?
If you're unemployed after a coding bootcamp, you're not alone. You've had a fast-paced introduction to a lot of different topics, but you'll need to put in some extra work to develop the depth of skill, knowledge and experience that most employers are looking for.
This is why the vast majority of people who do find work quickly already had significant programming experience—sometimes even professionally—before they started the bootcamp.
But don't lose hope just yet.
Back in 2013, I was in exactly this situation.
I'd graduated from a bootcamp, but I was terrified of interviews. I couldn't code well enough to solve even basic technical challenges. One bad experience after another, I received more rejections than I can even remember. I began to realize that I was a long, long way from what anyone was looking to hire.
Fast forward 7 years, and I'm happy to say I'm now a senior software engineer at a successful company in San Francisco. My skills improved, and I eventually figured out how to pass technical interviews (yep, there's a technique to it).
I've also had the chance to interview a lot of other engineers, so I know what companies are actually looking for.
And I know that finding a job after a bootcamp is possible (even though I know it doesn't feel like it at the time).
So if you're in this situation right now and struggling, this guide is for you.
It's a series of actionable steps you can take, to bridge the gap and grow the extra skills you need to actually get a job.
In this guide
- Learn computer science fundamentals... properly
- Build some more unusual projects
- Practice interview coding
- Decenter the bootcamp in your story
- Make a small number of focused applications
1. Learn computer science fundamentals... properly
Most coding bootcamps focus on teaching practical industry skills, which essentially means learning to build web apps using current popular frameworks. And that makes sense, as it is what a lot of day-to-day industry software development looks like.
They may claim to also teach computer science, but it's a different beast.
Unfortunately, if the only computer science you've ever studied was during your bootcamp, there's a 99% chance it's not going to be enough. I know because I was one of those people (my bootcamp included a whole week of CS).
Do I really need to learn CS theory?
While you might not use the fundamentals directly very much in a job, to get the job at all, you need to pass the interview.
And many companies structure their interview processes (particularly for entry-level roles) around recent Computer Science graduates.
You may be familiar with some of the infamous algorithm-style interview questions. There's actually a fair amount of evidence that this style of interviewing isn't an effective way of hiring good engineers by now, and a lot of companies have (thankfully) started to eschew it in favor of more real-world problems.
But change takes time, and of course you can still find companies who will ask you these kinds of questions.
I've seen advice along the lines of: "don't waste your time learning that stuff, if a company interviews like that then you don't want to work there anyway."
And while that may be true, I personally think it's still worth taking the time to learn CS fundamentals, for two reasons:
- If you're in an interview and you do happen to get a question that requires some CS knowledge, what would you rather do: freeze on the spot and have no idea where to even start, or at least be able to make an attempt?
- Learning this way of thinking will actually make you a better programmer—even if you never have to reverse a binary tree for the rest of your tech career.
Computer science fundamentals resources
These are the resources that finally helped me learn what I needed to know:
CS50 is a fun and engaging introduction to the topic, suitable for complete beginners. It uses C as a teaching language, plus some web languages you may be more familiar with.
It's the first course in Coursera's Data Structures and Algorithms Specialization. You could do the whole specialization if you have time and find you enjoy it, but I found the first course to be enough.
If you don't have a STEM background, you may find some of the reason you're struggling is that you just haven't had enough exposure to what I like to call 'thinking in puzzles'.
There are certain logic-based problems that require you to think about things in different ways. When you figure this out, you'll start to spot patterns, and a certain class of programming problem will become a lot easier.
2. Build some more unusual projects
All bootcamps will tell you that a portfolio is important. And they're right, so they will have you build projects.
But there are a couple of problems with bootcamp projects.
What's wrong with my bootcamp projects?
Firstly, I don't know about you, but mine were not exactly well-crafted examples of work I felt proud of. I'd honestly just thrown a bunch of technologies together because I'd been told to, without really understanding how most of them worked.
Your app might function, but maybe the front end looks bad because you hadn't really figured out CSS yet. Or you didn't really understand the concept of unit testing well enough to know where to start, so you just didn't write any tests.
When you're just learning about all these things for the first time, and then have to rush out a full-stack app in a week, let's just say it's not going to be your greatest work.
Secondly, you're probably already aware, but you're not the only bootcamp grad currently looking for their first job.
And those other bootcamp grads? They all learned exactly the same things, in the same way, and to the same level as you. So if your projects look just like that of every other bootcamp grad out there, it's going to be hard to stand out.
This is all to say that if you're relying solely on your bootcamp projects during your job search, you're making things harder for yourself.
What else should I build?
One thing I wish I'd realized sooner is that not everything has to be a full-stack web app.
I actually started to learn a lot more when I began to work on smaller, more focused projects after I'd finished the bootcamp.
This was also useful because I could finish things quicker, and get a sense of satisfaction from having completed a project, rather than feel like I was stuck on multiple different areas of some huge project for weeks. (Larger projects are important too, of course, but feeling like I was moving forward and making progress was helpful for me at this stage.)
Projects also don't have to be serious, or useful (you're learning to code, not preparing to pitch a VC), so don't get hung up on this. They can be small, silly, funny, pointless...
Obviously you'll have to figure out what kind of projects interest you. But my advice is to think of projects you would actually have fun building, or feel really good about, or be proud sharing, and then figure out what you need to do to build them.
Don't worry about how many technologies you're checking off a list; just think about what you need to solve that one problem and go from there (after all, there's no better way to learn what a particular tool is for than to realize you actually need it).
For any projects you include in your portfolio, make sure you understand them inside out. Be ready to talk in interviews about why you picked certain technologies or approached something in a certain way, what trade-offs you made, and what you would do differently if you were to start again today.
Portfolio project ideas that will make you stand out
- Contribute to a large open source project: New developers are often intimidated by the thought of this, but many projects are friendly towards newcomers—Node.js and Mozilla make particular efforts around this. There are so many benefits too: you'll get to interact with top industry developers, get experience contributing to large, complex codebases, and learn how to write production-grade code. (Plus, being able to write 'Node.js Core contributor' on your resume looks really good.)
- Build something with hardware: Get a Raspberry Pi or Arduino and build something for your home: maybe a color-changing lamp, or a device to water your plants automatically. These kinds of projects won't be directly relevant to a web engineering role, but they do demonstrate willingness to step outside your comfort zone, and companies love to see that you have drive and curiosity to solve problems using a whole range of different tools.
3. Practice interview coding
So, your computer science basics are now solid. You understand the difference between a graph, a tree and a linked list, and can talk about algorithms in terms of big O notation.
You've also now built some interesting and unique projects, showcasing different aspects of your personality, creativity, and skill set. And these aren't just things you rushed to get done in a week—you can tell an engaging story about them, from concept to finished product, including some fascinating things you learned along the way.
But now it's time to make sure you can show off your skills in interviews.
Why do I have to practice interviews?
The truth is that technical interviewing is a skill in itself. And like any skill, it has to be studied, learned and practiced. You could have really valuable technical experience, but if you can't demonstrate it well at interview, you're not going to get the job.
I do want to mention that I'm not saying this is a good thing. Many companies are starting to realize that their interview processes are far from perfect, and are looking for ways to make them more reliable and equitable. Once you're working for a company, by all means get involved and help to fix this system from the inside. But while you're job-hunting, it's helpful to learn to play the game.
Your bootcamp probably gave you some idea of what to expect in a coding interview. Maybe you did some practice questions in groups, or a full mock interview with a whiteboard.
This part of the guide is basically about doing all these things, but a lot more.
You want to get so comfortable solving coding challenges—in all kinds of environments—that it feels natural to you. Then, when you're in the high-pressure environment of your real interviews, you'll be able to focus totally on the problem, and not how weird it feels to be writing curly brackets on a whiteboard.
Resources for interview practice
The main environments you'll be asked to program in are:
- A text editor on your own laptop (hopefully this is already comfortable for you)
- A shared online IDE like Coderpad
- A timed online environment like HackerRank
- A physical whiteboard
You should practice in all of these. If you find one particularly challenging, spend the most time practicing it.
If you don't have a whiteboard at home already, you can get home office ones that are big enough to write code on, but small enough to store easily. I have this 24 x 18" one from Amazon, that comes with a magnetic dry eraser and 2 marker pens. You can hang it on a wall, but I just tuck mine away behind my couch when I'm not using it.
Where can you find practice questions? Honestly, there are thousands freely available on the internet. Here are some popular sites to get you started:
When you're comfortably solving problems on your own, find another person to practice in front of (it does add more pressure when someone's watching you code).
If you have a technical friend or family member who is willing to help out, great! If not, interviewing.io is a service that offers practice anonymous mock interviews. You can practice with other members for free, or pay to practice with industry engineers.
4. Decenter the bootcamp in your story
Every year, more and more people attend coding bootcamps. That means increasing numbers of bootcamp grads in the market for a job, and more competition for you.
I'm not saying this increased competition means you should give up; if it did, I wouldn't have written this guide. It is still possible for you to find a job. What it does mean is that the bar to stand out is higher.
If you've done everything I've suggested so far, you've already done more than the majority of bootcamp grads you'll be up against. But getting your story on point is another step you should take, and that's what this section is about.
Story? What do you mean?
If you've had any interviews so far, you may have noticed that they almost always start with some variant of the ice-breaker: "so, tell me about your background."
The trick to this is to prepare a short blurb ahead of time. This is for a couple of reasons:
- You want to make sure it's the right length. Too short and you're wasting an opportunity to make a good first impression. But go off for 15 minutes in far too much detail, and you'll seem scattered and unfocused (a lot of people have this problem when they're nervous).
- Once you've had a few interviews and answered this question a few times, you'll get so used to saying your blurb that you'll start every interview with a familiar, comfortable mindset. This can help you relax, which is always useful in an otherwise stressful situation.
What should I include in my story?
A problem I've seen while interviewing recent bootcamp grads is that they lean too heavily on the bootcamp part of their experience.
Their story will go something like this:
"I wanted to learn to code because I did a little bit of it at [other job] and really enjoyed it. That's when I applied to [bootcamp]. I learned [tech stack] at [bootcamp] and these are the three projects that I built there. Now I'm looking for a role where I can learn from senior engineers."
Sadly, employers have now heard this same story hundreds of times. What is there to differentiate this candidate from any other bootcamp grad?
In some of the discussion around companies' negative reaction to bootcamps, I've seen people ask if they should even just leave the bootcamp off their resume entirely.
I don't advise trying to hide the fact you did a bootcamp, because that'll just look weird and deceptive if the company ever finds out. And I don't think, in most cases, that merely having done a bootcamp will count against you.
What you should do is use your story to frame the bootcamp as just one part of your learning.
If you've taken the time to learn computer science fundamentals on your own, get some interesting projects in your portfolio, and really solidify and build on the skills you just scratched the surface of in your bootcamp, your story could sound more like this:
"I wanted to learn to code because I did a little bit of it at [other job] and really enjoyed it. I then attended [bootcamp] which was a great introduction, but since then I've continued to teach myself through online courses and independent projects. I've gained experience contributing to [large open source project] where I worked on [some feature], and I also wrote [app] to solve [real problem]. As demonstrated in [project/experience], I'm particularly interested in [something relevant to company], so I'm excited to learn more about opportunities on your team."
By diverting attention away from the bootcamp and focusing more on your other achievements, you'll come across as more memorable and unique, and avoid getting put in the 'just another bootcamp grad' bucket.
5. Make a small number of focused applications
By this point, you've got the skills not only to ace a technical interview, but also to present yourself in a memorable, engaging way so you can get past the first stages of the interview process. You're finally ready to start applying for jobs.
Shouldn't I apply to as many places as possible?
Many bootcamp grads know to expect a tough time finding their first role, so they go for quantity. They send out hundreds and hundreds of applications, spamming job portals and just applying to anything and everything they can find.
This approach rarely works (for anyone actually, but especially someone looking for their first role).
In my experience, you're better off taking the time to carefully research and apply to no more than a few companies at once.
Why? Companies want to hear that you're specifically interested in them, and the problems they're solving. It's just not possible to research hundreds of companies in the kind of depth you need to, all at the same time.
I know you probably feel pretty desperate at this stage—and your actual criteria for finding a company is more like 'anyone who'll give me a job'—but the trick is to never come across like this. Find some aspect of their product that's actually interesting to you (preferably that you've used), or some technology in their stack that you'd really like to work more with.
You should always have backup options in case no companies in your initial list work out, but don't sacrifice the quality of your applications by taking a scattershot approach.
What if companies just ignore me?
The hardest part of an entry-level job search can sometimes be getting a company to speak to you at all.
Networking and how to pick the right companies to target is a broad topic outside the scope of this guide, but I will say that, as a bootcamp grad, you'll have greater success if you can form personal connections with people than if you submit a cold application through a website.
Once you have a shortlist of companies (with reasons why you're interested in each), it's time to see if you have any contacts in your network at these companies. If not, reaching out to one of their recruiters directly on LinkedIn is a good way to start a conversation. They will at least be able to give you a sense of whether there is suitable role available.
Tips for a successful job search
- Have a goal or direction: You don't have to be a specialist yet, but you should have an idea of what kind of role you're looking for (front end, back end, startup, larger company etc.). Show how you're working towards this goal, and how the company fits into this plan.
- Make a shortlist of companies you have genuine interest in: Targeting companies in an industry related to the role you had before can be a good way to do this (e.g. if you were previously in finance, fintech would be a natural fit).
- Use personal connections instead of cold applications: Build your network by going to meetups or being active in online communities. Use LinkedIn to your advantage.