Tips On Landing a Software Engineering Job Post-Bootcamp

I finished at Fullstack Academy in December 2018 and was on a peculiar journey upon graduating. I was enrolled in the Part-time Immersive Program, which means I was working full-time and my program lasted about seven months. Three months prior to graduation, I received an opportunity to take on a three-month contract with a Fin-tech startup to be a Google G Suite Developer. Risky as it was, all I wanted was to continue learning as a developer and to get some more industry experience to make me more marketable upon graduation. So I dove right in. I worked for three months on a contract and in December 2018, I became unemployed.

After a long bootcamp, most students would assume that the hard part is finally over. You’ve just taken a huge chunk of time in your life to learn how to code. You went from 0 to 100. You went from not knowing exactly what the hell the difference was between a Shell, CLI, and Text Editor was to knowing Node, Database Management, React, Redux, and a whole new language in Javascript. If the hard part isn’t over, then kill me now.

Like learning how to code, searching for that ever-elusive first job is a marathon, not a sprint. And it is going to simply feel like the next phase of the bootcamp after bootcamp has finally ended. Except this time, you can’t be sure when you’ll cross the finish line. After five months of job searching, I received two offers, and I eventually decided to sign with LivePerson. Keep in mind that this post is not intended to be a one-month formula. Although, I also wouldn’t be surprised if some of these tips led you to an offer within a month’s time. Here are some things I’ve learned during my process.

Catch Your Breath.

You’ve gone through a long, intensive, hyper-focused period of studying. You jammed a lot of information into your head and have successfully implemented it into projects from ideation to deployment, and MOST of the features are working. If you are anything like me, you need someone to give you permission to relax and recharge — especially if it is December and no one will be reading your applications — because you don’t only need it, you absolutely deserve it. You will need to do this periodically through your search because not everyone can be a machine. Everyone goes at their own pace, and you need to go at yours.

Don’t Do It in Isolation.

This is pretty self-explanatory, but there are two tiers to this. First, I personally believe that the best code is written in community and the best learning happens with a diversity of perspectives. Keep writing code in community. If you are working on projects, do it with friends at a coffee shop. If you are doing algorithms, pair with someone and whiteboard it as if you would in an interview. If you have a brilliant idea for a project, build them with people. You don’t always have to finish. Celebrate each other. The second tier is to continue surrounding yourself with people who care about you and believe in you. These people could be tech or non-tech folks. I would never have been able to get through any of the phases of learning to code without these essential people who pushed me past every bump on the road. You’ve heard this African proverb before but —

If you want to go fast, go alone. If you want to go far, go together.

Create a Scrum Framework Blueprint.

Once you dive back into code, you’ll be overwhelmed. Between fine-tuning your knowledge of what you already know, rounding out your projects, renovating the projects, starting new projects, creating a portfolio, practicing algorithms, developing a job-hunt rhythm, learning new technologies, and networking, it’ll be difficult to determine starting points. I did not do this from the start, but once I created a personal Scrum Framework (using Trello) on a realistic game plan and organized it in a pipeline, I was able to block out what was outside of my immediate purview.

You Don’t Know Your Projects.

I did not discover such an ineptitude with my projects, specifically group projects, until I stepped into the interview process. Chances are, you were assigned to work on certain features within your projects and spent little time touching other pieces. If you weren’t assigned to build the socket technology or the front-end data flow logic, you may not know how it works. Take some time to revisit your projects. What I did was write out a broad overview of what the major features were and the dilemmas, issues and roadblocks that my team ran into and how the business logic was eventually resolved. I sketched out what I specifically worked on and why I chose to architect it the way I did. Ask the fundamental questions of why each technology was relevant to the problems you were trying to solve.

The more fluent you are in the architecture of your projects, the easier you will be able to improvise on talking points relative to your interviewer’s questions. You’ll be met with — So, tell me about your projects or Tell me about X project — often. My initial response would be to jump to my favorite project first for question A or to jump to the features I worked on most for question B. Although this isn’t a terrible option because it’s better than being simply speechless, you are also defaulting rather than thinking dynamically. Your interviewer is throwing broad questions at you for you to showcase that you are able to perform the tasks the job description may demand. Understanding where your projects may intersect with X company’s engineering expectations will leave the strongest impression. Knowing your projects beyond what you were specifically responsible for will give you the most talking points with your interviewer.

