Two years ago, I decided to radically change my career from nonprofit STEM education to software engineering. I had no background in coding, outside of a single programming class in 7th grade and a little HTML when I was a teenager. I entered a coding bootcamp, Ada Developers Academy, in January 2018 and had full-time software engineering offers from two of Seattle’s tech giants in December of the same year.

Being a nontraditional Black female software engineer, preparing for the interview process began as a terrifying and mysterious endeavor. Through much study, practice, and creativity, I eventually became a confident interviewer, capable of landing the same roles as new graduates with Computer Science degrees.

While there’s plenty of interview advice out there, nontraditional software engineers often require a bit of a different approach. Here are some tips and tricks that I accumulated along the way to my first engineering position

Learn the Basic Data Structures First

The key to almost all coding problems for junior engineers is identifying the correct data structure for the solution. Many people learning to solve coding problems start by working the problems themselves. This approach makes it much more difficult to understand the “why” of the solution and to notice patterns in the types of solutions. Rather than diving straight into the problems, start by gaining a firm understanding of all of the most common data structures: arrays & strings, hash tables, linked lists, stacks & queues, and trees & graphs.

There are many books and written resources for learning data structures (I’ll talk about one later), but trying to learn through only reading about them was confusing and frustrating for me. I figured out that the better approach was to use YouTube to find multiple explanations of each data structure. I gained a foundational understanding this way, then went back and started reading written explanations to fill in the gaps.

Make Sure You’re Starting With the Easy Problems

This might seem obvious, but I’ve noticed that it isn’t necessarily clear to everyone. Some people jump right into trying to solve random problems without being sure of whether they are easy, medium, or hard. For the first problems I started solving, I went to LeetCode, which has a huge amount of free coding questions and solutions available in several languages. You can easily filter questions by difficulty and data structure. I initially picked a couple of problems, searched YouTube for example solutions, then tried to solve them on my own. Once I’d gotten familiar with the general process of solving the questions, I switched to attempting the problem first, then watching the solution.

Memorize Patterns, Not Problems

I noticed several of my peers attempting to memorize individual solutions to all of the specific problems they encountered. This will make your life so much harder and I honestly think it just won’t work. Interviewers are familiar with the wording and details of all the common coding challenges out there, so they will almost never ask you an exact question that you’ve practiced. So, instead, pay attention to the similarities between different questions with similar answers, so you can learn to spot the pattern in problems that require certain approaches.

For Example:

Contains Duplicate

Valid Anagram

One of the ways that both of these questions could be solved is using a hash table. Once you notice that problems like these two are basically the same thing at their core, you will be more prepared to recognize this type of solution when asked a similar question that you’ve never seen before.

Talk to Yourself!

I cannot stress this enough! You need to explain what you’re doing, and why you’re doing it, while you solve your problems! During interviews, your interviewer needs to know your train of thought at all times. I do this for two reasons, but I’m sure there’s even more justification for doing it.

The first reason I do this is because your interviewer must understand your problem-solving process and why you’re going from point A to point B in your approach. You do not want your interviewer to get lost trying to follow your solution! The second reason is that your interviewer might give you a couple hints to keep you on track if you get stuck. If your interviewer sees that your approach is 90% correct, but you’re just stuck on one little detail, they might give you a clue or ask a helpful question so you can move on and continue showing them your skills.

You. Always. Want. To. Be. Talking.

Watch examples of coding interviews to get a sense of how people speak while whiteboarding coding problems, then practice all the time. You don’t want the first time you speak while solving a question to be during an interview. It should be second nature.

Whiteboard Constantly

You should whiteboard at least several times a week for at least a few months. Before my first interviews, I practiced learning the basics of data structures for 3–4 weeks. Then I whiteboarded coding problems a minimum of 5 days a week, for 5 hours a day, for two months. I was able to cram so much practice into a short period of time because I was often able to whiteboard at my internship for 2–3 hours a day, then I would go home and solve more problems for a few more hours.

Most people don’t have this kind of time on their hands, so I suggest giving yourself a minimum of 5 months to prepare. During this time, you want to visit and revisit problems until you are confident at least outlining a potential solution and working through your approach to problems that need any of the common data structures.

Buy Cracking the Coding Interview

This isn’t an advertisement, I have no affiliation with the author or publisher of this book. Cracking the Coding Interview by Gayle Laakmann McDowell just happens to be the Bible of coding interviews and it’s a great resource… once you’re ready for it. As I mentioned before, I recommend watching YouTube videos as your first introduction to learning data structures and coding problems. Once you’ve got the basics down, Cracking the Coding Interview is a great go-to for written explanations of the entire interview process, coding problems, and system design problems.

The only real drawback to this book is that the solutions are solely written in Java. I had only coded with Ruby and JavaScript when I used Cracking the Coding Interview, so it’s possible to comprehend the solutions even if you’re unfamiliar with Java itself. It takes some time, but it did become readable to me after I spent a little while with it. It was definitely worth gaining readability in Java in order to use this book.

Mock Interview. A lot.

Mock interviews were vital to my success with interviewing. A mock interview is just a practice interview where someone asks you a question and you solve it doing everything you would do if it were the real thing. Ideally, you will work up to going through the process with questions you’ve never tried before.

Finding mock interviewers can be difficult if you aren’t surrounded by software engineers. It’s helpful to start with anybody you have around, but eventually, you’ll want some engineers. There are ways to find people to help! I recommend checking out Meetup in your area to see if there’s already an established coding interview prep group. Another option is to join tech-related Slack communities (here are 400 communities), which often have channels for people who are located in specific cities and regions. Just explain your situation and ask for people who are willing to volunteer to give you an hour of their time for a mock interview. Booking a room at a public library is a great way to find a place for this.

To practice the technical phone screen and behavioral questions, Pramp is an excellent free resource where you can practice interviewing with other software engineers. Mock interviews in Pramp use an environment that’s similar to what you will often encounter during your first technical interview before you are (hopefully!) invited on-site for your final interviews.

I completed 10 mock interviews and at least 5 Pramp interviews.

Don’t Start With Your Dream Job

If there’s a specific role or company that you have your heart set on, do not apply there first! The last thing you want to do is set yourself up for disappointment by going into your first interviews with everything on the line. Of course, any job is better than no job, but try to get interviews with your “so-so” positions scheduled for before you go after the ones that matter the most. You want to be as practiced, comfortable, and confident as possible when it’s time for the big one.

Early in my process, I intentionally applied to a few companies that I am ethically opposed to. My first on-site interview was with one of these companies and I went into it knowing that I was going to do my best, but I would never accept an offer there, even if they gave me one. This took a huge amount of stress out of the situation and let me become familiar with the real interview process before I showed up to my first interview for a position I really wanted.

---

These are only tips and tricks that worked for me during my interview preparation. I’m sure they’ll work for some, but maybe not for others. I’m also sure there are people out there who might disagree with my approach, but it worked for me!

If you’d like to hear more about my experience becoming a software engineer or let me know what’s worked for you, please drop a comment before you go!