As a career-changer, I can wholeheartedly say that I wouldn't have learned to code without going to General Assembly. They planned the curriculum, taught us the lingo, held us accountable, and gave us a support system of classmates, teachers, and TAs. They also sold us a shiny promise that we'd easily land a $80k+ job with just four projects, a rewritten resume, and a can-do attitude. In hindsight, the last part seems ridiculous.
I loved every second of my program, but it failed to prepare me for the reality of the job hunt post-grad. I can chalk a lot of the deficiency up to my own blind optimism and naivetÃ©, but this lack of direction is a major flaw in the bootcamp model. While my experience doesn't apply to every bootcamp grad, it rings true for many of us and it needs to be addressed.
Here are 5 practicalities I've learned in my first year in the trenches (that my bootcamp didn't teach me):
When I graduated, I had a new job lined up within 24 hours. I was one of the first in my cohort to do so, and I was pumped. Holy shit, someone actually wants to pay me to do this! I got caught up in the excitement and failed to be selective in my search.
This company hired me as their first front-end developer. ðŸš¨ DANGER ðŸš¨ One thing became abundantly clear, and fast: "First developer" is often code for, "We have no idea what to do with you."
After joining, my manager regularly called me by the wrong title (UX person?) and questioned my legitimacy because I said being a designer, a front-end dev and a backend dev were three very different jobs, and I couldn't do them all. Their clients set impossible deadlines for my projects. They wouldn't grant me IT permissions to use the terminal, and eventually asked me to use my personal laptop instead. I left after 2 months.
Jobs like this won't give you equipment, structure, or professional guidance. Being marooned on a non-technical island is not the best way to grow as a brand new developer. That being said...
I left the previous company to pursue a full-stack role at a different organization where I was again, the solo dev, but with even less oversight. This time, I was hired by a non-technical team to work on internal projects without any clearcut deadlines, and they trusted my skills implicitly. Cool! I have complete creative freedom, I thought.
A few weeks in, I realized they didn't care about my skills because they had no way to measure them. Because no one monitored my work, my performance was never subjected to praise or constructive criticism. I can't stress this enough: it is so easy to become complacent (and stagnant) in your skills if no one is around to challenge you.
This type of environment can also make your job vulnerable, or even dispensable. If software isn't a priority for anyone else at the company, it's likely that your position could be one budget meeting away from being cut. This happened to me, and it seems ridiculous (why did you even hire me?), but it's common in disorganized companies. Jobs like this are easy to land, and often hard to keep.
Since parting ways with the last company, I launched into a 6-month stretch of code challenges and technical interviews. It turns out, proving yourself worthy of a "real" dev job is really hard – it requires practice, confidence, and adaptability. My career coach at GA insisted, rather, that a sparkling LinkedIn profile would be our best asset in this race, and he disregarded the rest of the process.
Pro-tip: a well-worded LinkedIn does not make up for poor performance in a technical interview.
Here's a snapshot of some interview scenarios I encountered for junior/mid-level front end roles (some between 3-6 hours long):
- Solving riddles and writing game-like algorithms with my screen shared on a projector in a room full of engineers (Palindromes, Fibonacci, Tic-Tac-Toe, etc.)
- Pair programming to create a custom Sass animation with @keyframes
- Working with a designer to build a page using their chosen preprocessor (Slim) and the company's custom Sass style guide
- Racing through a timed, super-granular multiple choice syntax test
- Answering theoretical questions like, "What's the difference between cookies and local storage?", "How does JS event propagation work?", "How can you improve loading time?", and "List the pros & cons of each browser."
- Taking a handwritten test on fundamentals like, "What is a closure?", "How do you determine if a variable is an object?", "What does 45 + '17' evaluate to?", and, you guessed it, FizzBuzz.
While I found common themes in each challenge, the method changed each time, and GA failed to drill us on any of them. Take the preparation into your own hands. Read up on ways to stand out and pose thoughtful questions to your interviewers. Practice answering common questions with a friend. Try handwriting those riddle algorithms. Explain theoretical concepts out loud – it's harder than you think.
And it's not always your fault. Maybe your interviewer is having a bad day. Maybe they brought you in even though your skills don't completely align with the role. Maybe you're an "awesome culture fit", but they "went with a more experienced candidate". Maybe they said they want to hire you, but the budget for the role got yanked the next day. Maybe your recruiter just doesn't know wtf they're doing. I've been victim to all of this.
But what about when the failure is your fault? Technical interviews are highly intimidating – even very skilled developers often fail them. Maybe you studied browser quirks and sorting algorithms all night just to get quizzed on CSS instead. Maybe you completely freeze under pressure. Maybe you rely too heavily on Google. Maybe you need to brush up on the CS fundamentals. I'm also guilty of all of this.
If your experience is anything like mine, this trial-and-error process will cause a heaping sense of imposter syndrome. Every time I failed or a more experienced engineer outperformed me, I got a sinking feeling that I'd never be good enough. Even though I wrote code every day, listened to dev podcasts, went to networking events/meetups/conferences, read programming books, learned a few new libraries & frameworks, and built a handful of side projects, I still couldn't hack these interviews (pun intended). If you're doing all of these things and experiencing similar luck, keep at it. Stay immersed.
Professional rejection is an awful feeling, but it is completely normal. Know that you're getting wiser with each interview, and these failures rarely reflect on your overall potential or skill. Failing doesn't mean you're a bad developer –it means you need more practice, and the right fit has yet to come along.
This industry is also competitive as hell. I often came across job postings that already had 400+ applicants by the time I found them. By the end of 6 months, I applied to 211 jobs. These numbers are intimidating, but keep in mind that if you're getting in the door at all, you're doing something right. Keep practicing.
Bootcamps sell a short term solution for a long term goal. Students are told that they can abandon their careers, code for a few months, and come out the other end with an ROI comparable to that of a 4-year degree. The reality of that sentiment is still hotly debated.
The pure short-term hustle and instant-gratification vibe of a bootcamp evokes a sense that an amazing job will just appear when you graduate. In most cases, this couldn't be farther from the truth.
I wish someone had told me that this goal would take a healthy dose of failure, serious self-awareness, a whole lot of tenacity, and most of all... time. The transformation doesn't happen overnight.
Bootcampers: we're known in this industry for being scrappy self-starters and fast learners – don't let that end when your job hunt begins. Keep grinding, be selective, and land a job where your professional growth is a priority.
Bootcamps: let's get more practical in the career coaching arena, yes?
*** 8 Month Edit ***
I'm happy to report that by the time this post went live in April, I had just landed what's proven to be a highly creative, inclusive, technical role where I learn & grow every day. Just know that these jobs are out there – and a really tough interview process is not always a reflection of your skills or potential as an engineer. Keep going! ðŸ™ŒðŸ¼
Many times as a mobile developer I have to work on apps without the API ready that was crucial for the feature I was implementing. Either the backend was developed by another team that was not entirely in sync with us or our backend team had no chance to implement those endpoints earlier. For this reason, I was not able to satisfy the Definition of Done but it does not mean that I have implemented the UI only.