You’ve just graduated Hack Reactor, or App Academy, or Galvanize, or some other programming bootcamp. You’ve got two or three group projects on your Github, maybe a solo project. You’ve got a resume in hand and some sort of job search coach pestering you weekly. You’re getting all sorts of advice on how to go about your job search: Focus on sending resumes. Focus on personal projects. Only do leetcode problems. Don’t bother sending resumes, only use warm leads. I remember this time as one of the most confusing of my life. How could there be so many different ways to go about this deceivingly simple task of Getting A Job?

I’m going to add my voice to that mix. I’m going to lay out as clearly as possible exactly what I did to get a job when I graduated from a bootcamp, and temper that experience with the new knowledge I’ve acquired from four years as a software engineer, often in a hiring position. I’m going to share what I learned from several years as a recruiter. I’m going to guide you as I guide Hack Reactor grads that I am a mentor to, working off questions I often get from my mentees, people in the audience at alumni panels, and from emails I get from random students that find my email. And at the very end, I’m going to invite you to email me questions about anything that didn’t seem clear to you.

The goal of this post is to give you a very broad overview of what, in general, a recent coding bootcamp grad should be doing to get a good job quickly.

Handling offers and other late-stage-job-search topics won’t be covered.

This process is not guaranteed, universal, applicable to all people, or applicable to all cities, states, or countries. Use it to help guide yourself in deciding what you should be doing day to day from now until you get a job. Good luck.

If you want to know my first job hunting experience as a bootcamp grad, I wrote an article back then about it: How This Coding Bootcamp Grad Found a Job

Index

The Tasks

I believe the coding bootcamp graduate’s job search can be broken down into four core tasks they should be balancing. Below I will list them, with the percent of your “core working hours” time I think they should be taking.

  1. Working on projects: 30%
  2. Practicing coding challenges: 20%
  3. Submitting resumes 40%
  4. Studying 10%

Each of the above items is a link into a detailed breakdown of what each task is and why it should take the above given percentage of your time.

The Schedule

A common question: “How much time a day should I be job searching?”

The answer is quite simple: The more time you spend on this process, the sooner you’ll get a job.

I typically advise Hack Reactor graduates to stick to the same schedule they had at the bootcamp until they get a job: 8am to 8pm Monday through Friday, 8am to 5pm on Saturday, with Sunday as a full time break. I advise them to continue to take an hour lunch and dinner break every day, with a 2 hour break Monday, Wednesday, Friday, during which they should do a heavy workout.

This is a very intense schedule. It’s important to stick to it, because I imagine the programming bootcamp was one of the most focused and productive periods of your life, and you can leverage this momentum to get you a job more quickly.

Momentum is important to keep up because it will be damaged by the excruciating process of the job search, so the more momentum you have at the start, the more resistant to motivational damage you are.

I have seen many coding bootcamp grads “take a week off” or “take it easy” immediately after the programming bootcamp. Invariably these students take the longest of their cohort to find a job.

If you have the means, I recommend avoiding get a part time job, even if it means going into debt. I’ve seen many students turn a post-bootcamp part time job into a permanent job because of how hard it is to maintain a job search while working.

The longer you take to get a job, the bigger your employment gap becomes, and the more unattractive you become as a candidate. This sucks, and is a good reason to maintain a high velocity and get a job as soon as possible. Plus, your skills will become rustier the longer you spend outside a full time programming environment.

If you absolutely must maintain a part time job to fend for yourself, I advise still sticking to the above mentioned percentage breakdowns of tasks, and fill all available time with job search activities. This will be monumentally difficult and you’ll probably have a harder time than anybody in your cohort in finding a job.

The Personal Project

Working on projects should take 30% of your job searching time.

Your job, when you do get one, will be to make applications for a company that either directly makes money for that company or somehow adds value. Thus, one of the most important things you can demonstrate to prospective employers is that you are capable today of developing applications that make money or add value.

