So there I was - sweaty, bedraggled, wild-eyed, and proud; after 15 weeks of intensive web development training, I'd done it. I'd proved - to myself, and maybe even others - that I understood the fundamentals of programming, and gained intermediate fluency in two languages. I'd deployed apps in two major frameworks, and gotten the hang of their DSLs. I had over a thousand commits on Github. I was employable, and would have a job in no time!

Countless rejections later, I can tell you that in a competitive market this is simply not the case. However, in the last few weeks, I've been getting much more consistent interest. I've advanced to second and third rounds with multiple companies, and today I accepted an offer from my first choice. As far as I can tell, there are a few reasons for this, and I'd like to break them down for you, the new graduate. (Also, I never would have gotten this far without the bootcamp, so this is in no way intended to be a substitute to the program. Think of these as strategies to differentiate yourself from other grads who won't put in this effort.)

Specialize . . .

If there's any language or framework or tool or anything you've touched so far that was more interesting to you, dive into that. I chose frontend, and specifically React/React Native, since I had the most fun with those. People love to see that you can learn something really well - you can teach skills, but not the drive to really go deep. Keep everything on your resume and skill list, but lead with your chosen specialty. I was hired for a frontend role, but had interest from backend roles, and one company said it was because of the aptitude I showed for React.

. . . But Also, Try a Different Stack

I learned Rails & React in school. I tried MEAN & MERN afterwards to make sure I could apply my training to new technologies. And although I now harbor a sort of mild distaste for Angular, hello world-ing in these new technologies was not too hard, and it looks great on my resume. It also reinforces the idea that you learn new things fast, and won't need 9 months of onboarding.

Test Ya Damn Code (and Write Testable Code)

Twice I was asked to comment on the lack of testing in my Github repos, and I didn't advance in either interview. It was also the main reason I didn't pass my first take-home code challenge. Coincidence? I think not.

In school, all of our labs were built around passing automated tests in Rspec or Jest. Exposure to test-driven development? Check! What they didn't teach us was to write the tests ourselves. Many of us left feeling like it was a blind spot, and a scary one to tackle alone. You know what? For intro projects, making some unit tests is dead easy.

Testing is ubiquitous in the real world, and even if companies aren't testing 50% of their codebase, they want you to feel like they should. Fortunately, when something is required of a lot of developers, a few will do the heavy lifting so it's easy for the rest of us. Modern testing tools are designed to require very little effort to learn.

Learning to write easily testable code is a bit harder. Go back to one of your bootcamp projects and write exhaustive unit tests for each feature. Some things will be easy - do your links navigate to the right URLs? But you will soon find parts of your code that are impossible to test in isolation. And that, dear reader, is Bad. Learn more from this excellent blog.

Data Structures and Algorithms (DSAs)

It's very likely you'll be asked to solve an algorithm question - a sort of riddle - in your job search. There's a lot of chatter by devs at all levels that this part of the interview process is broken. And really, you won't be solving tiny riddles every day. When I went through the Flatiron School, we barely scratched the surface; however, they are part of a standard CS degree, and knowing DSAs is often cited as the reason CS students are preferred over bootcampers.

From my perspective, learning DSAs is invaluable - and being able to select the proper one under pressure does prove that knowledge. It's part of every dev's job not just to make solutions, but to make efficient solutions, and to make efficient solutions efficiently. If you can break any problem into the most effective DSAs, quickly, you'll be able to focus on larger design patterns or solve inefficiencies in the code of other, inferior developers. You will be a more effective programmer.

That said, for junior positions, the questions I've gotten have not been too bad. I worked the Easy interview track on Leetcode until I was comfortable that I understood each one, and that covered 90% of the questions I've seen. The others were from jobs that were probably above junior level.

See my eye-crossingly intelligent friend Rylan Bauermeister's pieces on: Binary Trees, Linked Lists. Also learn to implement a hash class from scratch. This came up multiple times.

Get Good At Vanilla

I'll use the example of CSS. While in school, I mainly used frameworks like Bootstrap and Semantic to style my projects, because they were quick to deploy and looked fine. I was caught out on this in an interview early on when I listed stackable columns as a benefit of a heavyweight framework like Semantic. This revealed I'd never dove into Flexbox at all, and was ignorant of modern CSS capabilities.

So, I took a random card-based page from an e-commerce site, and recreated it in React and vanilla CSS. It took me about three days. Did you know you can use variables in vanilla CSS? How about show an even drop-shadow border on all four sides of a card with one property? Use calc to make your sizing dynamic (or anything dynamic, really)? Well, I do now. And knowing that I can do it without the help, or load, of a framework has made me more confident as a frontend developer.

Drink From The Source

Take a framework you've gotten comfortable with, and think of a feature that was tricky for you to get working properly. (It's not super important which one.) Now open up its Github repo and look at what it's actually doing. Confirm it by passing it different inputs. Tinker! The source code of a widely-used open source framework is pretty likely to have been formatted for readability. Maybe the feature isn't perfectly documented - contribute to the README! I promise this will make you more confident. I had a PR approved on one of the Google Cloud docs and it did wonders for my self-esteem. (Super nice folks, btw!)

By the same token, learning about your language's compiler will also make you better. Example: creating identical object models in JS can make searching through those objects 7x faster.

At our level, you shouldn't be expected to know framework source code or compilers from back to front. You should show that you know they're there, and are comfortable thinking in their terms.

The Dreaded Behavioral Questions

There's no way around these. You're going to have to answer a variation of 'So, tell me about a time you disagreed with someone at work' almost every time. Look up the STAR or CARL techniques for answering these questions, write outlines, and practice them. Rewrite and practice until you can answer concisely and in a way that indicates you (a) are human, (b) can communicate about emotionally charged situations in a productive way, (c) won't be a horrific asshole to work with, and (d) care about getting shit done that benefits the people around you. That's all they want to know. That's pretty reasonable, right? I mean, that's who I would want to work with.

Your Cover Letter & Resume

When sending in a cold application, write a cover letter that's about 3 sentences long. Mention something from the job post, and why you're drawn to it. As a the geniuses at The Onion once proclaimed, "Student Thanks Professor Who Taught Him To Pretend To Give A Shit." Don't cyberstalk every employee or memorize every patch note. They just need to know that you're comfortable making them part of your identity.

In a short paragraph on your resume, sing your own praises - not just about your coding abilities (which count!), but all the skills you've gleaned from your other life experience. In professional language, of course. Anything that can be construed as project management, communication between groups, creative & technical problem solving - these are all instrumental to your new career. Emphasize these points under past jobs as well.

Find the nodes in your life that make you look like this was always your ultimate goal and you are going to excel at it. They are there, I promise. Graduating from a bootcamp proves you can absorb a lot of information fast! That can get a recruiter over the hump if you're missing experience in part of the job's tech stack. I know a developer who did their whole bootcamp in Python, and got hired for a Ruby job right afterward, by emphasizing this.

Now . . .

This probably seems like a lot to do. It is. It took me about three months. I was a little all over the place, but if you're better focused than I am, you could probably do each of these in a two-week span or less. In the scope of an average job search, that's not that bad. And I think doing some or all of this will do nothing but benefit you.

Good luck! I believe in you!