My Advice for Coding Bootcamp Graduates

Back to blog

My Advice for Coding Bootcamp Graduates

10/29/2021

In June 2017, I started my career in tech by enrolling in Makers Academy for an intensive 3-month bootcamp. I started my first tech job in October 2017, one month after graduating. I feel that there are a lot of resources out there that cover the process of getting through a bootcamp or landing your first job after graduating, but there's this period of time between graduation and your first day on the job where things can feel strange - I see it as an 'airlock'.

My post-graduation experience is slightly unusual in that I was able to move into a job relatively quickly, but that was purely luck; my first employer wanted to rapidly hire a batch of bootcamp graduates with previous technical experience and I happened to fit the bill. Nonetheless, I struggled during that airlock period. Without the structure of the bootcamp and a clear objective to work towards (just this abstract idea of 'a job' that will happen at some point in the future) I found it difficult to use my time productively.

So, in this post I have tried to codify some solid steps that can be followed to help you navigate the uncertainty of the airlock and thrive when you step into your first day at a shiny neon-drenched tech office. I have not included any direct advice regarding job-hunting or interviewing because there's already plenty of material out there. Instead, I've tried to focus on ways to keep your technical skills sharp and maintain the bootcamp momemtum after graduation.

1. Set a routine

I think this is easily the most important bit of advice I can give. Create a routine for yourself, and stick to it. It could be a simple routine, like the following:

  • Morning: job hunt
  • Afternoon: learn javascript

Or something more elaborate:

  • 9AM: Breakfast
  • 9:30AM: Read tech news or tech blogs
  • 10:00AM: Job hunting
  • 12:30PM: Lunch break
  • 1:30PM: Study a tech concept (e.g., bubble sorting)
  • 2:30PM: Work on a project (something different from the studying the previous hour)
  • 4:30PM: Catch up on any job hunting developments that happened in the afternoon (recruiters emailling you back, interview requests etc.)

There's no hard or fast rule to come up with a routine and stick with it. You are the best person to come up with your routine, and you know best how to stick with it. I didn't set a routine for myself after graduation and ended up suffering for it; I couldn't find the time or energy within my disorganised days to study the tech stack being used at the company I started working for and had a much harder time getting comfortable in my first job.

2. Keep writing code

This one is obvious, I feel, but really should be emphasised. Keep writing code. KEEP WRITING CODE. Just because you've completed your final project at your bootcamp and graduated does not mean you're done. It might be more difficult to know what exactly to write without the guidance of a curriculum, but there are some resources to help.

I recommend practicing the fundamentals frequently to stay sharp. In my experience, many tech tests (even for junior developers) will include some sort of 'gotcha' or a layer of complexity that will need to be tackled with good use of a fundamental technique or pattern.

Check out these resources for practicing your fundamentals:

  • Codewars - puzzles and code katas that may come up in interviews
  • r/dailyprogrammer - regular coding challenges (start from the easy challenge at the end of the table and work your way up)
  • Advent of Code - Christmas-themed coding challenges (previous years of the Advent of Code challenge are always accessible)

if you have an interest or curiosity about any particular tech, then dip your toes into it and play around. There's no harm in trying, after all! I would recommend taking a look at the web developer roadmap to see how you could grow and specialise your skillset. Pick something that sounds fun or interesting and dive in.

A final tip to close this section: upload every line of code you write to Github. It doesn't matter if it's awful, if it's broken, if it's a super-secret proof-of-concept for your amazing idea that will definitely be the Next Big Thing™ or if it's an actual project that you've built and deployed. Your Github profile will show employers that you're writing code everyday and trying to get better. You'll be able to talk about what you've written in interviews and demonstrate what you've created. Employers want to see applicants with grit and enthusiasm, and in my opinion having a populated Github profile is easily the best way to show this.

3. Practice your communication skills

To succeed in your new life as a developer, you need to be able to communicate. Your time at a a bootcamp will likely have helped improve your communication skills with other technical people, but how do you communicate these concepts to non-technical people?

This is important because you will need to be able to explain stuff to non-technical stakeholders if you want to progress in your new career. I know this sounds obvious - I really do - but I have been surprised by the number of developers I've encountered at work who simply could not communicate well. Communication barriers hurt a team's velocity and unnecessarily introduce uncertainty. If you can commnuicate your work simply and effectively, non-technical colleagues will like you, and remember you in the future. Ultimately, this can help unlock doors in your career that may have stayed shut otherwise.