Your coding bootcamp projects are a good start, but are insufficient by themselves for your job search. Their repositories are probably owned by an organization on Github, and thus aren’t immediately visible on your Github profile page. You may have been pair programming for many of the commits, and thus your personal Github account might look sparse in the commit history of the project. Finally, a group project is strength in numbers. When I look at a bootcamp group project, I have no way of determining who actually did the heavy lifting, especially if it’s from a bootcamp that I don’t know the fail rate for (I can be confident, for example, that Hack Reactor will likely boot someone not pulling their weight on a group project).

Following the bootcamp, you need to be creating new personal projects, preferably numerous ones that you work on almost every single day throughout the entire job search.

There are multiple reasons for this.

Projects Show That You Can Make Someone Money

As above, your primary objective is to demonstrate your ability to make someone else money. Given the jobs you’re applying for, the best way to do this is simply show off that you can make them money day one with a vibrant portfolio.

Projects Give Proof to Your Skillset

When I was a recruiter, and today when I look at resumes, I completely ignore “skills” sections. I know that skills sections only exist to allow non-technical recruiters check off boxes on a job description before sending it up the line. I know that the secondary purpose of a skills section is to make the resume more likely to be picked up on a text search.

If I want to know if someone knows Vue, I look for projects that use Vue. If I don’t see one, I have no evidence that the candidate knows Vue, so if they tell me they do (in the skills section or in a pre-phone interview stage), I’m skeptical.

You don’t want hiring managers to be skeptical. You want to have a project right there on your resume or personal website that uses Vue, with lots of commits by you, that unequivocally sends the message “I know how to use this framework, and I can use it today to make an app for you. As you can see, I’ve done so already.”

Projects Hone, and Teach New, Skills

At the beginning of your career, your engineering skills are tenuous. Give it a few months and you’ll find many things you were quite confident in at the end of the bootcamp have floated into a memory void. You want to avoid this by working almost daily to solidify everything you’ve learned.

I can tell when a candidate in an interview is just namedropping technologies they skimmed at a bootcamp. If I try to delve into nitty gritty details, they’ll flounder. If you regularly use the skills you learned, you’ll hone them, picking up subtleties you can’t possibly learn without regularly using these tools.

Projects also represent an opportunity to learn new skills. Typically I recommend bootcamp grads pick a framework and stick with it for the entirety of their job search, but projects allow you to pick up smaller technologies such as a new database technology, some new cloud tool or platform, a new testing framework, or an API. In What to Build, I’ll give some examples.

Projects Give You Interview Topics

My favorite thing to talk about in an interview is someone’s project. It gives them the opportunity to show off their chops with code we can look at right then and there, unlike work projects which use proprietary code we can’t look at. If the project is a solo enterprise, it gives me insight into what a given engineer thinks is important, how they manage a product when it’s entirely their responsibility, how organized they are, how much they ACTUALLY care about commit cleansliness or testing, and a myriad of other aspects of the engineer’s programming personality.

When I did my job searches, 90% of my interviews involved talking about my personal projects. This is because the majority of people are bad at giving interviews and the personal project is an easy thing for them to latch onto. This is advantageous to you: it gives you a huge amount of control over the interview. You can talk through prepared statements regarding why you made certain decisions, what you know about the technologies you chose, and what you want to do with the app in the future.

Below are some personal project tips and how-tos.

What to Build

A classic question I get at literally every alumni panel I’ve gone to: what should you build?

Consider that the purpose of personal projects (for now) are to hone your current skills, learn new ones, and show proof that you can make someone money. Bear this in mind when thinking about what to build.

Thus a great project is to duplicate an entire existent application or service, from scratch. Instagram is a great example. It will take a long time, but if you built Instagram from scratch, you’d learn:

  • Mobile vs Desktop CSS
  • Hardcore Framework of Choice Skills
  • How to host an app’s database
  • How to serve an app’s frontend
  • How to host an app’s server
  • How to make your app accessible by a URL

At a minimum. Who cares that it’s already been done? If a candidate walked into an interview with a fully deployed and functional Instagram clone, how could I possibly doubt their skills to make my company money?

It’s important to acknowledge that an above example would take months to do properly. That doesn’t mean you shouldn’t deploy until it’s “done.” A work in progress is also great to talk about.

