Ultimate guide to land a junior software engineering job

Written on August 30, 2020
Categories: engineering

Over the years, I have got so many messages from students and friends about software engineering interview prep that I decided to end this conversation once and for all. I don’t promise it’s going to be concise but it will be bs-free. I am doing this primarily because getting on phone calls is so inefficient. I don’t always think about this stuff and I don’t prepare before the phone calls either. It’s more effective if I just gather my thoughts on this topic and do a brain dump once.

Do I have any credentials? You bet, I’ve been on both sides of the table and got a software engineering job right out of grad. I know what you should be doing and in what order.

TLDR; All the takeaways are written as block quotes if you want to just skim them. Let’s begin.

I’m assuming that you are looking for a junior job (internships or first full time out of grad/bootcamp) so that means you have some foundation in Computer Science. This is the only pre-req to continue with this interview guide. If you don’t have the foundation, first complete your undergrad studies (at least the first two years before internships or your bootcamp) before you go out there and embarrass yourself. I mean this. Even if you pass your interviews, you will fail miserably later on the job unless you have good enough fundamentals. I don’t care if you went to a college or a bootcamp, but please complete your studies (with the exception of internships) before you look for a job. There’s obviously the wonder kids who taught themselves more CS than any school could ever teach them before they reached college but I’m sure they have no problems getting a job so they don’t need to read this.

First, take a deep breath. I know it’s a cliche, but I have to say it. It’s a numbers game. There are so many factors in play that you have statistically a better chance if you interview at many places.

Landing your first software engineering job is a numbers game. Find out all the tech companies you are interested in and put them down in a spreadsheet. Don’t just apply to FANG companies, there are tons of medium-to-small-sized companies (not talking about startups) and they will come in handy even if you don’t decide to join them. All you need is a good track record for your junior job, you can apply to a better company down the road if you don’t get an offer as a junior.

What tech companies are there? You are lucky if you are based in the US. There are tons: Apple, Amazon, Microsoft, Google, Facebook, Uber, Lyft, Twitter, Spotify, Netflix, Yahoo, IBM, Mastercard, Visa, Nordstrom, Shopify, AmEx, Robinhood, Notion, LinkedIn, Tech-oriented banks, hedge-funs, Airbnb, Dropbox. The list is just too long for me to remember… Start making a list and filter only a few that you would absolutely hate to work at for whatever reason. Keep most of them around- we’ll get to the reason why.

Don’t apply to any just yet. First, we have to prepare. Don’t worry, this is not going to be a full big bang prep before you can apply to any company but if you are not battle-tested you will struggle with most of the interviews and will end up getting yourself recycled for 6 months (best-case), or 2-3 years (worst-case). We don’t want that. We want to land the job.

Lucky us there’s a great book written for software engineering interviews. It’s called Cracking the Coding Interview. It’s just like that one blue consulting book written for consulting interviews. It’s the Bible of software engineering interviews. Get a copy now.

Get a copy of the Cracking the coding interview and start reading. You should finish the book (or at least have skimmed every section) cover to cover before you interview the companies you are seriously interested in. You need to understand the art of interviewing by learning how to approach the questions and how you go about solving them. This book teaches exactly that, doesn’t just show you how to solve a laundry list of problems.

Once you have the book and skim a few chapters, you’ll get a feel of what the interview questions will look like. At this point, stop. We are not making the most of the questions in the book, yet.

Put away your computer, get a whiteboard, or a notebook. Do every single question on the paper or the board, thinking out loud as if you are asked this question in an interview and were to present your solution. Time yourself. Even better, get a friend or a peer and solve it in front of them. This will help you familiarize yourself with the uncertain environment by making you a little nervous due to peer and time pressure. They are all good things to practice. You are not going to solve these questions comfortably during the interview. You’ll be standing in front of a whiteboard (or over zoom i guess) with three interviews watching you and timing you.

Note for interviewing during covid: I realized most applicants don’t get an in-person interview anymore, so get ready to code on a google doc (not an IDE!) and whiteboarding with your mouse.

