This link has been bookmarked by 397 people . It was first bookmarked on 13 Mar 2008, by someone privately.
-
15 Aug 19
-
06 Jun 17
-
20 Jan 17
-
08 Jan 17
-
Steven Skiena's The Algorithm Design Manual
-
you should ask them if they would like to see code.
-
One last non-technical tip: bring your own whiteboard dry-erase markers.
-
If so, just do your best. Worst case, you can always come back in 6-12 months, right? Might seem like a long time, but I assure you it will go by in a flash.
-
-
01 Nov 16
-
12 Jul 16
-
08 Jul 16
-
19 Nov 15
-
26 Aug 15
-
Algorithm Complexity
-
If you struggle with basic big-O complexity analysis, then you are almost guaranteed not to get hired.
-
Sorting
-
know the details of at least one n*log(n) sorting algorithm, preferably two (say, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical
-
don't try sorting a linked list during the interview.
-
Hashtables
-
arguably the single most important data structure
-
You should be able to implement one using only arrays in your favorite language
-
Trees
-
binary trees, n-ary trees, and trie-trees at the very very least
-
at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree.
-
tree traversal algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder.
-
Graphs
-
Graphs are, like, really really important. More than you think.
-
There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list)
-
basic graph traversal algorithms: breadth-first search and depth-first search.
-
You should try to study up on fancier algorithms, such as Dijkstra and A*, if you get a chance.
-
Whenever someone gives you a problem, think graphs.
-
Other data structures
-
You should study up on as many other data structures and algorithms as you can fit in that big noggin of yours. 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.
-
what NP-complete means.
-
Math
S -
basic discrete math questions
-
the essentials of combinatorics and probability. You should be familiar with n-choose-k problems and their ilk
-
Operating Systems
-
know about processes, threads and concurrency issues.
-
Know about 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
-
Coding
-
know at least one programming language really well
-
know a fair amount of detail about your favorite programming language.
-
The stuff I've covered is actually mostly red-flags: stuff that really worries people if you don't know it. The discrete math is potentially optional, but somewhat risky if you don't know the first thing about it. Everything else I've mentioned you should know cold, and then you'll at least be prepped for the baseline interview level.
-
-
21 Feb 15
-
28 Jan 15
-
Me: DUDE. The answer is Yes already, OK? It's an invariant. Everyone else who came to Google was in the exact same position as you are, modulo a handful of famous people with beards that put Gandalf's to shame, but they're a very tiny minority. Everyone who applied had the same reasons for not applying as you do. And everyone here says: "GOSH, I SURE AM HAPPY I CAME HERE!" So just apply already. But prep first
-
A classic example found everywhere is: Interviewer A always asks about C++ trivia, filesystems, network protocols and discrete math. Interviewer B always asks about Java trivia, design patterns, unit testing, web frameworks, and software project management. For any given candidate with both A and B on the interview loop, A and B are likely to give very different votes. A and B would probably not even hire each other, given a chance, but they both happened to go through interviewer C, who asked them both about data structures, unix utilities, and processes versus threads, and A and B both happened to squeak by.
That's almost always what happens when you get an offer from a tech company. You just happened to squeak by. Because of the inherently flawed nature of the interviewing process, it's highly likely that someone on the loop will be unimpressed with you, even if you are Alan Turing. Especially if you're Alan Turing, in fact, since it means you obviously don't know C++. -
You should feel good that you feel bad after this happens, because hey, it means you're human
-
-
19 Oct 14
-
Algorithm Complexity
-
Sorting: k
-
know the details of at least one n*log(n) sorting algorithm, preferably two (say, quicksort and merge sort).
-
Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work.
-
Trees:
-
You should be familiar with binary trees, n-ary trees, and trie-trees at the very very least.
-
You should be familiar with at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree
-
You should know about tree traversal algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder.
-
Graphs
-
There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list), and you should familiarize yourself with each representation and its pros and cons.
-
You should know the basic graph traversal algorithms: breadth-first search and depth-first search. You should know their computational complexity, their tradeoffs, and how to implement them in real code.
-
You should try to study up on fancier algorithms, such as Dijkstra and A*, if you get a chance. They're really great for just about anything, from game programming to distributed computing to you name it. You should know them.
-
ake absolutely sure you can't think of a way to solve it using graphs before moving on to other solution types. This tip is important!
-
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.
-
You should find out what NP-complete means.
-
-
11 Oct 14
-
you need to know Big-O. It's a must.
-
You should know the details of at least one n*log(n) sorting algorithm, preferably two (say, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical,
-
hashtables
-
There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list), and you should familiarize yourself with each representation and its pros and cons.
-
You should know the basic graph traversal algorithms: breadth-first search and depth-first search. You should know their computational complexity, their tradeoffs, and how to implement them in real code.
-
processes, threads and concurrency issues
-
Know about locks and mutexes and semaphores and monitors and how they work. Know about dea
-
dlock 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.
-
Doug Lea's Concurrent Programming in Java
-
-
09 Sep 14
-
21 Jul 14
-
The Algorithm Design Manual
-
encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail
-
Drink some coffee
-
spend at least an hour practicing immediately before you walk into the interview
-
If in doubt, you should ask them if they would like to see code
-
But some interviewers are really picky about syntax, and some will even silently mark you down for missing a semicolon or a curly brace, without telling you.
-
Ask if they care about syntax
-
ask a few clarifying questions
-
don't try sorting a linked list during the interview
-
Whenever someone gives you a problem, think graphs
-
livelock
-
Doug Lea's Concurrent Programming in Java
-
-
29 May 14
-
Whenever someone gives you a problem, think graphs.
-
-
25 May 14
-
But the gold mine is the second half of the book, which is a sort of encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail.
-
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.
-
You should find out what NP-complete means
-
Know about locks and mutexes and semaphores and monitors and how they work.
-
-
15 May 14
-
01 Apr 14
-
If you can do it on a whiteboard, every other medium (laptop, shared network document, whatever) is a cakewalk. So plan for the whiteboard.
-
1) Study a data-structures and algorithms book. Why? Because it is the most likely to help you beef up on problem identification.
-
So your best bet, interview-prep wise, is to practice the art of recognizing that certain problem classes are best solved with certain algorithms and data structures.
-
My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual.
-
Other interviewers I know recommend Introduction to Algorithms. It's a true classic and an invaluable resource, but it will probably take you more than 2 weeks to get through it. But if you want to come into your interviews prepped, then consider deferring your application until you've made your way through that book.
-
You should also practice whiteboard space-management skills, such as not starting on the right and coding down into the lower-right corner in Teeny Unreadable Font. Your interviewer will not be impressed.
-
Algorithm Complexity: you need to know Big-O. It's a must. If you struggle with basic big-O complexity analysis, then you are almost guaranteed not to get hired. It's, like, one chapter in the beginning of one theory of computation book, so just go read it. You can do it.
-
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, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical, so take a look at it.
-
Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview.
-
Trees: you should know about trees. I'm tellin' ya: this is basic stuff, and it's embarrassing to bring it up, but some of you out there don't know basic tree construction, traversal and manipulation algorithms. You should be familiar with binary trees, n-ary trees, and trie-trees at the very very least. Trees are probably the best source of practice problems for your long-term warmup exercises.
-
You should be familiar with at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree. You should actually know how it's implemented.
You should know about tree traversal algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder. -
Graphs are, like, really really important. More than you think. Even if you already think they're important, it's probably more than you think.
-
There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list), and you should familiarize yourself with each representation and its pros and cons.
You should know the basic graph traversal algorithms: breadth-first search and depth-first search. You should know their computational complexity, their tradeoffs, and how to implement them in real code.
You should try to study up on fancier algorithms, such as Dijkstra and A*, if you get a chance. They're really great for just about anything, from game programming to distributed computing to you name it. You should know them.
Whenever someone gives you a problem, think graphs. They are the most fundamental and flexible way of representing any kind of a relationship, so it's about a 50-50 shot that any interesting design problem has a graph involved in it. Make absolutely sure you can't think of a way to solve it using graphs before moving on to other solution types. This tip is important! -
You should study up on as many other data structures and algorithms as you can fit in that big noggin of yours. 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.
You should find out what NP-complete means.
Basically, hit that data structures book hard, and try to retain as much of it as you can, and you can't go wrong. -
Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other places I've been, and I consider it a Good Thing, even though I'm not particularly good at discrete math. We're surrounded by counting problems, probability problems, and other Discrete Math 101 situations, and those innumerate among us blithely hack around them without knowing what we're doing.
-
Your best will be a heck of a lot better if you 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.
-
This is just a plug, from me, for you to know about processes, threads and concurrency issues. A lot of interviewers ask about that stuff, and it's pretty fundamental, so you should know it. Know about locks and mutexes and semaphores and monitors and how they work. Know about 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, and you'll be a dinosaur in a real hurry if you don't understand the fundamentals of "modern" (which is to say, "kinda broken") concurrency constructs.
-
The best, most practical book I've ever personally read on the subject is Doug Lea's Concurrent Programming in Java.
-
You should know at least one programming language really well, and it should preferably be C++ or Java.
-
The best discrete math book I've ever read has to be "Concrete Mathematics: A Foundation for Computer Science" by Graham, Knuth, and Patashnik
-
-
07 Feb 14
-
20 Jan 14
-
22 Nov 13
-
My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual
-
Doug Lea's Concurrent Programming in Java
-
Concrete Mathematics: A Foundation for Computer Science" by Graham, Knuth, and Patashnik
-
-
07 Nov 13
-
25 Oct 13
-
01 Oct 13
-
22 Sep 13
-
11 May 13
-
29 Apr 13
-
11 Mar 13
-
Many interviewers are happy when you understand the broad class of question they're asking without explanation.
-
practice the art of recognizing that certain problem classes are best solved with certain algorithms and data structures
-
Steven Skiena's The Algorithm Design Manual
-
Introduction to Algorithms
-
Try to move (and write) quickly, since often interviewers want to get through more than one question during the interview
-
bring your own whiteboard dry-erase markers. They sell pencil-thin ones at office supply stores,
-
Big-O
-
know the details of at least one n*log(n) sorting algorithm
-
counting problems, probability problems, and other Discrete Math 101 situations
-
Know about locks and mutexes and semaphores and monitors and how they work. Know about 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.
-
-
07 Mar 13
-
05 Feb 13
-
23 Jan 13
-
24 Dec 12
-
07 Dec 12
-
11 Sep 12
-
09 Sep 12
-
05 Sep 12
-
23 Aug 12
-
22 Aug 12
-
02 Aug 12
-
29 Jul 12
-
15 Jul 12
-
11 Jul 12
-
26 Jun 12
-
30 May 12
-
you can't tell interviewers what's important
-
every "experienced" interviewer has a set of pet subjects and possibly
-
Instead, I want to prep you for some general topics that I believe are shared by the majority of tech interviewers at Google-like companies.
-
plan for the whiteboard.
-
The two best long-term warm-ups
-
if they ask you about coloring U.S. states in different colors, you get major bonus points if you recognize it as a graph-coloring problem, even if you don't actually remember exactly how graph-coloring works
-
The book also covers basic data structures and sorting algorithms, which is a nice bonus. But the gold mine is the second half of the book, which is a sort of encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail.
-
But if you want to come into your interviews prepped, then consider deferring your application until you've made your way through that book.
-
You should keep going until it is complete, no matter how tired or lazy you feel. Do this as much as you can possibly tolerate
-
Going through these exercises for a week prepped me mightily for my second round of Google interviews,
-
sure you spend at least an hour practicing immediately before you walk into the interview.
-
humble, open-minded, and focused
-
The best way to appear arrogant is to question the validity of the interviewer's question
-
Feel free to ask for help or hints if you're stuck.
-
Don't say "choo choo choo" when you're "thinking"
-
now." If in doubt, you should ask them if they would like to see code.
-
So ask. Ask if they care about syntax, and if they do, try to get it right.
-
don't take too long before actually solving the problem,
-
It's OK (and highly encouraged) to ask a few clarifying questions, and occasionally verify
-
will mark you down if you just jump up and start coding
-
The thin ones turn your whiteboard from a 480i standard-definition tube into a 58-inch 1080p HD plasma screen.
-
mark you down because they couldn't get a full picture of your skills
-
bring your own whiteboard dry-erase markers
-
you want minimal distractions during the interview
-
hashtables are arguably the single most important data structure known
-
You should especially know about the most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem
-
Whenever someone gives you a problem, think graphs
-
processes, threads and concurrency issues. A lot of interviewers ask about that stuff, and it's pretty fundamental, so you should know it. Know about locks and mutexes and semaphores and monitors and how they work. Know about 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, and you'll be a dinosaur in a real hurry if you don't understand the fundamentals of "modern" (which is to say, "kinda broken") concurrency constructs.
-
-
14 May 12
-
13 May 12
-
11 May 12
-
10 May 12
-
My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual.
-
Other interviewers I know recommend Introduction to Algorithms. It's a true classic and an invaluable resource, but it will probably take you more than 2 weeks to get through it. But if you want to come into your interviews prepped, then consider deferring your application until you've made your way through that book.
-
Algorithm Complexity: you need to know Big-O. It's a must. If you struggle with basic big-O complexity analysis, then you are almost guaranteed not to get hired. It's, like, one chapter in the beginning of one theory of computation book, so just go read it. You can do it.
-
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, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical, so take a look at it.
-
For God's sake, don't try sorting a linked list during the interview.
-
Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview.
-
Trees: you should know about trees. I'm tellin' ya: this is basic stuff, and it's embarrassing to bring it up, but some of you out there don't know basic tree construction, traversal and manipulation algorithms. You should be familiar with binary trees, n-ary trees, and trie-trees at the very very least. Trees are probably the best source of practice problems for your long-term warmup exercises.
-
You should be familiar with at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree. You should actually know how it's implemented.
-
You should know about tree traversal algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder.
-
There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list), and you should familiarize yourself with each representation and its pros and cons.
-
You should know the basic graph traversal algorithms: breadth-first search and depth-first search. You should know their computational complexity, their tradeoffs, and how to implement them in real code.
-
You should try to study up on fancier algorithms, such as Dijkstra and A*, if you get a chance. They're really great for just about anything, from game programming to distributed computing to you name it. You should know them.
-
Whenever someone gives you a problem, think graphs. They are the most fundamental and flexible way of representing any kind of a relationship, so it's about a 50-50 shot that any interesting design problem has a graph involved in it. Make absolutely sure you can't think of a way to solve it using graphs before moving on to other solution types. This tip is important!
-
You should study up on as many other data structures and algorithms as you can fit in that big noggin of yours. 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.
You should find out what NP-complete means.
Basically, hit that data structures book hard, and try to retain as much of it as you can, and you can't go wrong. -
Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other places I've been, and I consider it a Good Thing, even though I'm not particularly good at discrete math. We're surrounded by counting problems, probability problems, and other Discrete Math 101 situations, and those innumerate among us blithely hack around them without knowing what we're doing.
-
Don't get mad if the interviewer asks math questions. Do your best. Your best will be a heck of a lot better if you 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.
-
This is just a plug, from me, for you to know about processes, threads and concurrency issues. A lot of interviewers ask about that stuff, and it's pretty fundamental, so you should know it. Know about locks and mutexes and semaphores and monitors and how they work. Know about 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, and you'll be a dinosaur in a real hurry if you don't understand the fundamentals of "modern" (which is to say, "kinda broken") concurrency constructs.
-
The best, most practical book I've ever personally read on the subject is Doug Lea's Concurrent Programming in Java.
-
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.
-
-
07 May 12
-
But prep first.
-
These tips are actually generic; there's nothing specific to Google vs. any other software company
-
My hope is that by following them you will perform your very best during the interviews.
-
But prep first.
-
you can't tell interviewers what's important. Not at any company. Not unless they're specifically asking you for advice.
-
C++ trivia, filesystems, network protocols and discrete math
-
Java trivia, design patterns, unit testing, web frameworks, and software project management
-
We wipe the slate clean and start over again. There are lots of people here who got in on their second or third attempt, and they're kicking butt.
-
I want to prep you for some general topics that I believe are shared by the majority of tech interviewers at Google-like companies. Roughly speaking, this means the company builds a lot of their own software and does a lot of distributed computing.
-
Basically there is short-term and long-term warming up, and you should do both.
-
Long-term warming up means: study and practice for a week or two before the interview. You want your mind to be in the general "mode" of problem solving on whiteboards. If you can do it on a whiteboard, every other medium (laptop, shared network document, whatever) is a cakewalk. So plan for the whiteboard.
-
Study a data-structures and algorithms book
-
For instance, if they ask you about coloring U.S. states in different colors, you get major bonus points if you recognize it as a graph-coloring problem, even if you don't actually remember exactly how graph-coloring works.
-
practice the art of recognizing that certain problem classes are best solved with certain algorithms and data structures.
-
My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual.
-
More than any other book it helped me understand just how astonishingly commonplace (and important) graph problems are – they should be part of every working programmer's toolkit.
-
But the gold mine is the second half of the book, which is a sort of encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail.
-
Other interviewers I know recommend Introduction to Algorithms.
-
if you want to come into your interviews prepped, then consider deferring your application until you've made your way through that book.
-
Have a friend interview you. The friend should ask you a random interview question, and you should go write it on the board. You should keep going until it is complete, no matter how tired or lazy you feel. Do this as much as you can possibly tolerate.
-
Drink some coffee: it actually helps you think faster, believe it or not.
-
Make sure you spend at least an hour practicing immediately before you walk into the interview. Treat it like a sports game or a music recital, or heck, an exam: if you go in warmed up you'll give your best performance.
-
So! You're a hotshot programmer with a long list of accomplishments. Time to forget about all that and focus on interview survival.
-
Interviewers have vastly different expectations about code.
-
But some interviewers are really picky about syntax, and some will even silently mark you down for missing a semicolon or a curly brace, without telling you.
-
So ask. Ask if they care about syntax, and if they do, try to get it right
-
Look over your code carefully from different angles and distances. Pretend it's someone else's code and you're tasked with finding bugs in it. You'd be amazed at what you can miss when you're standing 2 feet from a whiteboard with an interviewer staring at your shoulder blades.
-
It's OK (and highly encouraged) to ask a few clarifying questions, and occasionally verify with the interviewer that you're on the track they want you to be on. Some interviewers will mark you down if you just jump up and start coding, even if you get the code right
-
One last non-technical tip: bring your own whiteboard dry-erase markers. They sell pencil-thin ones at office supply stores,
-
Algorithm Complexity: you need to know Big-O. It's a must. If you struggle with basic big-O complexity analysis, then you are almost guaranteed not to get hired. It's, like, one chapter in the beginning of one theory of computation book, so just go read it. You can do it.
-
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, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical, so take a look at it.
-
For God's sake, don't try sorting a linked list during the interview.
-
Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview.
-
Trees: you should know about trees. I'm tellin' ya: this is basic stuff, and it's embarrassing to bring it up, but some of you out there don't know basic tree construction, traversal and manipulation algorithms. You should be familiar with binary trees, n-ary trees, and trie-trees at the very very least. Trees are probably the best source of practice problems for your long-term warmup exercises.
You should be familiar with at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree. You should actually know how it's implemented. -
There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list), and you should familiarize yourself with each representation and its pros and cons.
-
You should try to study up on fancier algorithms, such as Dijkstra and A*, if you get a chance. They're really great for just about anything, from game programming to distributed computing to you name it. You should know them.
-
Whenever someone gives you a problem, think graphs. They are the most fundamental and flexible way of representing any kind of a relationship, so it's about a 50-50 shot that any interesting design problem has a graph involved in it. Make absolutely sure you can't think of a way to solve it using graphs before moving on to other solution types. This tip is important!
-
You should find out what NP-complete means.
-
Basically, hit that data structures book hard, and try to retain as much of it as you can, and you can't go wrong.
-
Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other places I've been, and I consider it a Good Thing, even though I'm not particularly good at discrete math. We're surrounded by counting problems, probability problems, and other Discrete Math 101 situations, and those innumerate among us blithely hack around them without knowing what we're doing.
-
Don't get mad if the interviewer asks math questions. Do your best. Your best will be a heck of a lot better if you 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
This is just a plug, from me, for you to know about processes, threads and concurrency issues. A lot of interviewers ask about that stuff, and it's pretty fundamental, so you should know it. Know about locks and mutexes and semaphores and monitors and how they work. Know about deadlock and livelock and how to avoid them. -
Know a little about scheduling.
-
The best, most practical book I've ever personally read on the subject is Doug Lea's Concurrent Programming in Java.
-
You should know at least one programming language really well, and it should preferably be C++ or Java.
-
You will be expected to know a fair amount of detail about your favorite programming language.
-
Everything else I've mentioned you should know cold, and then you'll at least be prepped for the baseline interview level.
-
Real-world work makes you rusty.
-
http://www.cs.cmu.edu/~15251/
-
-
27 Apr 12
-
The Algorithm Design Manual
-
-
18 Apr 12
-
17 Apr 12
-
08 Apr 12
-
25 Mar 12
-
04 Mar 12
-
22 Feb 12
-
study and practice for a week or two before the interview
-
-
10 Feb 12
Philip ChenDoug Lea's Concurrent Programming in Java
-
04 Feb 12
-
23 Jan 12
-
20 Jan 12
-
05 Jan 12
-
04 Jan 12
-
27 Dec 11
-
29 Nov 11
drfmunozhttp://www.google.com/support/jobs/bin/static.py?page=benefits.html
interview google career programming algorithms job interviewing
-
carlos puentesI've been meaning to write up some tips on interviewing at Google for a good long time now. I keep putting it off, though, because it's going to make you mad. Probably. For some statistical definition of "you", it's very likely to upset you.
interview google career programming algorithms interviewing job howto
-
26 Oct 11
-
23 Oct 11
-
19 Oct 11
keppettoJak przygotować się do rozmowy kwalifikacyjnej
interview google programming career jobs tips interviewing job blog
-
05 Oct 11
-
deadlock
-
livelock
-
-
01 Oct 11
-
Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview.
-
Trees: you should know about trees. I'm tellin' ya: this is basic stuff, and it's embarrassing to bring it up, but some of you out there don't know basic tree construction, traversal and manipulation algorithms. You should be familiar with binary trees, n-ary trees, and trie-trees at the very very least. Trees are probably the best source of practice problems for your long-term warmup exercises.
-
You should be familiar with at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree. You should actually know how it's implemented.
-
You should try to study up on fancier algorithms, such as Dijkstra and A*, if you get a chance. They're really great for just about anything, from game programming to distributed computing to you name it. You should know them.
-
You should study up on as many other data structures and algorithms as you can fit in that big noggin of yours. 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.
-
The best, most practical book I've ever personally read on the subject is Doug Lea's Concurrent Programming in Java. It got me the most bang per page. There are obviously lots of other books on concurrency. I'd avoid the academic ones and focus on the practical stuff, since it's most likely to get asked in interviews.
-
One little addition to the tech prep skills section would be dynamic programming - the tasks on this one appear to be quite common.
-
-
27 Sep 11
-
23 Sep 11
sac2171interview
-
20 Sep 11
-
23 Aug 11
-
22 Aug 11
-
08 Aug 11
-
28 Jul 11
-
01 Jul 11
-
11 Jun 11
-
26 May 11
-
The Algorithm Design Manual
-
Algorithm Complexity
-
n*log(n) sorting algorithm
-
Sorting
-
quicksort and merge sort
-
Hashtables
-
Trees
-
binary trees, n-ary trees, and trie-trees
-
basic tree construction, traversal and manipulation algorithms.
-
balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree.
-
NP-complete problems
-
knapsack problem
-
traveling salesman
-
find out what NP-complete means
-
discrete math
-
familiar with n-choose-k problems and their ilk – the more the better.
-
know about
-
processes, threads and concurrency issues
-
Know about locks and mutexes and semaphores and monitors and how they work.
-
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
-
deadlock and livelock and how to avoid them
-
scheduling
-
concurrency constructs
-
Doug Lea's Concurrent Programming in Java
-
Applied Combinatorics" (Roberts & Tessman)
-
http://www.cs.cmu.edu/~15251/
great lecture notes on discrete math on the wiki (for free).
-
-
25 May 11
-
design patterns
-
-
16 May 11
-
15 May 11
-
01 May 11
-
17 Apr 11
uygosmvAs for short-term preparation, all you can really do is make sure you are as alert and warmed up as possible. Don't go in cold. Solve a few problems and read through your study books. Drink some coffee: it actually helps you think faster, believe it or not. Make sure you spend at least an hour practicing immediately before you walk into the interview. Treat it like a sports game or a music recital, or heck, an exam: if you go in warmed up you'll give your best performance.
-
14 Apr 11
-
03 Apr 11
-
09 Mar 11
-
24 Feb 11
-
23 Feb 11
grobs456"Get that job at Google
I've been meaning to write up some tips on interviewing at Google for a good long time now. I keep putting it off, though, because it's going to make you mad. Probably. For some statistical definition of "you", it's very likely to upset you.
Why? Because... well, here, I wrote a little ditty about it:
Hey man, I don't know that stuff
Stevey's talking aboooooout
If my boss thinks it's important
I'm gonna get fiiiiiiiiiired
Oooh yeah baaaby baaaay-beeeeee....
I didn't realize this was such a typical reaction back when I first started writing about interviewing, way back at other companies. Boy-o-howdy did I find out in a hurry.
See, it goes like this:
Me: blah blah blah, I like asking question X in interviews, blah blah blah...
You: Question X? Oh man, I haven't heard about X since college! I've never needed it for my job! He asks that in interviews? But that means someone out there thinks it's important to know, and, and... I don't know it! If they detect my ignorance, not only will I be summarily fired for incompetence without so much as a thank-you, I will also be unemployable by people who ask question X! If people listen to Stevey, that will be everyone! I will become homeless and destitute! For not knowing something I've never needed before! This is horrible! I would attack X itself, except that I do not want to pick up a book and figure enough out about it to discredit it. Clearly I must yell a lot about how stupid Stevey is so that nobody will listen to him!
Me: So in conclusion, blah blah... huh? Did you say "fired"? "Destitute?" What are you talking about?
You: Aaaaaaauuuggh!!! *stab* *stab* *stab*
Me: That's it. I'm never talking about interviewing again.
It doesn't matter what X is, either. It's arbitrary. I could say: "I really enjoy asking the candidate (their name) in interviews", and people would still freak out, on account of insecurity about either interviewing in general or their knowledge of their own name, hopefully the former.
But THEN, time passes, and integoogle job interview programming career interviewing algorithms howto
-
20 Feb 11
-
11 Feb 11
-
Steven Skiena's The Algorithm Design Manual
-
spend at least an hour practicing immediately before you walk into the interview
-
go in humble, open-minded, and focused
-
Treat every question as legitimate
-
Don't say "choo choo choo"
-
focus on each problem
-
ask them if they would like to see code
-
Ask if they care about syntax
-
ask a few clarifying questions
-
don't take too long before actually solving the problem
-
bring your own whiteboard dry-erase markers
-
practice whiteboard space-management skills
-
Big-O
-
details of at least one n*log(n) sorting algorithm
-
Merge sort
-
implement one using only arrays in your favorite language
-
familiar with binary trees, n-ary trees, and trie-trees
-
one flavor of balanced binary tree
-
tree traversal algorithms
-
ways to represent a graph in memory
-
graph traversal algorithms: breadth-first search and depth-first search
-
Dijkstra and A*
-
NP-complete problems
-
Concrete Mathematics: A Foundation for Computer Science
-
"Applied Combinatorics" (Roberts & Tessman)
-
"Discrete Mathematics (Schaum's Outlines)" by Lipschutz and Lipson (2e).
-
dynamic programming
-
"Concrete Mathematics" By Knuth, Graham and Patashnik
-
-
10 Feb 11
-
02 Feb 11
-
01 Feb 11
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.