Advice to non-traditional candidates looking for their first job

Every few months, a friend will ask me if I’m willing to talk to someone they know who is in a bootcamp, graduated from a bootcamp, or is a self-taught programmer. They’re looking for their first job and they want advice. I’m always happy to talk to someone and if you’re reading this and in that situation, you should feel free to hit me up. But I want to take some of my thoughts and write them down.

First a caveat, I’ve been writing code since I was 14. I took computer science in high school and majored in it in college (in a so-called “target” school for NYC tech). My own personal experience is very much the traditional route. But I’ve been interviewing engineers for nearly a decade and a hiring manager for the last several years. I’ve looked at thousands of resumes and screened or interviewed thousands of candidates. I’ve hired bootcamp grads and even picked a very talented Flatiron grad to replace me at my last role. What I’m trying to say is that I don’t have a bias against someone from a non-traditional background and I hope that eventually bootcamp isn’t even considered non-traditional in the startup world.

What you need to know

I can’t stand when folks say that a six-month bootcamp is equivalent to a four-year college degree in computer science. It’s not and if you think it is then you’re a big part of the problem. Yes, you can count raw credit hours as being similar but at least from my own program, I would spend days locked in a lab or library writing or debugging code. The sheer amount of time you’re actually writing code spans years. You also have time to allow certain concepts to get absorbed because many assignments are repetitive. Even if a bootcamp spent half it’s time just on data structures, that still wouldn’t come close to how many different classes I had that required some kind of assignment based on data structures and algorithms.

Luckily, you actually don’t need that many hours to become a valuable programmer. I don’t think I’ve ever needed to balance an AVL tree at work. I’m glad I learned about it because it was interesting but you’re ok to skip it. But you do need some of the fundamentals depending on your role. The other great thing about a bootcamp and to a lesser extent being self-taught is that you learn relevant and modern skills that I didn’t learn in college. So what you need to do is understand what role you’re applying for (frontend, backend, fullstack, mobile, QA, data, etc..) and make a list of the concepts you didn’t learn. I’ve had someone tell me that a frontend engineer doesn’t really need to know data structures. I would argue that you can’t tell me the difference between filter, find and map without understanding data structures. Those are some of the functions that are the bread and butter of a frontend engineer.

Don’t just read a book. You need to intuitively understand them. Actually sit down and write code. Do you understand the differences between a queue vs a stack? Well implement them in your favorite language. Write some code to see the performance difference if there is one. Try writing some real code using each one. Do this for everything you learn! Make sure it sticks. I can’t tell you how many people I’ve interviewed who know that they’re supposed to be using a HashMap because it’s the most efficient but then don’t actually know or remember how to use one. Yes, interviews are tough and I’ve forgotten many things while interviewing due to stress and pressure. But certain things just need to become a habit. They won’t if you don’t practice so much it becomes ingrained. I won’t go into the full list because many other people have written blog posts and books about it. Just make a list and get cracking.

Projects

I think it’s great to have some personal projects and it shows that either you really enjoy programming (always a plus) or you have the work ethic to sit down and complete a project without direct external motivators (obviously getting a job is a motivator). Personal projects only go so far though. Software engineering is a team sport and like most team sports you actually need to play with others to develop certain skills. There’s a reason some of the best one on one basketball players in the world don’t play in the NBA. So my advice here is actually to find an open source project you can contribute to. You’ll learn many relevant skills like how real code reviews work, dealing with a large codebase, explaining technical ideas in writing and working with others. Also some open source projects are run by people who can’t communicate well and learning the art of communicating with a difficult person is both an unfortunate reality and a necessary skill in this industry.

If you don’t feel comfortable or can’t find an open-source project you’re interested in (highly unlikely there isn’t something out there) then try something local. Maybe you can volunteer to build some software for a local business or charity with some friends. How about seeing if some of your bootcamp class wants to collaborate on something?

Sourcing

So you’re feeling good about your skills but need to actually get some interviews. First think about the kind of company you want to join. My personal recommendation is to find a startup big enough to have a good ratio of senior engineers but not so big that you get siloed to very specific tech. Though I don’t have first-hand knowledge, I’ve heard some of the big tech companies have good programs for non-traditional engineers. But you should decide for yourself what interests you most. Next make a spreadsheet of the companies that interest you. This used to be constrained by geography but increasingly your city of residence is becoming less relevant.

