My Software Engineering Interview Preparation

I debated for some time whether or not I should make a post about this. By no means am I a top-notch interviewee. I have had my fair share of failed interviews. However, I did begin to notice a few patterns and tricks that are serving me quite well. Using these techniques, I eventually landed offers at both Amazon in Washington DC and Bloomberg in New York City.

Although I cannot share any specifics due to nondisclosure agreements, I can share many of my general techniques. Because of these two offers, I figured it would be helpful for others if I shared my study plan and methods. I hope you find this helpful!

Resources

First things first, finding a good class or curriculum to follow is key. I found a mix of these resources to be best as I could refer to many sources on any given topic. Some of my favorites include:

  • AlgoExpert: Great for coding question explanations and practice. The data structures content is also excellent in teaching you the breadth of what is required in the context of coding interviews.
  • SystemsExpert: This is great for their practice problems and their Design Fundamentals course. It helped give me a strong foundation although, I didn't really have a systems design interview.
  • Cracking the Coding Interview: The Holy Bible of coding interviews. A great resource to have.
  • LeetCode: My platform of choice for coding practice. Buying the premium subscription and sorting questions by company and frequency was helpful. More on this later.
  • freeCodeCamp: Great for adding to your resume and learning some new skills.

Organization

I probably spent a total of 6 months studying. The first 4 months were admittedly staggered, but it's very important to get your feet wet early and begin challenging yourself. Given I had only been given a 2-month notice to prepare for my coding interviews, I decided it was important to get organized as quickly as possible. You can use any method you want, but I ended up using a Notion database that contained all the new topics I needed to learn, the coding questions, the system design concepts, pictures, company-specific information, and behavioral question answers all in one place. I highly recommend you look into Notion to do this. I used the Kanban-style board to track whether it was completed, in progress, or not started. I cannot recommend Notion enough + it's fun!

Here is an example of my notion board with some of the technical concepts I learned.

Programming Languages

Do yourself a favor and learn python. It is so easy to write your algorithms and you can avoid so many syntactical mistakes. Most people tend to tell you to code in whatever language you are most comfortable in (and this is true), but I would focus on python if you have the time. Not enough time? Stick to your preferred language and try python the next interview cycle.

Data Structures and Algorithms

This the bread and butter of coding interviews. Without knowing your fundamentals you're just not going to get very far. I am going to layout the exact topics I learned and what exactly you need to learn for each one. Do not skip any of these points, learn them completely. This is not a comprehensive list as these topics can get very deep. I found AlgoExpert's data structures crash course to be really helpful in keeping things concise.

  • Memory
    • What are the primitive types? How do primitive types take up memory? Are they mutable or immutable? What does mutating, adding, or removing do to the variable in memory?
    • Find a simple way to break this down. Doesn't need to be complex. A simple grid to represent blocks of memory is good enough.
  • Logarithms
    • Everything is done in log base 2 in computer science. But does anyone know what that means? You should. I had a computer science degree and I don't think I ever learned how logarithms applied to computer science. This is crucial to understand.
  • Big O
    • Plenty of resources that will teach you this. Learn what it is and all the types of time and space complexities that exist. Additionally, learn which time complexities tend to correspond to each data structure. For example, logarithmic time tends to correspond with tree data structures.
    • Space complexity is important too so don't forget that. Although it is simple enough, it can get tricky as the problems get more complex. Look into call stacks in recursive algorithms and understand how this affects space complexity.
  • Recursion and Iteration
    • For loops vs while loops.
    • How does recursion differ from iteration? What is a call stack and how does this affect the space complexity? Does tail recursion occur in your language and if so how does this affect the space complexity?
    • Which is easier to write in the given time frame and which is easier to explain?
  • Arrays and Matrices
    • The time complexity of adding and removing elements in an array. how does this look in memory based on your specific programming language? For example, python lists are dynamic so what happens to the time complexity when we need a bigger array?
    • What are the ways you can iterate through an array and manipulate the data? How do you do all of the above in a 2D matrix? Can you go through them backward in an efficient manner? Make sure you know the syntax of this incredibly well.
  • Strings
    • Similar to arrays in many ways as it can be treated as an array of characters. However, they are different in many other ways. Are they mutable in your preferred language? If so, constantly adding and removing elements in a string may be costly. What are the tradeoffs? Maybe using an array of characters is better.
  • Sorting
    • Some people will argue that you need to know how to implement most of the sorting algorithms, however, I never really learned this and I ended up fine. I still understood how most of them worked conceptually (especially merge sort and quick sort) but nothing more specific than that. I would also make sure you know the time complexities for all of these and what sorting algorithm does the built-in sorting library use in your coding language. You will probably use it a lot.
  • Linked Lists
    • Bread and butter of data structures. How do you build them? How do you traverse them? Time complexities and space complexities. How can you combine this with other data structures (certain problems have multiple data structures)? These are common easy level questions so I would know linked lists like the back of your hand.
  • Hash Tables and Sets
    • My favorite data structure. That O(1) time complexity does wonders. When in doubt throw a hash table at the problem and it usually saves you in some way. Figure out how to explain this to an interviewer. How do you initialize, add and remove elements? What is the key and what is the value? How do you define hashing in simple terms? Are the elements in a hash table ordered? What happens to repeat elements in a set?
    • Do you know what collisions are? What are ways that we can handle collisions?
  • Stacks and Queues
    • Incredibly important to know and especially easy to implement in python (another reason to learn python). Look into how to implement and manipulate each of them. Also, how do they tie into common algorithms such as BFS and DFS? What's the difference between LIFO and FIFO? Look into the deque library if you are using python.
  • Trees and Binary Search Trees
    • Trees can get complicated but it is often asked about the most in interviews. You need to know all of the ins and outs of these data structures and their variations. Insertion, deletion, search time, and construction are what I recommend you know for AVL trees and binary search trees. Also look into pre-order, in-order, and post-order traversals.
  • Graphs and BFS/DFS
    • DFS and BFS traversals are the name of the game for graph-type problems. You might get a problem similar to Dijkstra's algorithm but usually knowing BFS or DFS will do the trick. Know exactly which elements will be searched first until you reach the end of the graph.
    • Know your exit conditions for each of these algorithms. Are you going until you reach a target or are you going through the whole graph? What data structure is needed for each algorithm? What are the time and space complexity?
  • Heaps
    • Heaps are a bit difficult to learn but turned into one of my favorites really quickly. You need to understand how they are constructed and how to quickly whip them up in a coding interview. In python, this is very easy using the heapq library. What is the time complexity for inserting, searching, and constructing? How is a heap different than sorting? What's the difference between a min-heap and a max-heap?
    • Also, look into priority queues!

