4 Things I Wish I had Done Immediately After Graduating a Programming Bootcamp

4 Things I Wish I had Done Immediately After Graduating a Programming Bootcamp

The process of securing a job after completing a coding bootcamp is not automatic. The good news is that coding bootcamps are certainly still a viable option for motivated students, but it’s important to have the right expectations ahead of time and to not see bootcamps as a means to an end. The right mentality is to consider that “the job has only begun” as soon as you complete a bootcamp. You should establish daily goals and a process that works for you. You will get many rejections, so the key is to establish a process and not to place all your eggs in one basket. Never get too attached to any one opportunity. There were companies that I was passionate about, knew the tech stack, and I had solid referrals for, yet didn’t get past the first interview. And on the other side, companies where I knew no one and had zero expectations for, yet ended up getting to the final interview or a getting an offer.

In addition to the mental fortitude, and treating it as a process, here are 4 specific tactics I wish I would have applied as soon as I graduated from a bootcamp: 

Create one “showcase app” 

I made the mistake of having a few different apps that I was working on at the same time. This was good for practice, but when I was asked in interviews to “tell me about an interesting project you’ve worked on” I wasn’t particularly proud of any of them. In fact, it was about a 4-way tie between all of my apps, and I would give different answers on any given interview, based purely on whichever of the 4 came to mind. There should be one dominant “showcase” app that you can resort to for this question since it will come up, especially if you have not had previous professional programming experience, you can only resort to talk through your personal projects. You should be proud every time you talk about your showcase app, and be comfortable talking through every aspect of it. 

Write down each of the coding questions you get in interviews 

You might be surprised how often the same type of question, or even the same exact question, can pop up in an interview. Oftentimes it may be the same exact question, but disguised in a different way: “how many floors do you need to walk up if…” vs “how many miles do you need to drive if…” After each of my interviews I remember thinking “it would be good to know how to do that problem, but there’s no way it will be asked again in my next interview… ” wrong. They kept popping up.

Another common issue is that you focus so much on getting the problem right during the interview that afterwards you think “well there’s no way I’m forgetting that problem that I just struggled with for an hour straight…”, but you do. It’s natural, we relax and somehow manage to completely throw out our memory of the problems we got the day before, so be sure to write them down as soon as possible so that you can practice them. Even if you don’t get the exact same problem again,  it’s very likely you will get a similar one. 

10 commits on github/day

Commits can be a vanity metric, sure. But one can make an argument that many things in life are vanity metrics… even college degrees to some extent. The github profile full of constant green boxes representing your daily commits will be nice for recruiters, but there’s a much bigger point here. When coding, it’s easy to enter into a mental block, very similar to ‘writer’s block’ that almost all professional writers experience. These blocks can be particularly challenging during the rough phase after graduating a bootcamp or college… you may start to even have certain doubts and depressing thoughts that creep in. The truth is, all professional programmers have these phases when motivation and energy is low, they just have more professional experience so it’s more easy to deal with- they are already employed, have already felt the feeling before, etc. so it’s easier to fight through. It’s important to realize that you don’t always need to be in a “flow state” or even close to your best mental state to commit code. What’s important is that you keep moving, that you “keep committing”. 

Another benefit of the 10 commits/day that applied for me was that it got me into the habit of “warming up” when I first start my day of coding. I usually would pick something small, like fixing up a bit of styling on the frontend, to immediately fix and commit within the first 15 minutes to get the ball rolling. Getting a couple of “easy” commits out right away can help to remind you of the structure of the app, and to warm up the fingers, to prime you to keep going. Also, getting something small accomplished can encourage you for bigger tasks; essentially with the same psychological factor that “making your bed” in the morning can have for daily productivity. And at the end of the day, even if you had a very unproductive day, at least you had a couple small fixes from the morning. In the words of Admiral William McRaven, “… and if by chance you’ve had a miserable day, you will come home to a bed that is made…”