Now go on linkedin and reach out to folks at that company. Expect that many people won’t answer you and some will be very delayed (I get so many linkedin messages every day but I try to filter through the crap to answer genuine requests eventually). Do your research first. Nothing is worse than realizing that you’re talking to someone who has no idea what your company actually does. It’s going to take a lot of cold outreach to even get some interviews. Don’t get discouraged if they tell you they don’t have a role open. Most startups won’t. It’s not malicious. It’s just that most startups are already under-water on capacity and having a senior engineer spend a few months getting you up to speed is going to hurt the roadmap and their ability to deliver.

“But I don’t need that much attention” you’ll say. Yes you do. It’s the little things that you’ve never encountered before. How to decide what is good vs bad code review feedback. How to give a proper estimate when your product manager asks if you can get something done tomorrow. How to think about debugging your code across a much larger system than you’re used to. These things just take reps and time. Being a software engineer is so much more than just the code you write.

The interview

So you finally get an interview. That means they have the possibility of a role for you. Exciting! Don’t screw this up with unforced errors. That means do your homework. Ask your recruiter for advice on how to prep. Learn enough about the company that you can give an honest and meaningful answer about why you want to work there. “Because I like not starving and food costs money” is a fair answer but that won’t cut it. It’s ok if you care more about tech than mission or vice versa. Just sound like you’ve thought about it.

You will very likely have to write code for your interview. Lots of folks try and bang out the first 10,000 questions on leedcode. I think what’s important is that you feel comfortable with a language appropriate for interviewing. I strongly recommend javascript (which is basically the lingua franca of interviewing) but I’ve seen python and ruby work fine. I don’t recommend languages like Java or C# (aka Microsoft Java). You don’t want to be suffering through imports and compile errors while you’re trying to solve a problem. You can’t guarantee the editor they give you will have any features beyond basic text editing.

Know all the important features of the language. Do you really want to change your answer because you don’t remember how to remove something from an array? I’ve literally seen this happen and it sucks. Practice your language of choice until you don’t even need to think about the language and can focus on the algorithm you’re writing.

If a company asks you to do a take home, you have to decide whether you will accept. I personally strongly believe in them. It’s much fairer to folks who aren’t comfortable live coding and is closer to what you’ll be doing on the job. Not all takehomes are fair but mostly the ones I’ve seen have been fine. Give yourself enough time to complete it and ask questions early if something isn’t clear. Even if they don’t ask for any, write tests and add a good readme. If possible, make sure they can run your submission with one command. Explain your assumptions and reasoning. Add some of your personality to it. When you get to the onsite and need to run through the take home, make sure you re-familiarize yourself with your work. It might be days or weeks between the original work and the onsite. Make sure it runs. If you get to the onsite and your submission doesn’t run, it’s basically a hard no from me. Expect that they’re going to ask you to add something to it and practice. Maybe they ask you to change a feature or add a feature. Maybe there’s a bug you need to solve.

When it comes time for you to ask questions, don’t waste it selling yourself. Oftentimes I’ll see a candidate ask about the company culture and then spend a bunch of time telling me why they fit that. It has never convinced me to change my mind on my existing thoughts. This is your time to see if we’re a fit for you. It also shows me what you care about in a role. It’s totally fair to ask about your potential future boss, onboarding, training, culture, the team you would join and anything else you can think of.

Hired! Now what?

I’ll probably save this for another time but I do recommend you invest in yourself if you’re able to beforehand. Ask about the tech stack and do some prep. A few hours on youtube will actually change your first few weeks! Also make sure to ask everyone you talk to for advice on how to be successful and about their own experience.

Final notes

Pay it forward. That’s it. You’re going to make it if you stick with grinding to your first job but someone coming up after you is just starting their journey. Don’t make it difficult for them just because it was difficult for you. Advocate to hire non-traditional folks at your company. You’d be surprised how often there is a bias based on little to no information. But you must also respect your company’s situation. Recognize that your team just might not have the capacity at the moment. And finally, never lose the curiosity and passion that made you decide to learn to code in the first place. Good luck!