Introdution

Here’s the thing: to become a software engineer, you don’t actually need to know how to code.

Hi, my name is Kira. I got my first full-time programming job when I was 16. When I was 19, I got a job at Facebook. Now I’m 22. And I might be a relatively inexperienced engineer — and human for that matter — but if there’s something I can talk about with some authority, it’s getting that first job as a self-taught programmer.

Because, you see, I myself have been through the wringer. The words “unprepared” and “unqualified” don’t even come close to describing my goofy teenage self in my first interviews. Forget not knowing the answer; I could barely to the receptionist. I was not waltzing into corporate office like some young confident mega-nerd prodigy. No, I was just an awkward kid, with an untested skillset, no experience, and no charisma.

But I improved. I got my first job. I got my second. And the third time I job hunted, despite a covid-infected job market, I was able to get a smorgasbord of job offers of my choosing.

So, I’m writing this article to break down and demystify the interview process, and then give you some tips on how to win at it. It will teach you how to hack interviews by understanding the bare minimum you need to do in order to pass 80% of them. If you’re really hungry for that first (or next) job, then you’ll want to pay attention.

“You Don’t Need to Know How to Code”

The reason I started off by saying this, despite it being a slight exaggeration, is because it represents what I consider to be the most important advice I have about interviewing: it’s a skill. It’s not a reflection of your programming ability. It’s not a mystical process which methodically reveals your shortcomings. Interviewing and programming are two separate things, and the best way for you to land a job is to focus on improving your interviewing skills — not your programming skills.

The reason I think this idea is so important is because online advice about interviewing is always the same old droll. “Make an open source contribution!” they cheer. “You need a side project”, they say. “Learn two programming languages! Build a portfolio! Learn about data structures and algorithms! Get Elon to retweet you! Go vegan and find your true passion in life!”

Yada yada yada. There’s truth to these things. But the problem is, this advice always fails to clarify why and to what extent the advice should be followed. On my own journey, I always felt that it left me with more questions than answers. Should I make an open source contribution? Is one pull request enough? Should I make a personal website? Will people notice that it has bugs? Does it need to include a blog? Does it matter which tools I use? So on, and so forth. If you find yourself going down these trains of thought, as I myself have done many times, know this: you’re wasting your time. You’re thinking about it all wrong.

If we truly start from first principles, getting your first programming job doesn’t require any kind experience. It has nothing to do with your side projects, or how good you are as a programmer. It simply has two requirements:

1. Land an interview
2. Pass an interview

That’s it, period, full stop. So if you’ve ever thought to yourself, should I make an open source contribution? Allow me to, for once, provide you with a straight answer: only if you’re going to talk about it in an interview.

The same goes for anything else you decide to do. Should you make a personal website? Only if you’re going to talk about it in an interview. Should you work on a side project? Only if you’re going to talk about it in an interview. Should you learn about compilers? Take a guess.

Frankly, when it comes to entry-level programming jobs, the answer to most of these questions is going to be a hard no. You don’t. Tech interviews are notoriously formulaic, and the interviews for entry-level jobs are especially so. So forget all the noise. You don’t need crap except for 1–2 hours of talking points, and to be able to answer common interview questions. If you want to become a better programmer, you can do that after you find a job.

So if that’s all making sense, let’s get started. I’m going to break the interview process down step-by-step, and then give you advice on how to beat each step.

How to Land an Interview

To land an interview, you first need to understand how companies hire. This is a rough sketch of the process:

To be clear, “landing an interview” constitutes everything leading up to actually being interviewed, meaning:

1. Application screen, where your application is screened by an automated system and/or a recruiter
2. Recruiter screen, where a recruiter calls you and talks to you on the phone

Beating the Application Screen

If you’re like me, resume screenings (automated or not) can be the hardest part of the entire process. In fact, I found this to actually be completely impossible during my first job hunt — I probably sent somewhere in the ballpark of 100–150 applications, to companies of all sizes, in all kinds of industries, and I didn’t get a single response. Not one.

So, you probably want to try to bypass this step. Here are two ways to go about this:

Hiring platforms, depending on how they work, can help you bypass resume screenings altogether. I had an awesome experience and got several offers using TripleByte. There’s also Hired.com, which got my friend his first job at PayPal (also at age 16). Then there’s interviewing.io, which not only landed me several onsite interviews but was also great for practicing. I can vouch for these three personally, but there are definitely more out there — try getting scrappy and see what you find.

Outreach to real people is pretty much your only other option, if you can’t get past application/resume screenings. This means finding engineers and recruiters on LinkedIn, Twitter, wherever, and DM’ing them asking for referrals or to be noticed. Believe it or not, this is a decent tactic that can work pretty well depending on the company’s referral policy. For example, when I was at Facebook the referral bonus was $5k — so if I gave someone a referral, and Facebook ended up hiring them, I got $5k. These incentives make it so doing this cold outreach isn’t that much of a long shot; you’ll for sure get a few bored people to help you out.

Beating the Recruiter Screen (Over the Phone)

