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):
1. Your first job as a developer should not be a solo gig.
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...
2. Don't take a job that doesn't require you to prove your skills up front.
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.
3. Technical interviews are no joke.
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.
4. Rejection is going to become a familiar feeling
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.
5. Landing a great job is a marathon, not a sprint
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! 🙌ðŸ¼
Top comments (27)
I've just finished a marathon of interviewing 8 bootcampers in 2 days. The ones that received offers stood out as extremely motivated self starters. More importantly, they stood out because they continued their education post boot-camp in interesting ways like working on Project Euler problems, meaningfully contributing to open source projects, and reading relevant, challenging books. I think that it's important for a bootcamper to augment their whirlwind 'education' in CS with some actual CS education. That education doesn't need to be formal. Reading a book on data structures, or a basic book on OO programming goes a long way in a technical interview of a junior candidate.
Absolutely!
I went to a college instead of a boot camp. I was fortunate that my first job was with a capable team which mentored me but initially I did get the "my education didn't prepare me for real work" feeling as well. Almost everyone I know feels the same way. I don't think you can single out boot camps on this one.
You're probably right! I'm just speaking from my own experience — especially since many bootcamps include career coaching and job placement assistance as part of the package.
It's great that you're sharing your experience with the community and bringing attention to such an important topic. Kudos!
I didn't go to a bootcamp but I experienced the same. The cards are very much stacked against junior devs. I've consistently gotten the, "we went with a more experienced candidate" response. It sucks.
There needs to be more outreach to junior devs because it's an investment not only in the person, but in the company. The better you train a developer, the better asset they become to the company.
Some companies will say they went with the more experienced candidate because it's easier than "we don't like you; you won't fit in our team".
It's stacked against juniors because there are more applying for each job and juniors cost more to the company than someone with experience.
Great realization for anyone starting their journey into the tech world.. You will have good jobs, and bad jobs.. good managers and bad managers. It's important to keep growing. If you look around and your the smartest person in the room, time to move on.
Very well said, Kim. Thanks for sharing your experience. :)
Exactly. "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). "
Thanks for this!
It's really depressing how so many companies nowadays think they're so cool when they ask people to do the dumbest things in "job interviews".
If anyone tries to make me solve a riddle at a job interview I will tell them I'm not interested in the job as they're obviously not serious and lack the skill to hire competent people.
Also you're wrong, they ARE a joke if they're trying to quiz you on useless things like that, and e.g. the correct answer to "What does 45 + '17' evaluate to?" is "depends on the language, and in real world situations you shouldn't bump into the situation as you shouldn't be writing code where that can happen, but if you want to find out run the code instead of asking me".
I don't go to interviews to play games and jump through hoops, if they want to learn what I know about things, riddles, writing code on paper, or trying to pick out syntax errors is not the way. At least most of the time my job does not involve me being able to pick out every error in the code manually, that's what parsers, IDEs, linters, and unit tests are for.
I think, serious companies give you a task, which you have to solve within several days and which is related to their product, because this is how dev is actually working. Not monkying around with riddles and stuff. Of course, there is a need of a technical interview, where they can have a feeling of how good you are as a dev. But it should contain serious questions which are solvable. If they want to know how you work as a dev, they have to let you code. Freely. Not with a projector. There is just no need for "Live-Coders"
When I say they're "no joke", I mean that juniors have to be prepared for a crazy-wide range of technical tests—some meaningful and some arbitrary—and GA simply didn't shed light on that. No matter how stupid or dissimilar the tests are to actual dev work, these situations are daunting and unfortunately very common, and new devs should be aware that they'll probably come across a few of them.
I can relate to this. I had this recent technical interview where they told me that my solution is wrong. Hours after the interview, I tested their solution only to figure out it was wrong while mine was actually correct. They tricked me a bit just to test how well I know what I did. My fault I didn't even bother to ask more time to internalize the solution they showed to me. Great read!
Ugh that's rough. Personally, I think that's a cruel interview tactic — especially for juniors who actually produce the correct answer. As a new dev you tend to assume that the person interviewing you is more experienced than you are (at least I did), and you don't necessarily expect trick questions. I would've done the same thing!
Lesson learned: take your time and question everything. Hope you land somewhere great!
I just resigned from my first job after three months because it wasn't anywhere near development. And I knew that it was not going to help me in achieving what I want to be. Now begins the series of interviews and rejections. I think I am going to be more persistent after reading your post.
Congratulations on pursuing what you really want! I've been at my current company for about 8 months now and couldn't be happier — just stick with it, and something awesome will come up!
I'm really glad I came across this post.
I'm a current boot camp grad myself and I'm still on the job hunt. A past company I worked for (small and a little disorganized) contacted me today about doing some development work for them. Thing is, they have no technical department whatsoever. It would just be me and I completely realize the sense in what you said regarding not taking a job if you will be the only developer there.
As much as I want to secure a job, I'm learning I need to have patience and find a place of employment that'll benefit me longer term. Then on the flip side, should I take the position just to have that on the resume so that I'll have better luck in my job search? I'm conflicted haha.
It's not always a bad choice to take a job as the only dev if they'll give you some solid projects with reasonable deadlines and expectations. These roles can act as filler work, or maybe even freelance projects, until you can land a fulltime engineering role. You'd just have to be totally confident that you can produce these projects alone, and that they'll pay you adequately. That being said, the engineering scope of these projects will likely be simple (since they're a non-technical company) and those types of projects don't always stand out on a resume.
Generally, my advice is to build some side projects of your own to add to your portfolio and keep looking for a company with an established product/engineering department that will foster your growth. If I was looking to hire a new dev for my team and I had to choose between a resume with Bootcamp + scattered projects at a non-technical company vs. Bootcamp + a handful of creative, technical side projects, I'd choose the latter.
Really good advice. I was just offered to opportunity to work for a previous employer, but I would be the sole developer on the team of a non technical company and this would be my first role. I'm tempted to take it for financial reasons but I'm really leaning towards holding out for a better position, one that would foster my growth as you said.
I've interviewed Bootcampers and I felt that each believed they knew much more than they did. Three was a difference between knowing 'eval' was dangerous and why is as dangerous.
Also, if you've Bootcamped a front end developer role, don't apply for full stack or think that your skills apply equally to the back end. Get into a company as a front end and then reskill.
When working with Bootcampers in teams, I've found that they don't often have the same analytical ability as those that have a university degree. University teaches so much more than data structures, algorithms, etc; it changes the way your brain works and that is starkly noticeable in teams. This doesn't mean that you must go to university of but be aware that you might find some tasks more of a struggle than others.