Beyond a massive copy-cat project like the above, you could also build some small one-off projects as a study in a given technology. For example, I built Soft But What Word Count to learn how to talk to Google BigQuery for a project at work. Now if somebody wanted to know if used BigQuery before, I can just point to that link. You could do this to learn a framework, an API, a testing suite, a build process (i.e. using Make instead of Gulp), or whatever you can think of.

How to Show Off What You’ve Built

If you go through the effort of building a project, you should ensure this work is helping your job search process. It’s madness the number of resumes I get that list a project without a link to a deployment, let alone a Github link. How does that help show off your chops?

Your projects should all be deployed. They should be accessible via the internet via a URL. That URL should be easily tapped out in a phone.

I typically host my projects on AWS or Google App Engine. That gives them some fucky long URL like https://bigquery-test-243517.appspot.com/ . So, in Bluehost (which manages my domain calebjay.com), I set up domain forwarding for a url like www.calebjay.com/softbutwhatwordcount, so it looks good on my resume or when I pop it into the URL on a hiring manager’s computer. I haven’t yet figured out how to actually get that URL to display in the address bar when on that app, which is embarrassing, but at least I have a redirect set up.

Make sure that the URL is typed out directly on your resume. You can’t click hyperlinks on printed paper.

Your projects should have publicly accessible code. Generally this means they should be hosted on your Github. If it’s a group project hosted on a different organization, fork it onto your own account so you can display it on your portfolio. Also, take advantage of Github’s “pinning” feature to select a few of your best projects to show off.

Your projects should have writeups. Be it a blog post or a dedicated page, somewhere you should talk about your project, why you made certain decisions, what technologies you used, and what your future plans are for the project. This is essentially a precursor to talking about the project in an interview and gives you further control over the narrative surrounding your project. It gives you opportunity to explain yourself and talk about why the project is important. Here’s an example of a writeup for one of my projects, and here’s an example of a blogpost for another.

By the way, if you get a take-home challenge, it’s a very good idea to submit a write-up alongside the challenge.

Also, if you get a take-home challenge, make sure to deploy it and host it on your personal website. That is your hard work and you should benefit from it. Feel free to explain it was a take-home assignment from a company, and feel free to name the company. If they want you to work for free and not share your work with the world, they can fuck themselves.

One of your projects must be a personal website. If you don’t have one of these coming out of the programming bootcamp, it’s imperative you get one out soon. It’s so strange getting resumes from self-proclaimed Web Developers that don’t have their own website. It comes off as amateurish. The website need’t be complicated: mine is plain HTML, CSS, and contains no Javascript. In fact, I advise against making a personal website very complicated. It looks a bit silly when I hit yourname.com and spend the first ten seconds loading fifteen libraries to show static content. It could be a Github Pages. It could be a Wordpress. It doesn’t matter, so long as you have a slice of internet that’s yours. It’s a honeypot of everything that represents your skills: links to your projects, links to your Github, photos you took, art you drew, whatever.

A personal website is your front page. It’s your space to show off exactly who you are and what you’re about. It’s a sandbox for you to play with the internet. It’s a place to show off all your hard work, organized in a way that show what is important to you. You absolutely must have a personal website. It demonstrates that you have at the very least the bare minimum of skills I’d expect a Web Developer (a catch-all phrase that includes frontend, backend, and fullstack engineers) to have.

The Coding Challenge

Working on coding challenges should take 20% of your time.

By coding challenges, I mean things like Leetcode, Project Euler, and working through Cracking the Coding Interview. I also include live practice interviews on a whiteboard under this umbrella.

Bootcamp grads often spend the majority of their time working on these, and I’m not exactly clear why. I suspect it has something to do with viewing the interview process as something that it isn’t, i.e. as a sort of coding challenge in and of itself, or an arbitrary barrier between the candidate and the job. Sometimes this is true, because most companies are really bad at hiring and interviewing, but it’s important to remember that the purpose of interviews is to figure out if you’re capable of making money for the company, quickly. Whiteboard challenges are a pretty terrible way to do that, but not every company has figured this out yet.

In any case, you will still get arbitrary bullshit programming problems like n-queens or Roman Numerals or whatever random crap pops into an uncertified interviewer’s head between the door to the meeting room and the chair at the table, so you do need to be prepared for these. Plus, these kinds of problems do tend to help grow your engineering and problem solving mindset.

