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.

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