Find a Boilerplate You’re Comfortable With, or Create One.

I learned this the hard way on my second technical assessment. After a fusillade of technical and behavioral questions with two senior engineers, I was given a prompt and 2.5 hours to build a fullstack application with as many of the features the prompt demanded. I was conditioned to think that setting up your server, database, routes, and frontend configurations — we used Webpack, Babel, and React at FSA — was good practice. At that point I was only faintly familiar with boilerplates. I defaulted to spending the next 45 minutes coding my setup because I could not afford debugging a boilerplate that I was not familiar with, and of course, something broke. I ended up spending just under two hours to finally see something on the browser. It was demoralizing. Be ready to use a boilerplate for maximum efficiency during a technical.

I came away from this looking for a boilerplate I was comfortable with and spent but a couple minutes spinning up a create-react-app for my next technical. Chances are your bootcamp may already have a couple of different out-of-the-box boilerplates for you depending on your stack, but if you wanted one that was very bare bones, you can definitely create your own. Otherwise, if you don’t mind all the extra features create-react-app gives you, it is quite easy to use.

Make Your Resume and LinkedIn Accessible.

When it comes to your resume and Linkedin profiles, those scanning them, especially recruiters, are not looking for verbosity. Rarely are they looking for your story. That is not to say they don’t want to know your story. It just means they’re not looking for it on your professional profile. Relevant links like Github and a Portfolio site (if you have one) need to be first. The technologies you use need to be accessible from most proficient to least. Your projects need to be described as concisely as possible and the stack and tech you used per project need to be listed. All the additional descriptions of how they were used can be later tackled if you get to the interview process. When it comes to your public profiles, accessibility is the highest priority.

Once I followed these steps, I received 4x more recruiter messages. I had some help from an FSA alum for proofing. Other resume tips include highlighting your professional projects over personal projects if applicable, include any relevant quantifications per project, and link clients if projects have been deployed and are currently being used. You can find my resume here as an example.

No More Cold Apps.

I spent the first couple months cold applying to any interesting LinkedIn job posting I could find. Easy Applys are very tempting because it seems to require no time at all, but it is often a poor investment. I won’t say you’ll never receive an interview from one of these cold apps, but I will tell you that I did not. I took some time to map out how my strategy changed over the course of time and the yield it produced as I slowly stopped sending out cold apps.

Job Search 2018–2019

I was primarily cold applying in December and sending out a limited amount of messages, but the yield was little to none. The small amount of interview yields you see below came from Fullstack’s Hiring Day in the beginning of December. I took a dip in January because I was overseas, but ramped up in February. Here is where my strategy took a pivot. I still sent out a decent amount of cold apps in the beginning of the month but jumped to networking either through mutual friends, alma mater connections, FSA alums, or just LinkedIn cold messaging. By the time March hit, there was barely a difference in number between my applications and my coffees because I was primarily sending out applications only to companies I had referrals for.

Number of Interviews

As you can see, the number of coffee chats steadily rises from February to April and the number of phone screens, technicals, and on-sites I received correlatively rose with the networking. I received two offers at the end of April which is when the numbers peeled off.

Source of Interviews

Although the interviews also rose with an increase of recruiters — I was getting more recruiter contacts once I revised my resume, LinkedIn, and portfolio — as you can see, most of the interviews (76%, 19 in total) I received began with networking. Even though I sent out about 64 total apps, 0% of my interviews begun with a cold apply. I had referral applications that sometimes required multiple follow ups before they were looked at, so I had little hope that my non-referral apps would get into the right hands. In short, entry level Software Engineer roles is a competitive market, especially when a role is publicly posted. Often times, 300+ applicants will be fighting for 1 role. An application sent with an internal referral vs. one without will always win out.

Establish a Rhythm.