How to Do a Coding Challenge

Note that instead of reading this entire section, you could instead go read Cracking the Coding Interview, which I highly recommend over any other form of programming challenges such as Leetcode, Hackerrank, or Project Euler.

The first step to a coding challenge is to close your laptop and pull out a notebook and pencil. This emulates the environment in which you’ll be doing a programming challenge: the whiteboard. I’m pulling this advice straight out of Cracking the Coding Interview. This will massively improve your psuedocode ability. Focus on writing quickly but with neat handwriting, and write enough detail that your code can easily be transferred to a computer and run, as this is what companies like Google do immediately after your interview.

Use the pencil and paper to solve the problem, writing out your entire programming solution. When you have a solution, point out the potential downsides of your solution. Write what the time complexity is and justify this with math. Then, if you can, write a second solution, ideally a better one, or at the very least one that has a different time complexity. Talk about the benefits and drawbacks of each, i.e. one might be faster but use more memory. At some point, pretend you’re an interpreter and “run” the program line by line. Check the first and last case of loops and recursive functions. After you’ve done all of this, type your code into a computer, noting any errors you made. Run it, see what bugs there are. Remember this, and focus on avoiding these kinds of bugs in the future.

Instead of arbitrary algorithm implementation, consider implementing domain knowledge. If you’re trying to become employed as a web developer, see if you can implement Promises in vanilla Javascript. See if you can implement setInterval using only setTimeout. See how much of the lodash library you can implement from scratch in vanilla Javascript. See how much of jquery you can implement from scratch.

If you are going to do arbitrary algorithm implementation, focus on actually useful ones like sorts and data structures, rather than doing, I dunno, “Convert Number To Roman Numeral.”

Finally, again, before doing anything else, I recommend just working through the entire Cracking the Coding Interview book.

The Resume Send

Submitting resumes should take 40% of your time.

The job search is best aided by increasing your surface area. By surface area, I mean the amount of people and companies that are aware that you’re available for a job. If they don’t know, they won’t hire you. This is why I consider the resume send to be the highest priority job search activity.

This is also why I advise the “resume blitz” strategy of job search. Often in an alumni panel I’ll come up in a head to head with another alumni advising a “slower” or more “considered” approach, or one that advises entirely focusing on warm leads. I don’t reject these methods outright. I believe they’re an important part of any job searching strategy. However, I still believe getting as many resumes out as possible is the best strategy.

One of the most difficult parts of the job search is dealing with rejection. You’ll spend weeks invested in the process of falling in love with a company, only to have them crush your dreams in a single email if you’re lucky or, if you’re really lucky, an actual phone call. Many times they will simply ghost you. If you’ve sent out 50 applications, that pain is quite focused. Each rejection represents a tremendous amount of effort “wasted.” However, if you devise a strategy of resume sending that expects at the very least 200 resume sends before employment, rejection becomes just a matter of course. It hurts less.

Other reasons for choosing a blitz strategy will be detailed below.

When to Start Sending Resumes

You should begin sending resumes the day after you graduate from your bootcamp, and you shouldn’t stop sending resumes at the volume indicated below until you and an employer have both signed an employment agreement.

The entire recruitment process, from resume send to offer, can take a month or more. If you get to the interview stage at 4 weeks in and then get rejected, and haven’t been sending resumes in the meantime, you essentially have to “start over” your entire job search. This is a crippling setback from the already emotionally draining rejection. Don’t do this to yourself. Send resumes immediately, and continue to send them every single day, even when you’re at offer stage.

In recruitment, we called this “spinning plates.” You want work happening in the background for you, while you do other things. When you send a resume, it slowly makes its way up the stack on a recruiter’s desk. While you wait for a phone call, your other resumes are being passed around various managers, who are deciding to schedule an interview. While you sit in an interview, other companies are looking at your resume and deciding if they want to call you. The more of this work happening at once, the better.

Crafting a Good Resume

Your bootcamp should have prepped you for this, and I don’t want to get into this too much here because there’s way better articles on the subject, but in general, your resume should:

