Studying for a Software Engineer Technical Interview

This section of the guide is devoted solely to the preparation and study for the technical part of the interview. Years ago, I found Steve Yegge’s article ‘The Five Essential Phone-Screen Questions’ and used it as a starting point for developing a study curriculum. Over the years I have expanded it a bit, but the core concept is similar.

Technical Interview Topics

Following are the basic technical interview topics that you will encounter during the technical phase of the interview process.


There are a number of different methodologies that companies will use for technical vetting. In my opinion, if they do not ask to you to write code, either in the form of a homework assignment or a live, online exercise of some sort you should be wary.

The typical options that I have seen are

  • Algorithm challenge: This is the typical LeetCode, HackerRank algorithmic challenges. You will need to do some study and prep for these. Not something that you typically find yourself doing in day-to-day software engineering, but there are many places that are convinced that if you can solve these sorts of challenges and bang out the code in 30 – 60 minutes you are an awesome Software Engineer. There are other pages on the site dedicated to what to study and how to prepare. There are two basic kinds
    • Live: You will get on a video call with another Engineer and they will give you a problem and ask you to write code to solve it.
    • Self-directed:
  • Homework Problem and Walk-through: You will be given a specific homework assignment and asked to build a program that solves a task and send it to them for review. If they think the code is sufficiently decent (and that you didn’t just ask some generative AI to write it for you) they will get on a call with you to talk it through. Typically, they will ask you to give them a walkthrough and then they will ask you to refactor something on the fly to see if you actually understand what you are doing and wrote the code.
  • Debug and fix broken code: You will be presented with some currently broken and/or poorly architected code and asked to make it work and then refactor it to be better.
  • Ad-hoc, show me how this works: Another technique that I have seen is when a technical discussion will start regarding a question about specific feature of a language and regardless of your answer the interviewer will ask you to try it out/show you how it works. This usually leads to you writing code, live, while the interviewer asks you more questions and asks you to edit the code and run it while you work through it. There are two basic ways that this can go:
    • They want to see if you know the minute details of a language and its features. In my opinion, this is pretty much a deal-breaker. It means that they are just hiring for a very specific skill in an specific technology and are not going to try to figure out if you are a decent Software Engineer or understand any of the basic principles.
    • They want to see if you understand the basic principals of software engineering and can sketch together something in the specific language that is a good starting point for a program.

System Design

Technical Leadership and Management

Study Areas

  • Algorithms: An algorithm is defined as a process or set of rules to be followed in calculations or other problem-solving operations, especially by a computer. A Software Engineer must have a basic understanding of the theory of algorithms, Big O notation, and the run time and memory requirements of an algorithm as the input data grows. Search algorithms are good to study as permutations of search problems are typically asked during the interview.
  • BASH and Scripting: In addition to knowing Linux, a Software Engineer must be familiar with command line scripting. Without getting into a discussion as to what the best shell language, my focus is on BASH. Primarily because it is the default shell on the most popular distros and as a result the most widely used.
  • Basic Coding: You must be able to write code, in a language of your choice, with the correct syntax such that it could be compiled and run. I’ve done many an interview writing code on a whiteboard, but more likely than not you will be writing it in an online tool that will be able to compile, and or interpre,t and run your code.
    • Java: Java is still one of the most popular, and valuable, programming languages. Following is an overview of the basic points to study should you be interviewing for a Java specific position.
  • Binary: Ultimately, everything on a binary computer is bits and a Software Engineer must understand the fundamentals of binary.
  • Computer Architecture and Operating Systems: A Software Engineer should be familiar with the basics of computer hardware, operating systems and how the two interface and work together. Understanding how the underlying hardware works very often influences the software architecture and design choices made when building systems.
  • Data structures are specialized means of storing and organizing data depending on the type of problem that you are trying to solve. A Software Engineer must have a solid understanding of the basic types of data structures and for which types of problems each is suited to help solve.
  • Linux: Ranging from basic usage of the OS to advanced System Administrator topics. Being able to navigate a Linux box is an essential skill for any Software Engineer
  • Networking: None of what a modern Software Engineer does happens on a single box. A good understanding of fundamental networking concepts is required to write just about any kind of program.
  • OO Design: Even though there are some languages such as Golang are not OO the staggering number of those that are, and the key design concepts that they embody require a Software Engineer to be well versed in OO principles.
  • Regexes: For the most part, a subset of scripting, but knowledge of regexes is often a key part in many different programs. Moreover, the value of regexes is hard to overstate in the context of Systems Administration and command line tasks.
  • SQL: A working knowledge of SQL and RDBMS is a must for Software Engineers. Even though there are many other query languages for different “database” implementations many of the core concepts are the same and the ubiquity of SQL requires a good understanding of it.
  • System Design:
  • Theories, Laws, and Best Practices

