# Tech Interview Tips

Questions or comments?

Contact Eric Giguere

Version 1.0 — October 12, 2012

By Eric Giguere, co-author of

Programming Interviews Exposed

Now in its 3rd Edition! A Wrox Book, published by

John Wiley & Sons, Inc.

© 2012

Programming Interviews Exposed

Now in its 3rd Edition! A Wrox Book, published by

John Wiley & Sons, Inc.

© 2012

Tech Interview Tips is your quick guide to
prepare for technical interviews.

Questions or comments?

Contact Eric Giguere

Version 1.0 — October 12, 2012

**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:

**Skilled**software engineers- Programmers who can
**get things done** - Coders who
**work independently but as part of a team**

How do they find these people? It's not easy!

A candidate's resume provides some initial indicators. For example, does the person:

- Have (or is working toward) a relevant technical degree?
- Have good marks from college/university?
- Have relevant work experience?

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:

- Each interview is 30 to 60 minutes long. Expect a minimum of 3 to 5 separate interviews.
- The first 5 minutes are usually introductions and general chit chat.
- There are then 30 to 50 minutes of technical questions by the interviewer in which you stand at a whiteboard (or use pen and paper) and write out answers to the questions.
- The final 5 to 10 minutes is time for you to ask the interviewer questions.

There are three broad categories of questions:

**Algorithm questions:**Can you figure out*how*to do something and how to do it*efficiently*? Can you*measure*the efficiency of your algorithm?**Coding questions:**Can you write working, readable code?**System design questions:**Can you design systems that work together and scale?

Consider the following before answering a question:

**Make sure you understand the question.**Don't start answering until you do! A good way to do this is to repeat the question after rephrasing it slightly. Ask for clarification if you're unsure.**Use the programming language you're most comfortable with.**Unless the question requires a specific language, go with what you know. Even if the interviewer isn't familiar with the language, he or she can probably figure it out, or consult colleagues afterwards for clarification.**Verbalize your thought processes.**Don't just stand there and do nothing while you think about the problem. Talk about what you're thinking; discuss the pros and cons. Think out loud!**Aim for a general answer.**The question may be specific, but if you can generalize the answer you'll get extra points. Note that you may need to answer the specific question first to figure out how to generalize it.**If you don't know something, admit it.**The interviewer may give you a hint or move on to another question.

Good preparation is **key** to interviewing well.
Here are some tips on how to prepare:

**Read Programming Interviews Exposed**to learn how to interview and review basic programming concepts.**Study computer science textbooks**, particularly those relating to algorithms and system design.- If you don't have a textbook, consider purchasing
*The Algorithm Design Manual*by Steve Skiena. - Make sure you understand sorting algorithms and basic data structures such as trees and linked lists.

- If you don't have a textbook, consider purchasing
**Learn about the company culture**. This is harder for small companies, but for big companies such as Google and Facebook many books and articles are available that describe what it's like to work at those companies and what they expect of software engineers.**Write real code.**If you haven't been out in the work force yet, don't be satisfied with your school assignments — these are often simpler than real life coding.**Do some mock technical interviews.**Enlist a friend to ask you questions while you stand in front of a whiteboard.

If you're not interviewing right away, take these extra steps:

**Update your LinkedIn profile and resume.**- Ensure both are complete. Add lots of detail to your LinkedIn profile.
- Focus on the things you've
*accomplished*and try to express the*impact*of those accomplishments. - Highlight
*teamwork*and*independent work*— both are important! - Show
*career progression*.

**Build expertise.**- Answer questions (correctly!) on Stack Overflow and other sites.
- Write articles.
- Start and contribute regularly to a blog about programming topics.
- Work on open source projects.

**Sanitize your online profile.**- Get rid of the "bad" stuff.
- Change your privacy settings.

On the day of your interviews, keep these tips in mind:

**Don't cram.**Either you're ready or you're not. Review key concepts, but don't think you can learn everything you need that day.**Clear your calendar.**Don't do anything stressful immediately before or after the interviews.**Get a good night's sleep.**Actually, get*several*nights of good sleep!**Dress appropriately.**Suits aren't necessary, unless you're interviewing at a bank, but you still want to look good.**If you are sick, reschedule the interview.**You won't perform well and the interviewers don't want to see you if you're sick — they don't want to get sick, either!**Arrive early.**Go the washroom to refresh. Relax.

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:

- You just had a bad day. (It happens.)
- You just can't code in front of a whiteboard. (Practice it until you can.)
- One of your interviewers was having a bad day. (Nothing you can do about that!)
- The job's not for you.

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!

Going to an interview? Here are some quick reminders of key concepts.

The preceding topics are discussed extensively in Programming Interviews Exposed.

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 *n*^{3} 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:

- Determine the input and what
*n*represents. - Express the number of operations the algorithm performs
in terms of
*n*. - Eliminate all but the highest-order terms.
- Remove all constant factors.

Thus *O*(*n*^{2} + 4*n*) reduces to
*O*(*n*^{2}).

From best-to-worst performance:

- O(1)
- O(log
*n*) - O(
*n*) - O(
*n*log*n*) - O(
*n*)^{c} - O(
*c*)^{n} - O(
*n!*)

Read Chapter 3 of Programming Interviews Exposed for more details about Big-O analysis.

The following are common types of linked lists:

**Singly linked lists:**Each data element has a link (a pointer or reference) to the element that follows it.**Doubly linked lists:**Each data element has a link to the element that follows it and a link to the element that precedes it.**Circular linked lists:**A singly or doubly linked list that has no end.

Things you need to remember:

- Track the head (start) of the list.
- Update the head (and the tail, if you track that as well) whenever you add or remove items from the start (or end) of the list.
- Watch for null pointers.

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:

- A
*key*is the value (or values) that determines the sorting order. - An
*in-place*sort does not use any additional memory to do the sorting. Swapping elements in an array is an example of in-place sorting. - A
*stable*sort preserves the relative order of otherwise identical data elements. In other words, if two data elements have identical values, the one that was ahead of the other stays ahead of the other after sorting. - A
*comparison*sort requires only that there is a way to determine if a key is less than, equal to, or greater than another key. Most sorting algorithms are comparison sorts and the worst-case running time for such sorts can be no better than O(*n*log*n*).

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(*n*^{2}) 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(*n*^{2}).

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(*n*^{2}), 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 eric@piexposed.com. Eric's Twitter handle is *@giguere*.

For questions about *Programming Interviews Exposed*,
contact the authors by email at
authors@piexposed.com or
via the contact form on www.piexposed.com.

Keep up to date by joining the *Programming Interviews
Exposed* mailing list! Visit www.piexposed.com/mailing-list/
to sign up.