The goal of this series is to share my journey on how I went from a bootcamp student to senior software engineer. Finding a new job after graduation was one of the toughest and most rewarding experiences I’ve ever had. I’m hoping that this series could help others learn from the things I did right and from my many mistakes.

How To Learn

One of the first lessons that coding bootcamps teach you is how to learn. You go through a checklist of finding the appropriate material for your level of understanding (with the assumption that you don’t have a strong technical background), how to find help or the right resources, and how to constantly ingest information, new concepts, or solutions that come your way. The bootcamp taught that this is a fundamental skill that all engineers needed in order to be successful, because we are always learning.

Initially, I thought to myself that I had not forgotten how to learn. Working as a project manager or product manager, I learned new things everyday. Through repetition, I was able to train myself to make of habit of things. If a certain issue had occurred, I would do the following: evaluate the situation, attempt to remedy the issue as I had done previously, google it, or ask someone who is much smarter than myself. At the time, it sounded like this initial fundamental skill that my bootcamp was focusing on was something I had already mastered.

The Difference Between Learning & Understanding

As I was going through the curriculum, I was learning but I did not always understand the underlying concepts. For example, I learned that javascript had asynchronous characteristics but I did not understand what it was that allowed it to be asynchronous (i.e the event loop; the heap, queue and stack). During my studies in the course provided materials, these details were omitted and probably for good reasons. Coding Bootcamps are designed for non-technical people to get a general grasp of programming skills. None of the course content is tailored for an individual, but rather for many, many students. You’re not expected to understand how the event loop works, only that it exists and it makes JS awesome, because most jobs do not require you to. Your focus, initially, is not to worry about scalability or all the cogs that makes the machine work, but to build a minimal viable product that just works.

My mentors have stressed that I shouldn’t spend too much time on focusing on the how or why of things, but to get as much hands on coding exposure by working through projects. They had a fair point; if I jumped down a rabbit hole of understanding how the anatomy of the event loop, understanding how Node.js works with the V8 JavaScript engine in-depth, or other areas of focus, then I would not be able to get any of my projects done. However, they did not discourage my curiosity for learning or understanding the questions that I had but instead they asked me to progress through my challenges at hand and do the research on my own time.

So I did. Anytime I was not working through my challenges of building a http server and connecting it to a database, I would take the time to try and figure out how things worked. On my BART commute or during my breaks, I would read articles on Medium or Reddit to strengthen my knowledge of the domain that I was trying to grasp. If during my challenges/projects, I would come across a new concept, I would write a bunch of notes on the concept or add a TODO comment to come back to it later.

I would meetup my peers, during the week, where we’d help each other try and understand things that we’re interested or stuck on. People learn differently, and some concepts are easier to ingest than others, therefore it was great to gain perpsective on how others were able to understand something that you may not understand. These meetings were one of my favorite moments during my journey of going through the bootcamp curriculum because it taught me to learn and teach others.

Learning Better (and Efficiently)

Building a habit to explore my curiosity in tech helped me throughout my career. It allowed me to continue to stay hungry; interested in new and foreign things. I would experiment with new concepts, trends, and best practices every day. I’m a hands on learner; I use my portfolio projects like specimen for me to experiment on. It helped me take the idea of learning to the next level.

Whenever I came across something interesting that I wanted to try, I would do the following:

• Draw a diagram of to make concept easier to understand

• Map out how I am going to achieve the goal in a current project

• Implement it in my current project as it’s own isolated function

• Write Unit Tests for that function

• Tweak the function to make sure that it satisfies all my cases

• Documentation: Use JSDocs, write lots of comments, create markdown notes for a README, and/or saving snippets in Evernote/BoostNote

Pro-tip: If you see a solution from stack overflow or from a colleague/peer, but you don’t fully understand it, write a unit test for it and make sure to also have a debugger on so that you can step through the functions with breakpoints. You can choose to select and watch certain variables to see if your data mutates, or if a behavior working as intended. You will also make sure that the code you found works with what you’re trying to do. console.log, println, fmt.Println, or etc., does not always tell the other entire story.