I broke up most concepts into separate notion pages with detailed notes, drawings and code examples.

Interviews

The number of interviews you do will vary depending on the company. And given any interview season, you may want to apply to 50+ companies you may be interested in. This will help give you the best possible odds of landing a job with the total compensation that you are looking for. In my experience, the interviews are pretty standard among all companies.

After passing your initial resume screen you will usually be presented with some form of an online coding assessment. After that, you will go through a phone screen (may or may not include a coding question). Finally, you will go for your onsite interview which can have up to 3+ coding rounds in addition to HR and manager rounds.

Going through all of these interviews simultaneously is daunting, but I tried to make the most of it. There were times where I was incredibly stressed but I tried to take things step by step. My advice is to take any interview that comes your way. At the very least, the interview will be good practice. Even if you find that you are unprepared, the only thing you can do is give it your best effort and use it as a learning experience. If you fail, then most companies will let you try again in 6 months anyway, only this time you will already know what the interview is like!

Coding Questions

Ultimately, passing the coding questions is really all that matters. Depending on the company they may focus more on your problem-solving ability or they may focus on getting the correct solution. Regardless, you want to make sure you get the question as correct as you possibly can. This usually means:

  1. Asking clarifying questions
  2. Explain your initial thoughts... what is the first solution that comes to mind?
  3. Not mandatory but I usually write a brief outline of the algorithm using comments
  4. Listen to your interviewer for any hints and collaborate with him/her. Make sure they understand your solution and how you will implement it.
  5. Implement the algorithm explaining time complexities and data structures as you go. Be collaborative.
  6. Reiterate the time and space complexity when you are done coding.
  7. Run through your code line by line using a test case.
  8. Identify things you might have done better if you had more time.
  9. Ask them if they have any questions about your algorithm.

If you follow these steps exactly you will more than likely pass the interview. You may even pass the interview if you got the algorithm wrong. Again, different companies look for different qualities in their candidates but this can be broken down into a formula. Use the points I made above as a framework and adjust depending on the specific company you are applying for. Some of the nuances about a specific companies' hiring process can be found online in forums like LeetCode or Glassdoor.

Additionally, some companies are partial towards specific data structures in their questions. Using Leetcode, find out what this data structure might be (trees for example) and study it more rigorously. You won't be able to know everything but this is about increasing the odds that you get a question that is favorable to you during the actual interview.

If you don't know the answer to the question then your best bet is to start from the beginning and explain your thought process as much as you can. Explain where and why you are getting stuck and pay attention to any hints that the interviewer gives you. If you get stuck all the time then you might need to go back and study some more. However, if you only mess up in one interview and make it through the others then you should be ok as long as you explained yourself properly and made progress.

Behavioral Questions

I don't know if this is just me but I find this to be the easy part. Even if you haven't prepared for these types of questions you can usually give a basic enough answer from memory that will satisfy the interviewer. More often than not, this is more to see if you say the wrong things rather than the right things. Don't say anything too out there and you shouldn't raise any red flags. Take your time when answering, but think it through and give an answer that is short and sweet. Some companies may have specific behavioral questions that they like to ask so if you find out what it is in your research then you should prepare the answer beforehand.

If you struggle with these types of questions I would recommend finding a list of the most common interview questions and writing a brief answer to each of them. This will help give you some things to go off of when the real interview comes.

Conclusion

I hope you found this informative and helpful. I also want to say that luck is a factor. If there is one important lesson I have learned from interviews (and life), it's that sometimes you can do everything right and still get it wrong. This is not your fault, it's just the way the cookie crumbles. I would like to reiterate that I am not some interview guru, but I did find some success in this space so I thought it was worth sharing. I still have a lot of things to work on myself and I hope to make more posts like this once I figure them out. Don't give up and good luck!