As discussed, our interviews include topics such as coding, data structures, algorithms, computer science theory, and systems design. We recommend you spend some time exploring our website to get into the right mind frame. Google Publications is a good starting point.

http://research.google.com/archive/gfs.html
http://research.google.com/archive/bigtable.html
http://research.google.com/archive/mapreduce.html

This gives you a good idea of what we look for in our interviews - http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/

This details how we do research at Google - Google's Hybrid Approach to Research - http://cacm.acm.org/magazines/2012/7/151226-googles-hybrid-approach-to-research/fulltext

Books to assist you in preparing for your interview:

• Programming Interviews Exposed: Secrets to Landing Your Next Job, Authors: John Mongan, Noah Suojanen, and Eric Giguère (Wiley Computer Publishing)
• Programming Pearls, Author: Jon Bentley
• Introduction to Algorithms, Authors: Cormen, Leiserson, Rivest & Stein

Please review the following topics:

Big-O notations also known as "the run time characteristic of an algorithm". You may want to refresh hash tables, heaps, binary trees, linked lists, depth-first search, recursion. For more information on Algorithms you can visit:
http://www.topcoder.com/tc?module=Static&d1=tutorials&d2=alg_index

Coding:

You should know at least one programming language really well, and it should preferably be C++ or Java. C# is OK too, since it's pretty similar to Java. You will be expected to write some code in at least some of your interviews. You will be expected to know a fair amount of detail about your favorite programming language.

Also make sure to check out our Google code style guides (C++/Python): http://code.google.com/p/google-styleguide/

For Java we don't publish anything official, however we base it heavily on this: http://www.oracle.com/technetwork/java/codeconv-138413.html

There is also an Android style guide that is quite similar: http://source.android.com/source/code-style.html

To practice for your interview you may want to visit the website www.topcoder.com If you launch the "Arena" widget and then go to the practice rooms where you can play with the problems in the first/second division as a warm up. Also: http://projecteuler.net/ - these are some math-related programming questions' vs topcoder, which tends to be more programming-oriented.

Sorting: Know how to sort. Don't do bubble-sort. You should know the details of at least one n*log(n) sorting algorithm, preferably two (say, quick sort and merge sort). Merge sort can be highly useful in situations where quick sort is impractical, so take a look at it.

Hashtables: Arguably the single most important data structure known to mankind. You absolutely should know how they work. Be able to implement one using only arrays in your favorite language, in about the space of one interview.

Trees: Know about trees; basic tree construction, traversal and manipulation algorithms. Familiarize yourself with binary trees, n-ary trees, and trie-trees. Be familiar with at least one type of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree, and know how it's implemented. Understand tree traversal

Algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder.

Graphs: Graphs are really important at Google. There are 3 basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list); familiarize yourself with each representation and its pros & cons. You should know the basic graph traversal algorithms: breadth-first search and depth-first search. Know their computational complexity, their tradeoffs, and how to implement them in real code. If you get a chance, try to study up on fancier algorithms, such as Dijkstra and A*.

Other Data Structures: You should study up on as many other data structures and algorithms as possible. You should especially know about the most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem, and be able to recognize them when an interviewer asks you them in disguise. Find out whatNP-complete means.

Mathematics: Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other companies because counting problems, probability problems, and other Discrete Math 101 situations surrounds us. Spend some time before the interview refreshing your memory on (or teaching yourself) the essentials of combinatorics and probability. You should be familiar with n-choose-k problems and their ilk – the more the better.

Operating Systems: Know about processes, threads and concurrency issues. Know about locks and mutexes and semaphores and monitors and how they work. Knowabout deadlock and livelock and how to avoid them. Know what resources a processes needs, and a thread needs, and how context switching works, and how it's initiated by the operating system and underlying hardware. Know a little about scheduling. The world is rapidly moving towards multi-core, so know the fundamentals of "modern" concurrency constructs. For information on System

Design:

http://research.google.com/pubs/DistributedSystemsandParallelComputing.html

Helpful links:

• http://www.google.com/support/jobs/bin/static.py?page=gettingintogoogle.html
• http://www.youtube.com/watch?v=w887NIa_V9w
• http://www.youtube.com/lifeatgoogle
• http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html

A few last tips:

• Talk through your thought process about the questions you are asked. In all of Google's interviews, our engineers are evaluating not only your technical abilities but also how you approach problems and how you try to solve them.
• Ask clarifying questions if you do not understand the problem or need more information. Many of the questions asked in Google interviews are deliberately underspecified because our engineers are looking to see how you engage the problem. In particular, they are looking to see which areas leap to your mind as the most important piece of the technological puzzle you've been presented.
• Think about ways to improve the solution you'll present. In many cases, the first answer that springs to mind isn't the most elegant solution and may need some refining. It's definitely worthwhile to talk about your initial thoughts to a question, but jumping immediately into presenting a brute force solution will be received less well than taking time to compose a more efficient solution.

Thank you so much professor.