Be easily found by search tools. This means having your skills listen en masse somewhere on it, such as a skills section. Apply other SEO concepts such as rewording various skills in many places across your resume. Notice how I have been switching between “coding bootcamp,” “programming bootcamp,” and namedropping bootcamps directly? That’s because I’m covering my SEO keyword ground. Do that for CSS, Javascript, SQL etc. Use ES5, ES6, Ecmascript, etc, throughout the resume or at the very least in the Skills section.

Clearly demonstrate what technology you’ve used. If you list a project or work experience, list out clearly what you used on that project. I.e. “Built a Frontend in Vue for displaying children’s books. The data was pulled from Firebase, which we used because we needed to quickly get a deployment up.”

Link directly to your projects. If you have a project on your resume, put a link to the Github page for it as well as the deployment. The link should be typed out entirely, not just a hyperlink.

How Many Resumes to Send

You should send fifteen to twenty resumes a day and adopt the mindset that it will probably take 200 resume sends at minimum to get a job.

The basic math is as follow:

  • Ten resumes gets you a phone call
  • Five phone calls gets you an onsite interview
  • Five onsite interviews gets you an offer
  • One in three offers will be an acceptable package

Should You Write Cover Letters

Yes, you should. It can only help, therefore it’s required. If it’s 50/50 whether it’s any good, and you don’t send a cover letter on every submission, that instantly invalidates 50% of your work.

That being said, a cover letter shouldn’t take more than 2 minutes of your time per submission. At first this will be impossible because you’ll be writing cover letters from scratch. But as you write more and more cover letters, you can copy and paste sentences between them. If one company wants React, you can copy a line talking about your React experience. If one company is in an industry you’ve worked in, you can copy a line from a submission to a similar company.

While you should get your cover letters out quickly. they must be tailored for each company. I get annoyed by obvious form cover letters. Cut all of the crap out and get just a single paragraph in about why you think you can make the given company money and why you’re excited for the opportunity to do so. Just chop out that intro “dear hiring manager, I’m excited blah blah” portion, and nix the “in conclusion, I look forward waaah” bit off the end. Hit the company website, look it up on crunchbase, drop a few sentences, and move on.

Below is the verbatim cover letter that got me my first job at Electric Imp.

Hiring team of Electric Imp,

I read that Electric Imp has recently reached over 20 million in series C funding, which is awesome news! I would guess that things are getting more exciting every day in the offices, and I’d be interested in speaking directly and learning more about your needs. In particular, I found your job posting on Linkedin, and I believe that I am a good fit for the position of Front-end UI Developer.

I’m currently a Software Engineer and Fellow at Makersquare/Hack Reactor. Day to day, I teach advanced Javascript and web technologies such as Node, Angular, React, and etc to junior Software Engineers. I have excellent command of Javascript, HTML5, and CSS, and am confident Electric Imp would find me an asset in that regard. I also have a great deal of experience in Bootstrap, Node, and UX development. I’m very familiar with event-driven applications, an example of which can be found at https://langbattle.herokuapp.com/#/home.

For further examples of my work, I invite you to visit my github at github.com/komali2 or check out my linkedin page at linkedin.com/in/calebjrogers. My portfolio is available at calebjay.com/portfolio.html.

I look forward to discussing the Front-end UI Developer position further with your team.

Warm Regards,

Caleb Jay Rogers

Notice that I name drop directly technologies I saw in the job description (which sadly I no longer have).

Warm Leads

A lot of people have this boomer mindset of “nothing better than a strong handshake from a friend to get your foot in the door” or whatever. Maybe I’m so skeptical of this because I knew literally nobody when I first came to San Francisco for Hack Reactor. Apparently it’s working for some people.

So, common question: Should I send my resume to my warm leads right after graduation, or wait until I’ve had more interview experience? Send them right away. If the company actually wants to interview you, you’ll almost assuredly be able to push back the interview date if you need to. I went through the interview process at Google and had a traumatic emergency first aid experience halfway through, leading me to request pushing back the interview nearly 3 months. They accepted without hesitation.

Probably it’ll take nearly a month for the company to even call you back. So, get the resume out as soon as possible.