Not only does doing these things help you learn and understand things in a better way, adding it to your workflow is a great skill that employers desire. It shows that you’re not a Full Stackoverflow Developer, that you go beyond copy and pasting or ingesting answers, and you actually know and understand what you are doing. I ended up making a list of things that I wanted to learn things daily by queueing them up in my bookmarks tab in Chrome, and I’d go through the list at the end of the week where I’d allocate time to experimentation or going in depth on things that piqued my interest.

Even after graduation and obtaining a new job, I still continue this practice regularly. The best way to fight imposter syndrome when getting a new job is to use your time to ramp up, wisely. Don’t stress about it because you’ve just developed a way to learn and understand anything and everything. Think of it as going from apprentice to master. One doesn’t simply master something just by learning, but by truly understanding something and really knowing the subject matter at a greater depth.

OK, Got it… What else?

Bootcamps have the stigma that they just ship out students that know the very basics of how to code and nothing more. They believe those graduates don't have the fundamentals from a computer science degree or their portfolio projects are not comparable to actual on the job experience. In the eyes of the industry for a bootcamp graduate, depending on your market and experience, you're usually a few steps behind those with a CS degree. This is definitely not always true.

What you learned and the entire experience you just went through is what you make of it. If you really want to stand out from the newly minted developer that just graduated from a bootcamp, then you have to be passionate about continuous learning. Often hiring managers will judge you on what you really know from the things that you’ve put on your resume. Remember anything you put on your resume is fair game for interview questions. So if you say that you are “advanced with Node.js”, I’m going to expect you to know how to use the built in debugger over console.log. This is not something that you should expect out of your bootcamp because their job is to get you started. Once you've gotten your feet off the ground, you need to take the next step forward to up your knowledge and game.

Side Note: You’re also better off learning about learning languages and their core fundamentals rather than focusing solely on mastering frameworks. In the JS ecosystem, new frameworks or libraries come out all the time, so it’s much more valuable that you understand the language.

Also, avoid listing a lot of items as skills on your resumes if you’ve only had minimal exposure to them. You can always add those skills that you’ve had minimal exposure to inside the bullet points of the job description, and explain how you used in a project. Anything you list under the skills section is fair game for deep dives or interrogation. I’ve interviewed many applicants and I generally derive questions from their skills; a fair amount of these applicants only used the underlying tech once or twice, but did not really know much about it.

On the Job Training

When I got my first job out of a bootcamp there was a lot of information you have to prepare yourself for to get ready. I was hit with having to figure out how to setup upstreams and a http proxy with NGINX on top of a node.js application, how to scale a node.js application, usage of different databases that I’ve never heard of, and many more. On top of stack and infrastructure, there’s also a bunch of tribal knowledge, such as why previous developers made a decision to do something over another, or the different quirks of authentication and session management that services have to go through. No one learns and understands that all on day one. The important thing is to not freak out, and have the perseverance and drive to digest all of this information at your own pace.

Conclusion

To be clear, I’m not advocating against attending coding bootcamps. I feel they do the perfect amount of getting you started, and having you continue on your own. At some point, you will have to leave the nest and continue learning on your own. During my job hunt, I figured out that to learn is to adapt. Going through job descriptions for the first time, you may not have learned how to scale Node.js applications, Dockerize applications, use NGINX, build microservices, or use AWS (not just S3 or lambda). I had to take the time to learn and understand it prior to applying for that job, just so that I’ll feel like I have the edge over my peers or the other 100s of candidates applying for that job or that I am adapting to become an ideal candidate.

I’ve always kept learning and trying to understand things as much as I can. I graduated from a bootcamp about two years ago and I’ve accomplished a lot. I’ve become a Engineering Team Lead for a Product (twice for two different companies), obtained a AWS Solutions Architect Certification, played a integral role for a company to migrate their on-premise infrastructure to AWS, and I am currently a Senior Software Engineer at Zendesk. I did not save this part for myself to brag about my accomplishments; a lot of my peers who did find great jobs or have greater accomplishments than mine, are always constantly learning, trying to understand, or experimenting with new things. I truly hope that your results will come out better than mine.

TL;DR: Keep learning and really understand your domain well. Work your way towards mastering the things you want to do good enough. Experiment with things and try to know the ins and outs of how things work. Take 5–10 minutes to read an article about your domain or try something new.