This is the next step in the hiring process: the recruiter screen, where you get on the phone with your recruiter for 30-ish minutes and they ask you random questions about what’s on your resume. I’m going to be honest. I have no idea what recruiters try to accomplish in these, other than verify that you’re a real person and not severely disturbed or something. I’ve been on dozens of them, none memorable. I’ve never been rejected after one, either. Don’t worry about these.

How to Pass an Interview

So for the actual interviews, here’s how they work:

First, you go through a technical screen. This is an hour-long session where your interviewer will ask you an algorithm & data structure question.

If you pass that, it’s onto the onsite interview. This usually consists of 3 or 4 hour-long technical interviews — each pretty to similar to a tech screen — and one behavioral interview. I’m going to break down what types of questions you should expect during both of these, and then I’ll give you some advice on how to beat them.

What to Expect in Technical Interviews & Screens

The majority of the interview process is made up of technical interviews. The majority of technical interviews are made up of algorithm and data structure problems. And (I kid you not) the majority of algorithm and data structure questions I’ve been asked were word-for-word in the book Cracking the Coding Interview. That book is, without a doubt, where you should start preparing for technical interviews.

Now this might come as a bit of a surprise, but think about it. You’re being interviewed by engineers. It’s not their job to come up with novel questions for interviews, so why would they? Odds are, each of your interviewers has a single favorite question that they re-use in every interview, and it’s not very unique. The exception is huge FAANG-level companies with tons of resources, but even then, they’re only going to ask you things that are covered conceptually in Cracking the Coding Interview. So read the f’ing book! Trust me: if you get through every algorithm and data structure section in that book (you can skip the other chapters), you’ll be ready to rock most technical interviews.

In addition to algorithm and data structure questions, most onsite interviews will include one live-coding exercise where you actually build something like a simple website or app — for example, for a frontend interview you might be asked to build tic-tac-toe using React. For these questions coding experience actually starts to matter, but just remember: you don’t need to have some cool website to show or anything like that. All you need to be able to do is write code comfortably for an hour. Practice a few of these.

Finally, in a very, very distant third place for the most common types of questions you’ll get, is the “system design” question. If you find yourself struggling with these, honestly, don’t bother. They’re not really relevant to junior dev positions, and they’re not asked frequently because they’re kind of weird to evaluate. You don’t actually have to demonstrate technical ability during these — you just talk about stuff. Over a few dozen technical interviews, I was only asked a system design question a single time.

What to Expect in Behavioral Interviews

This is it! The time is nigh! Your soul which you gave to your portfolio; the many open source contributions and GitHub stars and side projects which you ceaselessly toiled over; they have all led you to this glorious moment! Behold, the behavioral interview!

I joke, but only to hide the pain. Oh, the time that I spent poring over my personal website! Only for it to be talked about a bit in a couple of behavioral interviews, then thrown in the trash. The good old behavioral interview. One hour to answer open-ended questions about your life and work experience. These interview sessions vary a lot, but one thing is for certain: your past work experience, no matter how little of it you have, will come up. So what are you going to say?

At this point the whole spiel I gave about “not needing to know how to code” becomes relevant, because I’m going to repeat what I said then: all you really just need an hour of material. Can you talk about stuff you’ve worked on in the past for an hour? If you’ve can do that, you’re good.

Also, this might go without saying but I want to make sure it’s said: get along with your interviewers. They don’t just evaluate your abilities, they also evaluate whether or not they’d want to work with you. If you need help with this, try Charisma on Command, it’s a YouTube channel that unironically helped me develop social skills when I was younger lol.

Summary: How to Pass Interviews

If there’s one thing that summarizes the entirety of this section, it’s this:

Practice what’s going to be on the interview. Screw everything else.

Over the years, I’ve seen so many junior devs and bootcamp grads pour their precious time and effort into personal websites and other random projects, hoping this one feature will somehow make the difference between being hired and not. Don’t do that. Despite outward appearances, tech interviews are actually very systematic. Methodical. Rigid. You can learn how to game them. Interviewing is a skill, and you should be practicing it until you’ve mastered it; then after you have the security and environment of a job, you’ll be in a much better position to work on improving your programming skills.

Beyond that, here are the most important things I want you to remember from this article when it comes to beating the interview:

• Algorithm and data structure questions make up the vast majority of every interview process. To prepare for them, make sure you cover everything in Cracking the Coding Interview, and when you’re done practice on LeetCode.
• The next most common questions are live-coding problems. To prepare for them, find a few online and practice them by timing yourself.
• For the behavioral interviews: prepare by having at least 1 hour’s worth of talking points about past programming experience. This is the area where side projects and things like that matter.
• Get along with your interviewers.

Conclusion

Obviously, there is a lot more to software engineering than this. Also, just to be clear, I love software and I’m passionate about engineering. You are going to have a hard time succeeding in programming if you’re not willing to put in a lot of practice and work.

At the same time, you might also need a job. And if you do, that’s probably a lot more important right now than improving your programming skills. A lot of other advice online seems to confuse the two––“getting a job” with “becoming a better programmer”––and basically what I’m trying to tell you in this article is that they’re two separate things.

-Kira. Connect with me on Twitter ❤