As a very high level, I suggest 4 major areas of study for a technical interview:
Most interview code challenges encompass at least two of these areas; good puzzles will test most of these areas within a single puzzle.
When given a coding question, it’s a good idea to start out by restating the problem in your own words; be descriptive. This will give you a little time to think about the problem and start forming some questions for the interviewer. Sometimes you’ll come up with assumptions about the problem or data payload, and you should explain these assumptions to the interviewer so they understand your approach for a solution.
Asking questions throughout the problem is good, but try your best to think of questions before you begin – it’s possible that an answer you’re given to a question mid-way through your solution could alter your desired solution.
AKA “how do you model data?"
Many questions of this nature will revolve around persistent storage and will look at things like how you relate data across different objects or database tables. As an interviewer, I’m looking for best practices around object-oriented design such as abstraction or inheritance, good use of design patterns, and so on.
Occasionally, these questions will be standalone, ie “Design an object-oriented parking garage” and could be purely verbal or some sort of block diagram – always ask how they’d like this work to be presented.
My advice for these kinds of problems: start with broad strokes and fill in detail later. My best analogy for this is to treat design problems like Bob Ross would treat a painting: he doesn’t start by drawing happy little trees, he starts with the sky and a lake then fills in mountains and clouds and rocks and then fine detail. Don’t get caught up focusing on just one area, or you may run out of time without letting the interviewer know that you had ideas for other areas.
from Jason Noble: Feel free to ask your interviewer questions along the way. If we’re designing the parking garage, you might ask “Will the lot accept monthly parking passes?” or “Will there be a parking attendant, or an automated payment machine?” The point here is to show that you can think about a given modeling problem and come up with relevant questions to help facilitate the design of the solution.
To practice design problems, look at the world around you and think of how you would create that thing in an object-oriented way. Perhaps the keyboard in front of you is a good example: each key could be an object, but could also inherit important attributes like whether it’s an alphabetic/numeric key or a Function key, or the power button or mute button.
AKA “how do you store data?"
There’s a philosophical debate as to whether “generics” data types like integers and strings are considered data “structures”. I’m in the camp of “anything that can store data in a structured way is therefore a data structure” but many believe that only the more complex storage mechanisms are true data structures such as hashes, binary trees and so on.
When you have no formal education in Computer Science, you’re less likely to be asked about complex data types such as binary trees or graphs, but they may ask just to test your breadth of knowledge. It’s okay not to be an expert at implementation of these complex types, but understanding how they work in your language of choice will be very helpful. Explain what you do know, and how you would go about learning more if you needed to.
What is this data structure really good for? What is it not good for? Answering these questions can sometimes lead to better algorithm choices (covered next), so learning about the complex structures will be very helpful.
To get started, visit BigOCheatSheet.com and find the section on data structures. You don’t need to memorize all of the Big-O notations on the site, but if you click on the names of the data structures you should end up at Wikipedia where you can learn about the data structure. Read up on the following data structures to get a sense of what the data structure is commonly used for and where its performance suffers:
AKA “how do you access/manipulate data?"
This is one of the most critical parts of any coding challenge and are almost always combined with some sort of data structure. You can often find a solution using a simple approach, but performance may suffer if you choose the wrong data structure, and choosing the wrong data structure could also make the algorithm impossible to solve.
My advice for algorithm based questions is summed up in three letters: MVP
In software, we often build the Minimum Viable Product (MVP) for proof of concept code and also to ensure that we’re not over-engineering anything.
In many cases, coding puzzles are usually 15-minute problems; that is, you should be able to solve the problem in 15 minutes or less. You can usually tell from the description of the problem and a few moments of problem solving breakdown whether the challenge is small or large. Smaller questions sound like “find two numbers that add up to a third” or “reverse all words in a sentence but not the order of the words” or “show me how to join two tables that meets the following criteria” and so on. Larger problems will sound like “write an app…” or will involve working with large data sets.
It’s WAY better to write ugly code quickly that solves the problem, and then have a chance to optimize the code than to be clever at the start and not get a solution at all.
Let me repeat that: don’t start out being clever. Start simple.
It’s always great when a candidate can self-critique their own code and say things like “I’m not happy with the performance” or “I think I see some places where I could optimize my code”, but only do that after you’ve found a solution to the problem. Companies who care about optimized code will be happy to hear your ideas or see you refactor your code, so don’t be afraid to ask for extra time to improve your code if you’ve solved it in under 15 minutes.
Sometimes you’ll get blocked when thinking of an appropriate algorithm. It’s important that you at least get started somewhere. Try writing out some pseudocode to get the ball rolling.
If the problem came with a set of data, don’t assume that’s the only data you’ll use to test your work. Ask questions up front about the data you’re given to make sure you understand the scope. For example, if you’re given an array of numbers, you could ask if this is a typical sample size, or a small sample size. How big could the array be? Are the numbers always randomized or sorted? Could they ever be all negative? Are numbers unique in the list? If so, could they ever not be unique, and so on.
Once you’ve solved an algorithm question, your interviewer may discuss your solution or ask questions about your approach. They may present other data for your algorithm, they may present edge cases that change portions of your algorithm.
Communication is critical when solving these types of problems. Explain what you’re doing, why you’re doing it, and ask clarifying questions as early in the process as you can.
AKA “how do you think about data?"
Many years ago, Google was famous for asking silly problem solving questions that gave them insight into how well you can break down a problem, like “how many golf balls fit in a school bus?”. Many other companies followed suit because the questions seemed goofy enough to break the ice and lower candidates' stress levels by thinking of something abstract.
After several years of testing this, Google later published an article about how those questions never helped them find quality candidates because everyone had a different answer, and so they moved into questions that were more deterministic such as “what is the 10,001st prime number?” Now they can still get you to break down a problem, but there’s only one right answer.
To practice these kinds of questions, check out https://projecteuler.net/archives where you’ll see number 1 on the list is the infamous “FizzBuzz” problem. While many of these problems are heavy in math (“Sum Square Difference”), some of them are quite approachable for breaking the problem into smaller pieces, such as “Counting Sundays” (count the number of Sundays since Jan 1, 1990 given the rules for leap years etc)