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. Following is an outline of the study modules:

  • 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
  • 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.
    • Regexes: For the most part, a subset of scripting, but knowledge of regexes is often a key part in many different programs.
  • Binary: Ultimately, everything on a binary computer is bits and a Software Engineer must understand the fundamentals of binary.
  • 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.
  • 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.
  • Data Structures and Algorithms: Originally, I had this broken up into two sections. However, the two are tightly coupled, in that you must use specific data structures with certain algorithms. So, it makes sense to describe the data structures in the same section in which they are used.
    • 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.
    • 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.
  • 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 interpret and run your code.
  • 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.
  • Programming Languages: Following are links to study questions and answers for specific programming languages
  • Software Engineering Theories, Laws, and Best Practices

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.