Preparing for the Technical Interview and Things to Keep in Mind

  • Take the day off. DO NOT go to work that day. You will want to have a clear head and not be distracted by your current obligations or worried about having to get back to something at work that day.
  • Get a good night’s rest. Eat a healthy dinner and get to bed at a reasonable time. Don’t watch or read anything stressful that might stir up your emotions or get your mind racing that evening. If possible, schedule things with your family so that you can wake up naturally after your body has had enough sleep.
  • Ask questions and ensure you know the requirements for what you are asked to solve:
    • Ensure that you completely understandthe problem that you are asked to solve. Sometimes problems are presented that are purposefully vague and are designed to see if you are thinking through all of the details and the interviewer wants to see what kind of clarifying questions you will ask.
    • For algorithm problems look at all of the test cases provided and the expected answers to ensure you understand the requirements and if it is not absolutely clear, ask questions.
    • Before writing a single line of code, completely design your algorithm on a whiteboard and walk it through with multiple input scenarios. Include all of the data structures that you will use and even write out the methods and functions to ensure that it will generate the desired results. If this takes 1/2 of your allotted time, so be it. Writing out the code once you sort out the algorithm is the easy part and you should be able to bang that out fairly quickly if you have properly designed everything. If you start writing code too soon, you may have gone down the wrong path and will have wasted time. This is just like an essay test; the first thing is to write the thesis and identify your main arguments. Then outline your arguments. Once you have your outline, writing it is easy.

General Study Resources for Software Engineers

Following are some great resources and ideas about how to study, practice, and teach yourself how to be a good software engineer

  1. Practice Drill #1: Write your resume. List all your relevant skills, then note the ones that will still be needed in 100 years. Give yourself a 1-10 rating in each skill.
  2. Practice Drill #3: Go to Wikipedia’s entry for computer science, scroll down to the “Prominent pioneers in computer science” section, pick a person from the list, and read about them. Follow any links from there that you think look interesting.
  3. Practice Drill #4: Read through someone else’s code for 20 minutes. For this drill, alternate between reading great code and reading bad code; they’re both instructive. If you’re not sure of the difference, ask a programmer you respect to show you examples of each. Show the code you read to someone else, and see what they think of it.
  4. Practice Drill #5: Make a list of your 10 favorite programming tools: the ones you feel you use the most, the ones you almost couldn’t live without. Spend an hour reading the docs for one of the tools in your list, chosen at random. In that hour, try learn some new feature of the tool that you weren’t aware of, or figure out some new way to use the tool.
  5. Practice Drill #6: Pick something you’re good at that has nothing to do with programming. Think about how the professionals or great masters of that discipline do their practice. What can you learn from them that you can apply to programming?
  6. Practice Drill #7: Get a pile of resumes and a group of reviewers together in a room for an hour. Make sure each resume is looked at by at least 3 reviewers, who write their initials and a score (1-3). Discuss any resumes that had a wide discrepancy in scoring.
  7. Drill #8: Listen in on a technical phone screen. Write up your feedback afterwards, cast your vote, and then talk about the screen with the screener to see if you both reached the same conclusions.
  8. Practice Drill #9: Conduct a technical interview with a candidate who’s an expert in some field you don’t know much about. Ask them to explain it to you from the ground up, assuming no prior knowledge of that field. Try hard to follow what they’re saying, and ask questions as necessary.
  9. Practice Drill #10: Get yourself invited to someone else’s technical interview. Listen and learn. Try to solve the interview questions in your head while the candidate works on them.
  10. Practice Drill #11: Find a buddy for trading practice questions. Ask each other programming questions, alternating weeks. Spend 10 or 15 minutes working on the problem, and 10 or 15 minutes discussing it (finished or not.)
  11. Practice Drill #12: When you hear any interview coding question that you haven’t solved yourself, go back to your desk and mail the question to yourself as a reminder. Solve it sometime that week, using your favorite programming language.

Reading List

  • The Art of Computer Programming, Donald E. Knuth
  • The Art of Error Correcting Coding, Robert H. Morelos-Zaragoza