I split communication into two general areas (sometimes they overlap a little): technical and non-technical. Technical communication is the practice of giving information to colleagues who know how to code. Non-technical communication is the practice of giving information to colleagues who don't know how to code.

I think non-technical communication is the more important of the two to practice, because you can pick up technical communication skills organically within your work environment via pair programming and code review. I like to practice my non-technical communication skills by explaining technical things to someone who doesn't know much about technology. For me, the person I practice with is my mum. She'll ask me about general tech stuff (like the latest Facebook scandal) or work-specific tech stuff, and I'll try to translate anything technical into plain English. If she still doesn't understand, I'll spend a few minutes trying to come up with a different explanation and try again.

Find someone non-technical, and talk to them. Tell them about object-oriented design, about the law of demeter, about the dependency inversion principle, about HTML & CSS, about any technical thing you like. If you can reliably do this now, you'll find that once you start working and get comfortable on your team they will listen to you when you speak. Product owners, project managers and business analysts will remember you because you're able to explain the tickets to them in plain English. Other developers will like you because they won't have to waste time trying to translate technical concepts. They'll put in good words with leadership for you, and get you into meetings you wouldn't have gotten into otherwise. With that kind of influence, your career trajectory will change for the better.

4. Read code written by others

Reading code is harder than writing code. When you read code, you have to try and understand what it does, but also understand the author's intention.

I don't find reading code as enjoyable as writing code, but I know it's a critically important skill to have. As part of your future work, you will almost certainly have to perform code reviews for your team members. You'll need to be able to read their code, understand what it does and - most importantly - why it does that. If you're bad at reading code, you'll have a harder time getting work done on your team.

There's a simple way to practice this skill: read code. I know this sounds a bit reductive, but it actually took me a long time to figure this out. I would stuggle with code reviews because I had so much trouble parsing code that wasn't written by me, and found it difficult to make any meaningful suggestions to colleagues when prompted.

When I figured out that I was bad at reading code, I resolved to spend time focusing solely on improving. However, I couldn't figure out where to find code to read. I could look at the stuff my colleagues wrote, but looking solely at one project is a bit limiting. Ultimately, I figured out where to find code: Github. Plenty of open source projects both popular and obscure host their source code on Github. I cloned the source code of a library I was using frequently, read through the code over and over until I started to understand what it was doing, then stole bits and pieces to incorporate into my own library that I was writing.

So, go to Github, clone a project or library you like and dive into their source code. Read it, annotate it, break it, refactor it. Understand it. You may just learn a thing or two, or even end up opening a pull request and making a contribution of your own.

5. Don't go on holiday

I understand that this is a horrible-sounding piece of advice, but please really seriously consider not going on holiday between graduating from your bootcamp and starting your first job. I found that participating in a bootcamp put me in a certain mindset. I like to call it the "Just Fucking Do It" mindset. I would throw myself at challenges and problems, and take on everything in my path. Learn React to apply for a random job? Sure thing dude, no problem. Interview for 3 different companies in one day? Easy.

I had this focussed determination that helped me get my first job after graduation. I then went on a week's holiday to Cyprus and completely destroyed that mindset with cocktails and swimming pools and meze. I tried to dedicate time to writing code whilst on holiday, but that obviously never happened.

A few fellow graduates were interviewed and offered roles at the same company as me. They did not go on holiday, and instead spent their week learning about the tech stack in use. On their first day, they hit the ground running and started making contributions to their teams' work. On my first day, I had no idea what anybody was talking about (also I was quite sunburnt and therefore in a decent amount of pain), or what an Angular was, or what a TypeScript was. It took me 3 months to actually understand what was going on. My week's holiday cost me 3 months of professional development.

I could have instead scheduled a holiday for a few months after starting my job. I would've hit the ground running, and had a nice break to look forward to. The time I would then have away from my work would've given my mind space to breathe. I would've had the opportunity to relax and reflect, to let the important learnings from my first few months in my new career percolate through my head and turn into valuable knowledge.

I know you might be exhausted after getting through your bootcamp, but wait. Wait a few more months before going on holiday. It will be worth so much more.

To Conclude

I hope my ramblings help you. I've written this for two reasons: to help recent bootcamp graduates, and to try and help codify learnings from my own experience by reflecting on what I consider to be valuable in my career. Good luck out there - the job market may be tough on junior developers right now, but always remember that there are more vacancies for good developers than there are good developers.

To finish, here is one sneaky bonus piece of advice: read tech blogs. Interviewers may ask you about things you've read recently to gauge how dedicated you are to your craft. Tell them you read this and watch as they nod in approval!