What makes you get hired? Simple. Interviewers checking-off boxes on their sheets. So what are those boxes? Those are the boxes that ensure you have the engineering mindset. Let’s go over each specific box in detail.

  1. Do you digest the technical question well?
    • Do you immediately try to solve the problem or reiterate the question, draw helpful stuff on the board, and ask clarifying questions? Do you wonder about the boundary conditions, do you ask about the exact requirements? What’s in scope - what’s out of scope?
    • Clarifying all the vague stuff will make interviewers check-off an important point. Ask questions, visualize the problem on the board, and always think out loud. It’s okay to take 10-20 seconds to think in silence and gather your thoughts but otherwise make it a conversation. Nobody expects you to come up with the answer right away, we just want to see how you think. Show us how you think.
  2. Can you solve the problem?
    • By this we don’t mean if you can immediately code it out. Do you even have an idea of how the algorithm should look like? Do you know at a high-level what data structures you will be using? Can you communicate the algortihm verbally? Tell us your idea and plan before you code.
    • Finally, code it up. Don’t stop talking while you code. Explain your thought process as you go.
    • Check your code for basic edge cases.
    • Quickly test your code with a few simple test cases. Describing what test cases you will run your code against will give you extra points.
  3. Can you defend your answer?
    • Sometimes, you will get asked why you designed the algorithm one way or another. Explain and also internally be suspicious of your answer. But if you are confident you did the right thing, stand firm for your decisions but back it up.
    • What are the trade-offs in the problem? Why did you make certain decisions over others?
  4. Can you optimize it?
    • More often than not, if you get the bruteforce approach right, (which you should always lay out first even if you can somewhat think of the optimum solution), you will be asked to optimize it. If you have no idea how, go back to the bottleneck. Why do you have to traverse X n times? Why do you have to do it n^2 times? Why do you have to use up that memory on the side? Can you do it inplace? Try to figure out what’s preventing you from optimizing it and again always exchange ideas with your interviewer, tell us what you are thinking even if you are stuck. Getting a few hints don’t hurt your ultimate decision. Interviewers would rather give you a hint than watch you get stuck for the entire interview. Try to solve it yourself by having a conversation without an explicit hint, if possible.

Most likely, as a junior candidate you won’t get a design question but if you do, figure out the exact requirements first and then focus on a few core use-cases and try to explain how you would architect and implement those pieces rather than trying to chew more than you can swallow. Figure out the trade-offs and talk about what decision would be impacted by them.

As you go through the cracking the coding interview book, always exercise those 4 things above. Once you get the hang of it, it’s heavy practice time. Solve as many questions as you need to feel comfortable – the more the better but at least finish the questions in the book. There will be difficult questions - but don’t get disappointed if you can’t solve them. Try to get all the easy questions right, do above average in medium ones, and at least be competent in difficult ones. The 4 things that interviewers want to hear will be much more important in the difficult ones. Aim for solving those hard questions with a few hints and some guidance.

OK, so where do we find the extra questions? Online, of course. There’s hackerrank and leetcode among a gazillion other websites. Last time I checked hackkerrank had a really nice question bank and an editor if you ever want to run through their test cases to see if you algo really works.

Once you start to realize you are getting comfortable with whiteboarding and talking through your solutions to your peers or to yourself in the mirror, it’s time to go out there and start having a few exhibition/scrimmage games. You shouldn’t wait until you solve all the question banks in the world (or not even finishing the book necessarily - but you will know when you are ready). This is where the original list of companies will come in handy. Rank the companies per your preference. Start applying to the ones at the bottom. Schedule phone calls and interviews. We are going to keep our favorite ones to a later time when we have a few games under our belt. This way, you are going to feel a lot less nervous about the big spots. Bonus points if you get an offer from the first ones, those will give you a morale boost and motivation for the next ones.

As you go through the interviews, don’t stop solving questions on the side until you get an offer from your tier-1 companies or a few of your tier-2 companies. Getting multiple competing offers will give you leverage and a leg up in negotiations.

As for the behavioral questions, have a few solid projects/classes in mind, and please don’t exaggerate your contributions. Interviewers know when you are BSing. Keep those behavioral answers simple and to the point. Follow the STAR format. As a junior candidate, your technical skills have the spotlight, just try to not get red-flagged in behavioral questions. As a junior candidate, your resume & cover letter don’t mean a lot, but definitely get them reviewed by another peer and make sure they are not “claiming anything you haven’t done”, consistent with your real experience and cover concrete things that you can actually talk about.

One other great resource is mock interviews.

A great website to practice your interview skills with real engineers is pramp. They hold mock interviews for you to practice. Take advantage of them and take the mock interviews just as seriously. People are basically donating their time and resources so be respectful and test your skills without risking a real offer.

If you ever realize during this process that you are lacking fundamental knowledge on core data structures, brush up on them. The algorithms usually follow the data structures so if you suspect you are missing some information, go review your CS books. Especially relevant are the arrays, maps, lists, stacks, and queues. Also important are trees and graphs but don’t worry too much about the advanced versions of those trees and graph questions (e.g. nobody is really going to ask you about Red/Black trees or B+ trees). Make sure you can also do bit manipulation and easy-to-medium dynamic programming. Object-oriented programming is another thing juniors are expected to know.

I intentionally didn’t talk about whether or not I find this type of coding interviews useful for the companies to find the right set of candidates. That is because a) it’s a longer topic and subject for another post b) it’s technically irrelevant to how successful you can be at these interviews.

Also, this is not how senior engineers are interviewed. I rarely talked about system design but I can come back to this later if there’s any interest. Most of the time, I get approached by juniors or students so I thought this would be more useful to my audience.

Finally, search on LinkedIn to see who’s working at the companies you want to work for and see if they are willing to put in a referral for you. This usually works better if they know you well and they work at a smaller company. Otherwise, don’t expect much from this. Also at best you will get your resume on the top of the pile, that’s it. You still have to do well in your interviews. When you reach out to the people, be respectful of their time, don’t write long emails (nobody got time to read them), and clearly highlight what you are asking and why.

Hope you find this guide helpful. If you have any questions or feedback, send me an email.