Also, try to grab coffee with one random person off LinkedIn once every two weeks. Explicitly don’t try to get a job with this person, it’s annoying and probably won’t work anyway. If they want to recommend you for a job they’ll probably tell you. Treat it as an opportunity to learn more about Talking the Talk. You likely have never done the Engineering Day To Day. This will be obvious to your interviewers. Getting firsthand conversations about what the job is like from other engineers will make you come off as more seasoned.

Finding People to Send Resumes To

I sent the majority of my resumes over:

I’ve heard good things about Stackoverflow jobs, especially for remote work, but it seems in general they’re looking for more experienced engineers.

As for services like Triplebyte, go for it, but don’t expect much. They included a bunch of embedded system, C programming type questions in my interview, despite me explicitly telling them I have no interest or experience in such things.

To help your LinkedIn application process, send out requests to the maximum number of people LinkedIn will allow you to, and accept every request that comes to you. I detail the why and how of this further in my article specifically about LinkedIn Strategies for Bootcamp Grads

Also, upload a resume that doesn’t have your phone number, but does have your email, onto Monster. You’ll get tons of irrelevant and crappy job recommendations from recruiters, but submit through them anyway. It’s a free resume send you don’t have to do the legwork on, and you might get free interview practice from it.

Finally, grab a local paper, because shockingly, people are putting web dev roles in there, and I think it’s boomers that don’t know how to use the internet, so you might get lucky and be the only candidate sending a resume in to a position nobody else knows about.

General Networking

Networking can help, but I disagree that it should be the primary method of job hunting, as some other alumni claim.

I often get asked if as a new bootcamp grad, one should attend meetups, and if so how often, and also which ones.

I never had success with job leads through meetups. I had one job lead through a conference, once. A man had a phone case that looked like a giant rubber duck in his back pocket, so I asked if I could take a picture of his ass for my girlfriend at the time who loved ducks. He thought this was funny and a conversation led to him asking me to send him my resume for a developer evangelist position. Nothing ever came of that. I imagine this is because every single meetup’s membership in the Bay Area is comprised of 75% job seekers, 50% of whom are recent bootcamp grads. Market’s flooded and it’s not nearly as efficient a way to increase your surface area as simply blitzing resume sends to open job recs.

Still, it’s important to get out of your house and actually talk to people, so as to prevent turning into some kind of weird LinkedIn cave troll. Therefore, I do recommend attending at least one meetup every two weeks during your job search. Ideally it’s related to programming in some way, but it could be anything really.

Use Meetup.com to find meetups. Facebook might be good too, I don’t know.

Good keywords to search for include html, javascript, node, react, vue, web, and programming.

Studying

Studying should take 10% of your time.

A broad and neglected topic for bootcamp grads. Studying in this context generally means just reading documentation, or maybe doing a tutorial.

This is important because it can generate inspiration for new projects. It can also slowly add to your growing skillset. Having a broad range of technology skills is important to make yourself more “T” shaped.

Learning also keeps you sharp and on your toes. It helps keep alive all the fruitful little brain things that exploded awake during the bootcamp, and lets you take advantage of them throughout your job search.

Finally, Hack Reactor, App Academy, Galvanize, or whoever, didn’t teach you enough to get your first job with much ease. You must augment your education.

Studying can be as simple as reading documentation. You can have it open on a tab on your phone and read it while pooping, or sitting on the train, or in lieu of browsing Instagram or Reddit.

You won’t memorize everything you read, and that’s ok. You’ll have a brief enough knowledge on the subject to be able to say during an interview, “oh, I remember reading about that in the Node documentation, isn’t it called something like x or y? Mind if I look it up real quick?” It will decrease what you don’t know you don’t know, and increase what you know you don’t know.

Once during an interview I was asked to list all the ways you can control when a line of code will run in Node. Luckily I had read the Node documentation top to bottom on the toilet that day, and thus was aware of things like process.nextTick.

Here are some things you should study:

Take a look at my list of helpful links for more random stuff to page through.

Further Questions

This post will probably be updated quite frequently over the next few months. If you found something confusing or have something you think is important to add, please email me at caleb at calebjay.