Let’s be real, bootcamp does not exactly end when you graduate. The job hunt is simply the next phase. And this phase is often times the most rigorous because it is the most self-driven. There is little to no facilitation. Determine what rhythm is the best for you. Are you in complete shambles working in the morning before coffee? Are you a coding prodigy but find yourself completely incompetent in an interview? Do some of your projects need major renovation?

Here are some of what was part of my rhythm. I spent the first hour of the day either working on something left unfinished from days prior, or networking. I sent messages to engineering folks in companies that either had openings or companies I was interested in. The messages generally looked like —

Hi ____, I am a software engineer (or FSA grad) searching for a new opportunity in New York and am interested in X company. [Say concise artifact of why you’re interested in their company] If you’re interested, I’d love to grab a coffee (or hop on a call) to chat more.

After networking, if I had a coffee, call, or interview scheduled, I’d attend to that. Otherwise, I’d code.

Whether or not I had an interview coming up determined how/what I would code. If I had either an on-site or phone interview that included algorithms, I would practice whiteboarding or schedule a Pramp. If it was a Hackerrank, I’d practice on Leetcode, AlgoExpert, or CTCI. If it was behavioral, I’d review my projects. If it was a build, I’d work on whatever coding project I was building at the moment. Always prepare relative to what you have in the pipeline. Although all of us would love to do everything, it simply does not make sense to, say, practice whiteboarding if there are no foreseeable technicals in the pipeline. Or to research common questions on database interactions if you’re interviewing for a Frontend Developer role.

If I didn’t have any interviews in the pipeline, I would default to my original Scrum Framework. Many of my Tuesday and Thursday evenings were reserved for Meetups. There is no exact formula to creating the perfect rhythm — your rhythm will depend on your journey.

Wash, Rinse, Repeat Until You Sign a Contract.

When momentum begins building with one company, especially if it is the first company you’ve gone the farthest with, it is easy to bank on it being your big break. It could be. And if it is, good for you. But chances are, it might not be. You can feel like a code extraordinaire at your final round and you might even have blown away the CEO by solving the hardest algorithm you’ve completed to date, and still…. nothing is guaranteed (trust me). I was intent on a company I felt very good about, but when the company decided to pass on me last minute, I did not have any coffees or calls set up for the following week. I learned from that experience and when I finally accepted an offer at the end of April, I still had 3 phone screens and 2 coffees scheduled on my calendar.

Continue to take calls, schedule interviews, and follow the rhythm you’ve set until you’ve signed on the dotted line. You do not want to be in a place where a company reneges on their word and have nothing in the pipeline. Worst case scenario, you continue interviewing. Best case scenario, you get multiple offers at once and let your offer companies duel it out.

When All is Said and Done…

These were some of my main takeaways from my journey. I made mistakes and I tried my best to learn from them. Know that this list is not comprehensive but it does provide overarching data points and pivots I took that were successful.

Other components I chose to leave out because they could potentially be bigger blog posts in and of itself are how to network effectively and making human connections, how to prepare for an interview, how to negotiate on salary, and where do meetups fit in. If you would like to hear about any of these topics, please leave a comment below!

Contrary to how most posts I’ve read prefer to market this kind of journey, my biggest takeaway is that the road through a Software Engineering bootcamp is easier said than done. I know many very talented Software Engineers who have taken longer than 5 months to find their first gig. Eventually Imposter Syndrome will seep in because we as people tend to qualify ourselves by quantifying our journey. It’s okay. Don’t let the syndrome take root. If you’re reading this, you’ve probably already graduated. You’ve made some amazing strides. Built some amazing things. Keep it up. Getting to the end requires a lot of hard work, at least a little bit of passion, a small dose of luck, but above all else, stamina and persistence. You will get there, and the end will be as sweet as cherry pie.

**If you liked this piece, please hit the clap button or share so that others might benefit! You can find my code on Github, connect with me on LinkedIn, or find other projects or writing I’ve published in the past on my Portfolio or Medium page. Other posts that have been helpful for me while I was searching for a job include Sophia Ciocca’s piece and Mitchell Kosowski’s piece, both written back in 2017.

Tips On Landing a Software Engineering Job Post-Bootcamp was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.