What’s it like to interview at tech companies as a bootcamp grad, and how can you help yourself stand out from the crowd? Get insights from Hack Reactor grad and current Climb Software Engineer AC Roselee, from searching for jobs to acing your interviews!
By AC Roselee
Don’t shy away from networking — or LinkedIn.
The most traction to blind applications that I got was by using LinkedIn and sending my resume in proper ATS format, and I would build the resume and my cover letter towards the job description … A site that offers the service to customize your resume and cover letter to the job description that was able to help me was Resume Worded, which also sends out an email newsletter with helpful tips and tricks to think about what to do once you get the interview.
But what I felt was the most successful way to find job opportunities was through networking. I think that word makes most people freeze like deer in headlights, especially career changers, because they may be thinking “all of my friends are not in tech, how am I supposed to network in the traditional business sense?” But that’s not what I mean — if a recruiter reaches out to you about a job, even if you aren’t interested in it, thank them for their time and outreach and ask that they keep you in mind for a role you would be interested in. That’s networking.
You can reach out to recruiters on LinkedIn, and some of them are really nice professionals and will take 15 minutes to give you a read on what they’re seeing in the job market. If you see a job posting that resonates with you, go ahead and reach out to the people who work in that role or at that company for a 15-minute chat about their experience, not with the intention to get a referral or try to sell them that you’re the person for the role, but just to learn more. And a lot of times, referrals do come out through that. Their people are excited that you’re excited, and they want to help. Also, hit up old co-workers who work at a company you’ve decided would be a good fit. That’s actually how I found my first job out of bootcamp — I had been talking to all kinds of people, but then an old co-worker from the newspaper was like “hey, we’re hiring for developers, what are you doing?”
Other things that people can do is going to meetups and joining groups on LinkedIn (there are tons of groups on LinkedIn for developers, or whatever you’re interested in). You are a software engineer, prove it. Start doing things that show “I’m not just here for the money, I’m here to actually do this work.” And you never know where a referral or job offer may come from, so stay open to putting yourself out there, be it through a human connection or a job board.
Make sure to stay organized and keep track of your applications.
Personally, I kept things in a Notion board. I like it because my documents that I have organized and nicely made are all at my fingertips. As long as I have an internet connection, I can get back to these things. I kept track of the most promising job prospects, the ones I was most interested in, as a basic document answering the five Ws: who, what, when, where, why. However, if you’re more data-oriented, many in my bootcamp cohort followed recommendations in the book The Two-Hour Job Search, which advises you to make a spreadsheet to keep track of where you got in the interview process, with whom you interacted, benefits, pay range, all kinds of stuff. That can be valuable data you collect as you progress through your career — not just this job search but the subsequent ones. You keep that data with the intention of potentially interviewing at that company again. Say you get right out of bootcamp and apply at Alphabet or Google. Chances are, unless you know somebody and are a rockstar, you’re not gonna pass the first interview. But that’s fine, you may want to work for Google when you’ve been an engineer for two or three or five years, and you’ll want to go back so that you can refer to these notes.
When it comes to interviews, practice and preparation are key.
Confidence is attractive, and so I actually tried to take as many interviews as possible in order to increase my confidence, refine my elevator pitch, and strengthen my ability to speak on technical topics coherently and concisely. What an employer ultimately wants to know is if you can and want to do the job, so I centered my elevator pitch around communicating both of these points to my interviewers. Before the interview, I took time to learn salient points about the health and growth of the company, like its mission, key employees, and recent news. And I cannot say this strongly enough: never go to an interview without at least two questions designed to suss out the work environment and people you are potentially going to spend at least a third of your day with.
I and some of my cohort also used Pramp, where you can practice with your peers and shake off some of the nerves that you may have. So a peer will come to you and give you a mock technical interview so that you can learn to get your message clearer, more concise, and more impactful.
Communicate what you bring to the table, but be sure you can back it up with examples as well.
In the world of marketing, there’s a handy concept called an elevator pitch — imagine you happen to get onto an elevator with someone who can change your life, and they will be getting off at the 20th floor. What do you say to generate interest in what you have to offer in a few sentences or less? So you identify your strengths, how they can be an asset even if you were coming from a different industry or field, and brag about your resilience. Make it clear, direct, and get ready to provide your evidence if you make it past the elevator pitch.
Part B is that you have to be able to prove you can do the work — they need some evidence so they can go to their boss or their stakeholders and say “this is the person we want and this is the evidence.” This often involves making sure you have a portfolio site, GitHub repos of your work, and even blog posts on how you overcame technical challenges. If you’re a person who is good at technical writing, don’t keep it a secret. Go ahead and share with the world what you learned, if you’re comfortable with it. I know many people who are, and they get a lot of traction that way.
Highlight to interviewers how a coding bootcamp education sets you apart.
I did have previous experiences as a developer, but I focused on my recent work at bootcamp and spoke to the challenging problems I saw there and my desire to take a deep dive and become an expert in the language I learned, which was JavaScript. I spoke to the time pressure and difficulty of working on complex problems in a pairing environment, and how that grew my soft skills as a team player in a coding environment. Best of all, I talked about my war stories, which were extremely challenging technical difficulties that came up in bootcamp, and I explained how I fixed them. Because ultimately, engineers love to hear about how others solve puzzles, and they love to debate opinions. So have examples ready of both, and be willing to intelligently defend your opinions and why you chose certain methods. Then, I incorporated my previous experience as a graphic designer to talk about user-first design, efficiencies of planning before you write, being able to communicate effectively with different business units and determining specs, and my attention to detail. While I already had these skills, bootcamp was able to refine them to translate to the world of tech.
You might not know how to answer every question, and that’s ok.
Just because you go through bootcamp, that doesn’t mean you know all the theory. But don’t sweat it too much at this time — realize that because you graduated from a bootcamp, it means you know how to program, but you may be a little foggy on why. Lifelong learning begins the second you decide to become a software engineer, so always be looking to backfill your computer science knowledge, update your current skills, and scale up your understanding of how and when to use which tools. When I was asked a question I didn’t know, I would frankly admit that I was not familiar with the concept or technology they were speaking of, and I would politely ask them to explain it to me. Show that you are curious and always willing to learn what you don’t know, and never let pride get in the way of your learning. Sometimes, the other tack I would take if I sort of knew what they were asking, is I would say “I’m not super familiar with X, but here is what I understand of it, and if I understand what you are asking correctly, I believe the educated answer would be…” and go from there. Both of these methods can demonstrate that you may not know precisely what it is, but you are willing to communicate, have curiosity, can show your thought process, and are open to learning. Not every job is going to give you the grace to grow into your role, and that’s okay. Just keep shopping yourself around until you do.
Concisely show through your answers that you have the necessary foundational knowledge — even if some of that foundation isn’t in tech.
Understanding the fundamentals and demonstrating through my answers that I had a good foundation seemed to be the most effective strategy for answers in interviews. Know your system design (at least on a basic level), show that given any problem you can break it down and solve for what you know, and mention the resources that you would use to fill in for what you do not know. That will take you far as an engineer and in the interview.
Apply your experiential knowledge in concrete ways, like: “I have been an accountant, and this is how that translates to tech” or “I have been a garbage collector, and this is how it applies to tech.” Bring up concrete examples of why your experiential knowledge is going to be helpful, while communicating effectively and, most critical of all, concisely — don’t drag out trying to explain things. Practice practice practice, because to speak concisely is not usually a skill people come by naturally. Hone your conversational skills with your friends and family, as well. If you can make a technical subject fun to hear about and easy to grasp for your non-tech people, you’re definitely on the right track.
When performing a skills test, never be afraid to ask questions.
From my personal experience, I never did a skills test like they prepare you for in bootcamp (the dreaded whiteboard test). However, I found a lot of value in practicing the whiteboard test because it helps me even today as a software engineer. Identify what’s truly being asked of you, challenge assumptions, ask the reviewer if this will need to be in a specific big O notation, and ask if there are any edge cases to consider in the code that they’ve asked you to write. Make it painfully clear what the inputs and expected outputs are, and do not be afraid to ask questions, especially when the angle you want is to understand the problem as perfectly as possible. That’s what a good engineer does.
You never know what the skills test might be, so be ready for anything
Skills tests that I had been given over the years included a written essay on the importance of observability and accessibility in web design, then another skills test was actually a take-home test where I was writing a few back-end operations in a language that I had only looked at a few times and had to estimate how long it would take me. One time for an interview I was given a color by numbers worksheet and was told to follow the instructions specifically … they wanted to see if you could follow instructions. You just never know what they’re gonna throw at you, so be ready for anything, keep an open mind, and keep calm. List out what you know, what you don’t know, and how you’re going to find it.
If I could go back and give myself any pieces of advice before starting my job search, there are four things I would say.
- Nerves will eat your brain’s bandwidth; that’s just how it works. It’s okay to have nerves, but do everything you can to shake them off and let what you have learned shine. Ultimately, I got to a place where even if I really wanted and needed a job, I would approach the interview with this mantra: “The worst they can say is no. They won’t take away my birthday.”
- Laugh a little, especially at yourself. If you take things too seriously, you’re gonna be in a bad place mentally, and you should avoid that negative place with all your might. Remember that rejection is just redirection to the place that will appreciate your skills, talents, and qualities as an employee.
- Watch out for major red flags when interviewing your potential employers! For example:
- If you’re a person who needs work-life balance, don’t be afraid to ask them what they see as work-life balance. If they scoff at the question or don’t answer it, smile and thank them for their time and move on. It is often not a good idea to try to stick a square peg in a round hole; everyone’s just going to be miserable — your employer’s going to be miserable, and you’re going to be miserable. Set your boundaries.
- If your interviewers seem scattered and barely interested that you’re there, that is a huge red flag. You’re walking into a hostile work environment. If you do take the job, keep looking for that next job because this one will probably not last very long.
- Never take a job if you’re the only one. If you’re just starting out in your software engineering career, you will progress faster working around a team of other SWEs and learning from their techniques, thought processes, and areas of expertise. Because this job is an art and a science, the way you learn is you have to get feedback. You get immediate feedback from the computer, but you also need constant feedback from your peers.
- Finally, when you’re job searching, it’s ultimately a numbers game. Send out your resume to any job listing that interests you and for which you meet at least 25–50% of the job requirements. When I was going through, I would see something that said I need to know C++. I should have applied to those jobs because, who knows? Maybe they would have said “well, you know everything else, we can handle you teaching yourself.” You just need one yes, even if it’s application number 200. Don’t dwell on the no, focus on how to get a yes.
And lastly, remember: you’re not alone in this, and you don’t have to go it alone.
A lot of times, it helps to have a buddy when you’re doing something difficult — if nothing else, somebody to listen to you and validate your frustration, happiness, or whatever you’re feeling. While you’re looking for a job, stay with the bootcamp buddies you made along the way. They may end up getting you a job sometime in the future. They may be able to make an introduction that changes your career. Again, it goes back to networking, but the other thing is that they’re in the same boat as you. So they can offer validation, or they can offer alternative methodologies to things that maybe have changed in the past. Keep your coding buddies around as long as you can in order to get through it, because it is a difficult process.
Attending a Climb partner bootcamp and ready to get to the next stage in your career? Sign up for our free ClimbTalent career development platform to access job listings, resources and tools, mentorships, and more!