Tech Interview Tips is the companion app to Programming Interviews Exposed, the original technical interview preparation book, now in its third edition!
The tips and advice in this app help you prepare for your interviews with leading companies such as Amazon, Facebook, Google and Microsoft, as well as thousands of startups and other software firms that use the technical interview format.
Be sure to check out the Quick Interview Reminders section before you interview to review key concepts!
Find out why technical interviews are different from regular job interviews.
Read Chapters 1 and 2 of Programming Interviews Exposed for even more details about the technical interview process!
Tech companies want:
How do they find these people? It's not easy!
A candidate's resume provides some initial indicators. For example, does the person:
These are the kinds of questions that employers use to screen candidates who are obviously unqualified for a software development position.
But even a stellar resume doesn't mean that the candidate knows how to code. That's why employers use technical interviews to find out if a candidate actually knows how to program.
A technical interview (also called a programming interview) is a special type of job interview in which a software engineer asks you a series of programming questions to assess your skills and capabilities.
Technical interviews are separate from the "normal" interviews you have with recruiters to discuss salary, benefits, career path, and general job information. Technical interviews are all about determining if you can actually program — are you actually a skilled software engineer who can get things done and work independently as part of a team?
Most companies use a format similar to this for their technical interviews:
There are three broad categories of questions:
Consider the following before answering a question:
Good preparation is key to interviewing well. Here are some tips on how to prepare:
If you're not interviewing right away, take these extra steps:
On the day of your interviews, keep these tips in mind:
You've had the interview. It's over. Time to move on.
Did you prepare enough? Be honest with yourself. If you didn't prepare enough, do more preparation next time.
What if you don't get an offer? It's not the end of the world! Maybe:
If you want the job, most companies will let you try again later. But you'll have to wait a few months or a year.
The technical interview system isn't perfect. Many good candidates don't get an offer because they didn't do well in one of the interviews. The ideal job interview would have the candidates actually working at the company for a few weeks so that their true skills can be assessed. But who's going to do that?
Companies like the technical interview format because it keeps eliminates most of the poor candidates, especially those who look good on paper but don't actually how to code. Although some good candidates may be lost, from the company's perspective it's better to have false negatives than false positives!
Big-O analysis is a way to express the relative efficiency of an algorithm given an arbitrary number of input values. Big-O analysis counts the number of operations required to run the algorithm relative to the size n of input values. (An operation is a fuzzy concept, but it's normally something a computer can do in constant time.)
Big-O analysis concerns itself mostly with very large values of n. Many algorithms have similar running times when n is small. But when n is large, there is a huge difference in running time between something that takes n3 operations versus something that takes n operations.
Remember that you have three cases to consider: best-case, average-case and worst-case running times. Which case applies depends on the input data. You should calculate all three types.
Follow these steps to calculate Big-O:
Thus O(n2 + 4n) reduces to O(n2).
From best-to-worst performance:
Read Chapter 3 of Programming Interviews Exposed for more details about Big-O analysis.
The following are common types of linked lists:
Things you need to remember:
Read Chapter 4 of Programming Interviews Exposed for more details about linked lists.
In a tree, each node (data element) is referenced only by at most one other node, the parent node. (The root node is the node that has no parent.) The nodes referenced by a node are called its children.
In a graph, there may be multiple references to any given node.
A binary tree is a tree where each node has at most two children, often called the left child and the right child.
A binary search tree (BST) is a binary tree where each node holds a value and where the following rule holds: The left child's value is less than or equal to the node's value and the right child's value is greater than or equal to the nodes's value.
The height of a tree is 1 + the maximum of the height of the left subtree versus the height of the right subtree.
A balanced tree is one where for any given node the difference between the height of the left subtree and the height of the right subtree is 0 or 1.
Lookup is an O(log n) operation in a balanced binary search tree. In an unbalanced tree, however, it is an O(n) operation.
Deletion and insertion are O(log n) operations in binary search trees.
Read Chapter 5 of Programming Interviews Exposed for more details about trees and graphs.
The following is a list of common sorting terminology:
Starts with the first element, scans through the array to find the element with the smallest key, swaps it with the first element, then repeats with each subsequent element until the end is reached.
Not a great sorting algorithm, O(n2) for best, average and worst cases. But useful if swapping elements is an expensive operation because it requires at most n-1 swaps.
Builds a sorted array one element at a time by comparing each new element to the already-sorted elements and inserting the new element into the correct location.
Best case running time is O(n) if the list is already sorted, so it's a good way to add new elements to a presorted list. Average and worst cases are still O(n2).
A divide-and-conquer algorithm where you choose a pivot value from the data set and split the set into two subsets, the first subset containing all the values less than the pivot and the second containing all the values greater than or equal to the pivot. You apply this process recursively to each subset until there are no more subsets to split. The results are combined to form the final sorted set.
The choice of the pivot value is key to Quicksort's performance. It can be shown that always choosing the value in the middle of the set is the best choice for already-sorted data and no worse than most other choices for random unsorted data. So although the worst case is O(n2), the best and average cases are O(n log n), making Quicksort an excellent choice for most data.
A divide-and-conquer algorithm that splits the data into two or more subsets, sorts the subsets, and then merges them together into the final sorted set.
Merge sort is a good choice when the data set is too large to fit into memory. The subsets can be written to disk in separate files until they're small enough to be sorted in memory. The merging is easy, and involves just reading single elements at a time from each file and writing them to the final file in the correct order.
The best, average and worst case times for merge sort are all O(n log n), but it requires much more memory than many other algorithms.
Read Chapter 8 of Programming Interviews Exposed for more details about sorting algorithms.
Programming Interviews Exposed is the bestselling book devoted exclusively to preparing for technical interviews. It was the first book to focus on the unique challenges that software engineers face to land their dream job. Freshly updated for today's job market, the third edition of the book continues to provide its readers with practical and timely advice based on real-life situations and problems.
You can purchase Programming Interviews Exposed from all major booksellers. Printed and electronic versions are available.
Visit www.piexposed.com for more information about the book and its authors.
For questions about the app, contact Eric Giguere by email at firstname.lastname@example.org. Eric's Twitter handle is @giguere.
Keep up to date by joining the Programming Interviews Exposed mailing list! Visit www.piexposed.com/mailing-list/ to sign up.