I recently began speaking with a student from my Alma Mater about preparing for his career after college. The below information is a slightly altered version of the email that I sent. While some of the information is specific to Java development, most of the information can be applied to programming interviews in any language.
As you become a more experienced programmer, you’ll learn that there’s no problem that you can’t solve as long as you’re able to use Google and think hard. Unfortunately, you won’t have that luxury when you’re in a job interview. At this time, it’s important to have a good grasp on the concepts involved in the programming language you’re interviewing in (in this case, Java). Fortunately, you don’t have to be perfect because every software engineer spends more time on Stack Overflow than they’d like to admit.
Control statements are a given in every language you use. Typically, I’m able to write a loop with conditional statements in a language that I don’t know just because there are so many similarities between every language. From my experience interviewing, you’ll typically see four types of questions:
- Language Trivia – The majority of these questions are canned and you can find sample questions by doing a search for “java interview questions.” These questions test that you have put in the time to learn the language that you will be working in.
- Data Structure Trivia – This may consist of implementing a data structure, determining which data structure is best for a stated problem, or solving a problem with a specific data structure. Being able to do these things at a moment’s notice make you more effective when designing algorithms.
- Algorithm Design – Often times, you will be given a problem that is vague that you have to draw out on a whiteboard. When I say “draw out”, I mean you will have to write the code in a programming language rather than pseudocode to show that you know the language. It’s okay for you to have a few syntax errors since you are likely nervous and no one’s perfect.
- Behavioral - These are the questions that help an interviewer determine whether or not you are a good fit for his or her team. Some behavioral questions include, “tell me about a time when you had trouble communicating with a co-worker on a project” and “where do you see yourself in five years.” When an interviewer asks these questions, they never have a specific answer that they would like you to give them. You want to speak honestly to the interviewer because they may use your response to dig deeper into your thoughts. It’s a lot easier to speak genuinely than it is to create a story on the spot.
To prepare for the above questions, I recommend the following:
- Long Term – Try to do side projects to gain knowledge and experience. As you work on different problems, you will discover new libraries. This will not only prepare you for job interviews, but also make you more efficient on future projects. By working on different projects, you will also be working your brain and making yourself a better problem solver. As you progress through your career, you’ll start seeing problems that look very familiar because you’re able to abstract previous solutions and apply them to many problems.
- Approaching an Interview – There are a ton of great books out there that will prepare you for programming interviews. Choose one and work through the problems. I believe the library has some of them. Two books that I found very helpful were this one and this one.
To more specifically answer how to know you’re a strong Java programmer, you should know these things:
- The concepts of the object oriented paradigm and be able to discuss how they’re used in Java
- How to implement different data structures
- All of the collections interfaces (Set, List, Map, etc) and their implementations (HashMap, LinkedList, HashSet, etc). You should know when to use each collection.
- The common core Java packages. Some of these include java.io, java.util, and java.util.concurrent. The last package I listed is used for threading, which is a topic that may not be brought up in a junior engineer interview.