Phone Interviews
The first two phone interviews were back-to-back and lasted 45
minutes each with a 15 minute break in-between. Both interviews had a
mix of questions pertaining to programming, algorithm design, work term
experiences, school projects and fundamental programming and computing
concepts. The interviews were well-rounded and had good breadth and
depth in terms of coverage.
The third interview was solely to test my coding skills. It was a
45-minute phone interview as well. I was given two problems and I had
to talk through my solutions and provide detailed pseudocode over the
phone. Then, I was instructed to submit actual code files to the
interviewer’s email address within an 1-2 hours after the interview. I
was given freedom to use whatever programming language I saw fit. I
made sure my code compiled and I put comments for better readability. I
also cleaned up my code for any redundant or unnecessary variables.
After a week or so, I was told that there were no more positions
available in the smaller offices but that they had an opening for the
Software Engineer in Test position at the Mountain View campus, if I
was interested. Of course, I said yes. So, I got flown down to Mountain
View to interview with the Test team. It was a nice 3-day reprieve from
winter chills.
On-site Interviews
I was scheduled to meet my recruiter at 10am. She gave me a good
tour around the Googleplex and talked about Google as a company and
some of the employee perks. Then, she brought me to the interview room.
There was a Google bag with other Google goodies that was for me to
take home after the interview.
Technical Interviews
I had three technical interviews. The first 2 interviews were held
before lunch, and the third one after lunch. Each interview lasted
around 45 minutes and had an average of 3 problems each . All the
technical interviews were held inside the same room. Although there is
a whiteboard in the room, I was only asked to write on it during my
third interview. For the other interviews, I mostly wrote on a pad
paper. For some reason, I was allowed to write using pseudocode but I
think it is still better to write real code. Most of the problems I was
asked were just common coding problems or algorithms and to give ways
to test them. Two problems I was given were search-related and for one
of them, I was asked to scale the solution to a distributed file system
that comprised of thousands of servers. I’ve compiled a list of technical interview tips and guidelines, as well as a list of helpful interview resources.
Lunch Interview
I was introduced to another member of the team and he brought me to
the biggest cafeteria in the Googleplex. As everyone probably knows by
now, one of the best Google perks is free food and tons of it. There
was a wide variety of food and drinks. I decided to get food from the
Japanese station. The sashimi was really fresh and sumptuous. Anyway,
on to the casual interview. Most of the questions during lunch were
just about which aspects of software or computer engineering I liked
the most. I also talked about some of the projects I worked on in
university as well as in my work terms. There was no technical question
at all. I think they just wanted to see whether my interests and
expertise are a good match for their team.
Original story
A little more than two weeks ago I had an on-site interview at
Google in Mountain View, California! The job interview with Google was
an interesting experience and I want to tell you about it. (I got the
green light from Google to publish this article).
The position I was interviewing for was a Google SRE. SRE stands for
Site Reliability Engineering. Site reliability engineers (SREs) are
both software engineers and systems administrators, responsible for
Google’s production services from end-to-end.
There were eight separate interviews total. The first three were
over the phone (phone interviews) and the remaining five were on-site.
The first interview was with the recruiter and was not very technical
but the other seven were very technical.
All interviews went very well but I just got to know that I did not
get hired! Oh well… I personally think that I did really well. I
answered all the questions but it seems they were not satisfied! The
recruiter told me that I did not have enough experience to work in a
mission critical team and that I should get more experience and try
again.
Here is how it all happened.
Shortly after I published the “Code Reuse in Google Chrome” post I was contacted by a recruiter at Google. The email said:
I recruit top notch Software Engineering talent at Google. I recently
came across your name as a possible world class Engineer and am
intrigued to know more about you. I promise to exchange some detailed
info about us as well.
Interested to hear more? Want to be an impact player at Google? Then
please respond with a current (English) copy of your resume and I’ll be
happy to call you and discuss.
At first I thought I would be applying for a software developer
position, but after we went through my skillset, the recruiter
concluded that I would better fit as an SRE. I agreed with him. This
seemed like a perfect position for me. I love systems administration as
much as I love programming.
First Interview (phone)
The first interview was on the 10th of September with the recruiter.
He explained the Google recruitment process to me and we went through
my skill set. I had to rank myself from 0 - 10 in a bunch of areas such
as C programming, C++ programming, Python programming, networking,
algorithms and data structures, distributed systems, Linux systems
administration, and others.
As I said, based on my answers we concluded that SRE was the best
position for me. An SRE basically has to know everything: algorithms,
data structures, programming, networking, distributed systems, scalable
architecture, troubleshooting. It’s a great hacker position!
After these questions he asked me where I would like to work -
Google office in Ireland, Zurich, Mountain View or Australia. I said
Mountain View as it’s the Googleplex! He explained that if the
interviews went OK, I’d have to get an H-1B visa that allows non-US
citizens to work in the US.
The second half of the interview had some basic technical questions,
just to make sure I knew something. The questions were about Linux
systems administration, algorithms, computer architecture and C
programming. I can’t go into any
details because I signed a non-disclosure agreement and my recruiter
kindly asked me not to post the questions!
I made some factual mistakes but he was satisfied and we scheduled
the next phone interview. He warned me that it will be very technical
and I should do really good preps. I asked him to give me a plenty of
time for the preparation and we scheduled the next interview on 22nd of
September.
He also told me that each phone interview is going to be 45 minutes to 1 hour long.
I started preparing like crazy. I found three presentations on what SRE is all about:
Engineering Reliability into Web Sites: Google SRE
Google SRE: That Couldn’t Happen to US… Could It?
Google SRE: Chasing Uptime
Then I found all the other blog posts about interviews and interview questions at Google:
Corey Trager’s Google Interview
Rod Hilton’s Google Interview
Ben Watson’s Google Interview
Shaun Boyd’s Google Interview
How I Blew My Google Interview by Henry Blodget
Get That Job at Google by Steve Yegge
Tales from the Google’s interview room
Google Interview Questions
Google Interview Questions — Fun Brain Teasers!
And some others…
I printed and read four Google research papers:
The Google File System
Bigtable: A Distributed Storage System for Structured Data
MapReduce: Simplified Data Processing on Large Clusters
and just for fun Failure Trends in a Large Disk Drive Population
I also went through several books:
the best book on basics of networking “TCP/IP Illustrated“
the best book on algorithms “MIT’s Introduction to Algorithms” + my notes on algorithms
a book on scalability “Building Scalable Web Sites“
As I did not know if I might get specific programming language questions, I went through a few tens of receipts in C++ Cookbook, Python Cookbook, and Perl Cookbook.
Second Interview (phone)
The second phone interview was with an engineer from Google. He
worked on the Ads team which is responsible for running AdSense,
AdWords and other advertisement stuff.
The interview was very technical and started with an algorithmic
problem which was too large to fit in computer memory. I had to tell
him precisely how I would get around this problem and what data
structures and algorithms I would use. He also asked me to think out
loudly. The interview continued with questions about data structures,
DNS, TCP protocol, a security vulnerability associated with TCP,
networking in general, and Google itself. Sorry, but I can’t disclose
anything in more details.
After the interview the engineer had to write feedback on me. It was positive and I could move on with the interviews.
Third Interview (phone)
I gave myself more time to prepare and the third interview was on
the 1st of October. It was with an engineer from the Google traffic
team.
In this interview I had a very simple programming question and I had
to do coding over phone. I was free to choose the language and I chose
Perl as it is my most favorite programming language. It was impossible
to dictate Perl syntax over phone “for my dollar sign element open
paren at data close paren open curly brace … close curly brace” so I
submitted my Perl program over the email.
Then the same problem was taken to the next level, what if the data
we are working on is gigabytes in size, terabytes in size. How would my
program/solution change?
Finally I had a question about DNS again, then HTTP protocol, routing, and TCP data transfer.
The feedback was positive and I could prepare for the on-site
interviews. In my conversation with my recruiter I got to know that
there will be five on-site interviews, each exactly 45 minutes long.
One on my previous work experience, one on algorithms and data
structures, one on troubleshooting and networking, and two on software
development with focus on C and C++.
My recruiter suggested that I read a few more documents:
Google C++ Style Guide
Web Search for a Planet: The Google Cluster Architecture
Algorithm Tutorials on TopCoder
I flew out to USA on 24th of October at 1pm from Latvia and arrived
in California at 8pm. The flight was actually 14 hours but it was nice
that I flew in the same direction as the time flows. This saved me 7
hours. The on-site interview was scheduled on 27th of October so I had
a good rest before the interview. It was also nice that Google paid for
my trip, hotel, cab and food. I had zero expenses!
Fourth Interview (on-site)
The fourth interview was finally at Googleplex! At 10am I met my
recruiter and we had a 15 minute discussion about the interviews. He
told me I would have two interviews now, then one of Google engineers
would take me to lunch to one of Google’s restaurants and then I would
have three other interviews.
At 10:15am the first on-site interview began. It was about my
previous job experience. I have had a lot of job experience in the past
and I decided to tell about a physical security notification system
that I coded in C on Linux a few years ago. The system would receive
messages through the serial port and send out emails and SMS’es.
In the last minutes of the interview he asked me some basic Unix filesystem questions.
In all the on-site interviews I was writing and drawing on two big whiteboards. Fun!
Fifth Interview (on-site)
The fifth interview began at 11am. It was a coding session and began
with a trick question and not a real coding problem. I was asked to
implement the solution in C. The solution was a mathematical expression
that was a one-line return statement. No big coding there. Then I was
asked to write an implementation of a very well known data structure.
While coding I made a mistake and forgot to initialize part of a data
structure that I had malloc()’ed! The program would have segfault’ed in
real life and I would have noticed the error, but Google engineers are
very serious about it! If you have an interview don’t ever make any
mistakes!
After this interview I was taken to lunch by the engineer who
interviewed me on the second (phone) interview. She told me she was
working at Google for two years and was very happy about it. We went to
Asian food restaurant (located in Googleplex) and I had all kinds of
delicious foods. All free!
Then she showed me around Googleplex. It was all amazing. Free
drinks and candy everywhere, some arcade machines, a beach volleyball
outside, and many other surprising things.
Sixth Interview (on-site)
The sixth interview began at 12:45pm. It was a troubleshooting and
networking interview. The interviewer drew a network diagram on the
whiteboard and had imagined a problem in there. I had to ask a bunch of
specific networking questions to locate the problem. He was satisfied
and in the last few minutes of the interview he asked me some specific
networking device questions.
Seventh Interview (on-site)
The seventh interview began at 1:30pm. It was a coding session. I
was asked to implement a simple string manipulation subroutine in
either C or C++. I chose C. Unfortunately I made an off-by-one mistake
there - the most common programming mistake in the history of mankind.
The whole interview focused on this one problem.
Eighth Interview (on-site)
The last, eight, interview began at 2:15pm. It was algorithms and
data structures interview. The problem presented here was similar to
the problem in the 2nd interview. Not only was it a problem too large
to fit in computer memory but it also was distributed. So I had to do
all kinds of trickery to solve it. The interview was very free-style
and we talked back and forth about the problem. I arrived at the
correct solution near the end of the interview and he said that not
many candidates get that far in the solution. I was happy.
After the interview the engineer escorted me out to the lobby and I took a cab back to my hotel. That’s it!
FIN
Overall the Google interviews were pure fun for me. The interview
questions were technical but not very challenging or difficult.
Thanks for the opportunity Google!
Original story
This is the 3rd interview I had with Google. You can find the previous and the questions asked here:
* First Google interview
* Second interview
In
the 3rd interview I talked with a woman software engineer from Mountain
View. As usually it lasted for about 45 minutes but there was a
surprise waiting at the last question..But let's take things from the
beginning.
The first question was a hard test for my memory: "How do you test your code?"
This is a fair one for software engineers. But not for my style. I
personally like things that are quick and dirty. For larger projects I
use some of my own class libraries that employ some kind of logging,
measure method execution time and so on. But saying "Well, I use my own class libraries." I thought would not be a good answer. Nor a professional one.
So
talking about Java, I made the mistake of mentioning the JUnit
framework. I had used for some time (long ago) but the time had passed
so I had forgotten even the basics. And of course the interviewer
started the questions (How the JUnit handles exception and others)
To tell you a secret I had already opened in my browser a JUnit site
(some kind of tutorial I guess) but this didn't help at all. So, don't
do it. It will only make things worse. Trying to think logically didn't
help either. The interviewer kept pushing, until I 'broke' and admitted
that I couldn't answer. That was it. We moved to the next question.
All next questions were really typical, the kind you find in tech interview sites:
* "What is a Unix kernel?"
* "What is the difference between interfaces and abstractt classes?"
* "What is the difference between threads and processes?"
* "What is inheritance, polymorphism and encapsulation?"
* "What is overriding and what is overloading?"
I think there is no need to elaborate further on that. You most probably have come across these concepts and have your own mind.
Which
brings us to the last question. Actually it was a puzzle including
programming with handicaps, i.e. with small processor, low memory etc.
The puzzle was this:
"You have 1000
integers. All are less than 1000 and greater or equal to 1. Among them,
999 are distinct and there is one that is found twice. How can you find
the duplicate?" To this I gave an answer I think is optimal. The idea is simple. If you denote the duplicate number by d and the sum of all the integers by S then the following equation holds:
S-d= 499500 since S-d is the sum 1+2+3...+999 which is equal to 499500 by applying the formula 1+2+3...+n = n*(n+1)/2
Now
the good thing is that we can be able to find the duplicate even we
have capacity for one integer, or when reading from a stream and so on.
We can optimize even if we apply modulus to the first equation: d = (S-500) (mod 1000) Now if d
is equal to a positive number mod1000 then this is the duplicate,
otherwise the duplicate is the negative part plus 1000. For example is
1 was the duplicate, then d=1(mod 1000) and the duplicate had to be the 1. If the duplicate was 600, then d=-400(mod 1000) so the duplicate had to be -400+1000=600. This means we do not need to have storage for integer (int type) but only the byte type is enough.
While
fairly easy to grasp the interviewer had difficulties in understanding
how this would work, so she asked for an example when we have 10
integers. I replied this would transform the equation to d =S-45 but then the counter question was disappointing: "How did you compute 45?"
It is quite obvious however that I had to compute 1+2...+9 which is
equal to 45 when applying the formula that Gauss found when he was 8.
But the interviewer started computed 'by hand' the sum, adding the
numbers from 1 up to 9, which left me speechless for some seconds. I
mentioned that there was a formula for that but she didn't listen,
still being concentrating on her computations. I didn't bother
elaborating on the modulus idea since obviously would not give me any
more credit.
After that, the interview had finished. I didn't ask anything, saying something like 'I have many questions but I do not wish to spend any more of your time'
and we ended the conversation. In overall the last incident was really
awkward. To that time I believed that all Google engineers had a good
mathematical background. The engineer that I spoke with, did lack
elementary skills. So in my eyes, the myth had been destroyed and it is
a good advice to anybody, not bother berating himself more than he
should. If you already knew the formula for the sum of consecutive
integers, you have a good reason to feel more confident.
This continues from my first Google interview described here
In overall, the second one was harder in terms of questions and
expectations. I was called again from Mountain View sharply at the time
we had arranged.
The conversation began with an interesting question: "What would you change in the Java programming language?"
This has more than one questions embedded and it is educating listening
to all possible answers. For example, one of my suggestions was having
'mechanisms' much like the properties fields in C# to ease development (programming get/set
methods seems very tiring to me)Since the question was referring to the
language and not to the Virtual Machine anything you find tiring or
absent in Java is probably a valid answer.
We
next proceeded to a C programming question. My interviewer knew that I
was not a C-guru so he was gentle on that. The question was something
like this. What is the output of this C program?
main() {
char X[500] = "Hello World";
printf("%s",X+5);
}
I
knew it had to do something with memory allocation but I was not
succinct on that. I said that the output would be blank and I guess I
was right (the interviewers never tell you directly if you are right or wrong) So we said OK and moved on.
The 3rd question was about creating random functions. It is the type of questions where given a function randX that provides uniformly numbers from 1 to X, to generate a another randY. The actual question was about making rand8 from rand6. It is easy to establish how to get a rand2 from rand6. Then you can get rand8 from rand2.
This
was a straightforward case. However, this problem appears very often in
such situations and deserves some attention. You may find unlimited nonsense by searching for 'create rand7 from rand5' which is also a frequent question. Trying these forums/blogs etc you will get endless efforts of shifting from one rand to another using common arithmetic functions (addition, mod etc). This is nonsense. You will have to shift to elementary analysis for a while to get some good results.
In the general case consider you have to generate randX from randY where Y > X. Now consider that this yields the division: Y = n*X+r So, you can one group of Y elements into X groups of n elements and one more group with r elements. Now number the X groups as 1,2,3..X Then, create a 'machine' that uses the algorithm:
m = randY();
IF m belongs to one of the X groups return its number
ELSE restart the machine
The probability in every run of the algorithm to return one specific value from 1 to X is a =n/Y and the probability that the algorithm restarts is b = r/Y. So, the overall probability that the machine will output one number from 1 to X is :
P = a+a*b+a*b*b+a*b*b*b+... = a*(1+b+b*b+...) = a/(1-b).
By substitution we get, P = 1/X
In other words, we have generated the function randX
Now, if we wish to increase the rand range, for example get rand7 from rand5 you can create rand25 from rand5
(two rand5 calls) and then use the above method. Shifting to infinity
is inevitable in some cases and all other efforts are in vain.
Back
to the interviews, the final question had to do with designing and
analyzing an algorithm. This had to calculate all representations of an
integer as a sum of cubes. You can find many similar examples in
algorithms textbooks so presenting this story here is trivial. What is
interesting is that, we started a discussion on an incident that was
directly related to the problem. This is usually called as the 'cab number story'. Back in the days when Ramanujan was in Cambridge and was working with G.H. Hardy,
he had frequent health problems. One day, Hardy visited Ramanujan to
the hospital and to start a discussion he mentioned the number of the
taxi cab that brought him there. He said something like "..The cab number was 1729. I think this number is not interesting at all." A few seconds Ramanujan (which was extremely competent with numbers and calculations) replied: "You
are not right Mr.Hardy. 1729 is very interesting. It is the smallest
number that can be written as a sum of cubes in two different ways."
This
was a nice way to close the interview. We didn't have much time left,
so we said some relaxing things and then ended the interview
conversation. All in all, it went well and my interviewer was a really
nice person. Our discussion was interesting and I soon got the news
that I was to pass to the next level. Having acquaintance with math and
generally science history certainly helps!
The first Google interview is most likely the easiest one.
I have
the feeling that they normally ask general questions, just to ensure
that you have some knowledge of computers and you are not just the guy
who believes he deserves a place in Google because he can make nice
Powerpoint presentations. At least happened in my case.
A guy
from Mountain View called me sharply at the time we had arranged. He
called on my mobile. I had everything arranged: From the bluetooth
hands-free to nice and clean desk in front of me. At first, he asked me
some questions about my CV, my age and my education. He didn't seem so
interested in that and my impression was that his questions were
somewhat mechanical.
After a couple of minutes, he started asking technical questions. The first one was easy: If we would like to index the entire earth population, how long should the index size be?
Although a piece of cake, I felt like I was asked to prove that P=NP.
Soon, I panicked but I asked for some time to 'warm up'. The Google
Engineer was kind enough to understand and gave me all the time I
needed in order to finally realize that I was talking to Google and
that I had to control myself.
After recovering and answering to this question, I was put in front of a puzzle involving buckets
and I was asked to find an algorithm that would end up in a situation
that one bucket would be empty, as soon as some conditions were met.
Excuse me for this vague description but I am still not able to
remember exactly what the problem was all about. Instead of trying to
find some exact solution to a problem that I couldn't understand
(perhaps I was very nervous or I didn't understand the language), I
followed an old Harry Truman's quote: "If you cannot convince them, confuse them".
This seemed to work extremely well. I soon said something about
modelling the problem as a Diophantine equation, where the solutions in
integers would mean filling if positive or emptying if negative. Of
course I had no idea what I was talking about, but the Google Engineer
fell into it. He was not familiar with the idea, we soon started
talking until we had switched to a more theoretical conversation. This
gave me time to think over the solution and present with a
backtracking-type of algorithm. During all this, I was asked some
algorithmic-theoretical questions, for example about hashing space and time complexity.
We
spent a lot of time on this problem. The last one was around his own
domain of expertise. It turned out that this guy was working on Google Book Search and asked what I would if I had to find duplicates in book catalogs with entries with different titles but with the same content..
I had no idea of the format, Google was using to index book entries, I
asked some questions that clarified the problem to me and then I
presented my solution. My idea was to use some basic format properties
of book text, for example number of paragraphs, size of paragraphs and
so on. This way a book named "Albert Camus-The Stranger" would match a
book "Famous Authors-L'etranger" (the example might not be realistic
but it gives the idea)
The 45 minute had finished and it was time to ask my own questions. I asked a couple of things (one being if book search is still beta
to which the engineer falsely responded that it is not!)and some other
lame how-wonderful-is-Google questions and we said goodbye.
The
next day I was informed by my recruiter that I had done well we had to
proceed to the next stage. Overall, the guy I talked was very kind and
showed a lot of understanding when I was stuck in the first and
simplest question. But now I had to prepare for the 2nd interview which
my recruiter had informed me that would be much more technical...
MOUNTAIN VIEW, Calif. — Have you ever made a profit from a catering
business or dog walking? Do you prefer to work alone or in groups? Have
you ever set a world record in anything?
The right answers could help get you a job at Google.
Google has always wanted to hire people with straight-A report cards and double 800s on their SATs. Now, like an Ivy League
school, it is starting to look for more well-rounded candidates, like
those who have published books or started their own clubs.
Desperate
to hire more engineers and sales representatives to staff its rapidly
growing search and advertising business, Google — in typical eccentric
fashion — has created an automated way to search for talent among the
more than 100,000 job applications it receives each month. It is
starting to ask job applicants to fill out an elaborate online survey
that explores their attitudes, behavior, personality and biographical
details going back to high school.
The questions range from the
age when applicants first got excited about computers to whether they
have ever tutored or ever established a nonprofit organization.
The
answers are fed into a series of formulas created by Google’s
mathematicians that calculate a score — from zero to 100 — meant to
predict how well a person will fit into its chaotic and competitive
culture.
“As we get bigger, we find it harder and harder to find
enough people,” said Laszlo Bock, Google’s vice president for people
operations. “With traditional hiring methods, we were worried we will
overlook some of the best candidates.”
Google is certainly not
alone in the search for quantitative ways to find good employees.
Employers use a wide range of tests meant to assess skills,
intelligence, personality and honesty. And the use of biographical
surveys similar to Google’s new system is on the rise.
Such
tools, however, have mainly been the trademark of large corporations
recruiting armies of similar workers, like telephone service
representatives or insurance sales agents. They are rarely used in
Silicon Valley, which is built on a belief in idiosyncratic talent.
“ Yahoo
does not use tests, puzzles or tricks, etc., when interviewing
candidates,” Jessie Wixon, a spokeswoman for Yahoo, said. (Google is
known for hazing prospects in interviews with intractable brain
teasers. And it once tried to attract candidates by placing some
particularly difficult problems on billboards.)
Google’s growth
is staggering even by Silicon Valley standards. It is constantly
leasing new buildings for its overflowing campus here and opening
offices around the world.
Google has doubled the number of
employees in each of the last three years. Even though the company now
has about 10,000 employees, Mr. Bock says he sees no reason the company
will not double again in size this year. That would increase the number
of hires to about 200 a week.
As a result, Mr. Bock, who joined Google from General Electric
last spring, has been trying to make the company’s rigorous screening
process more efficient. Until now, head hunters said, Google largely
turned up its nose at engineers who had less than a 3.7 grade-point
average. (Those who wanted to sell ads could get by with a 3.0 average,
head hunters said.) And it often would take two months to consider
candidates, submitting them to more than half a dozen interviews.
Unfortunately,
most of the academic research suggests that the factors Google has put
the most weight on — grades and interviews — are not an especially
reliable way of hiring good people.
“Interviews are a terrible predictor of performance,” Mr. Bock said.
Mr.
Bock said that he wanted the company’s human resources department to
bring the iconoclastic style as its Web site developers to the normally
routine function of interviewing job candidates. “The level of
questioning assumptions is uniquely Googly,” Mr. Bock said.
So Google set out to find out if there were any bits of life experience or personality it could use to spot future stars.
Last
summer, Google asked every employee who had been working at the company
for at least five months to fill out a 300-question survey.
Some questions were factual: What programming languages are you familiar with? What Internet mailing lists do you subscribe to?
Some looked for behavior: Is your work space messy or neat?
And some looked at personality: Are you an extrovert or an introvert?
And
some fell into no traditional category in the human resources world:
What magazines do you subscribe to? What pets do you have?
“We
wanted to cast a very wide net,” Mr. Bock said. “It is not unusual to
walk the halls here and bump into dogs. Maybe people who own dogs have
some personality trait that is useful.”
The data from this initial survey was then compared with 25 separate
measures of each employee’s performance. Again there were traditional
yardsticks — the employee’s reviews, both by supervisors and peers, and
their compensation — and some oddball ones.
One score
was what the company called “organizational citizenship,” said Todd
Carlisle, an analyst with a doctorate in organizational psychology, who
designed the survey. That is, “things you do that aren’t technically
part of your job but make Google a better place to work,” Dr. Carlisle
said, such as helping interview job candidates.
When all this was
completed, Dr. Carlisle set about analyzing the two million data points
the survey collected. Among the first results was confirmation that
Google’s obsession with academic performance was not always correlated
with success at the company.
“Sometimes too much schooling will
be a detriment to you in your job,” Dr. Carlisle said, adding that not
all of the more than 600 people with doctorates at Google are equally
well suited to their current assignments.
Indeed, there was no
single factor that seemed to find the top workers for every single job
title. (And pet ownership did not seem to be a useful predictor of
anything.) But Dr. Carlisle was able to create several surveys that he
believed would help find candidates in several areas — engineering,
sales, finance, and human resources. Currently about 15 percent of
applicants take the survey; it will be used for all applicants starting
this month.
Even as Google tries to hire more people faster, it
wants to make sure that its employees will fit into its freewheeling
culture. The company boasts that only 4 percent of its work force
leaves each year, less than other Silicon Valley companies. And it
works hard to retain people, with copious free food, time to work on
personal projects and other goodies. Stock options and grants certainly
encourage employees to stay long enough to take advantage of the
company’s surging share price.
Google’s hiring approach is backed
by academic research showing that quantitative information on a
person’s background — called “biodata” among testing experts — is
indeed a valid way to look for good workers.
Michael Mumford, a psychology professor at the University of Oklahoma
who specializes in talent assessment, said that this sort of test was
effective, but he cautioned that companies should not rely on oddball
factors, even if they seemed to correlate to good performance.
“You
have to know or at least have a hypothesis why having a dog makes a
good computer programmer,” Professor Mumford said. “If you ask whether
someone started a club in high school, it is a clear indicator of
leadership.”
At Google, it is too early to tell if the system is
working. The surveys have been in use in about a dozen areas for
several months.
Indeed, there is some resistance even at Google to the idea that a machine can pick talent better than a human.
“It’s like telling someone that you have the perfect data about who they should marry,” Dr. Carlisle said.
But
even before the results are in on the new survey, Mr. Bock says he is
already seeing success in easing the company past its obsession with
grades.
“More and more in the time I’ve been here, we hire people
based on experience as a proxy for what they can accomplish,” he said.
“Last week we hired six people who had below a 3.0 G.P.A.”
Original story
I’m mostly happy with my day job. Actually not mostly, I’M HAPPY with my day job. Therap
is a fun place to work for Software Developers in Bangladesh, and it
has a unique culture which is seldom seen, specially in IT industries
in Bangladesh. So unless I feel like juggling with my career, or
someone from Mars offers me a job with a joining bonus of a House (and
a mini rover) in Mars, I think current job offer and agile environment
in Therap is hard to beat.
Well odd things happen you know, and on such an odd morning, I fired
up my Firefox and found an interview offer letter from Google. To be
precise it was “Google.com Engineering Team” from Mountain View,
California. Internally this team is called the SRE (Site Reliability
Engineering) team in Googleplex. They told me that they found me from
“Online Sources”. Was I excited? Hell yeah I was excited as getting an
interview offer from Google was … well … at least worth lots of
excitement in most geeks mind. So I replied with a positive tone, and
the interview process started.
It was interesting to go through Google’s interview process which
gave me the opportunity to find the strength (and weaknesses) of the
recruitment process of world’s best company to work for. They found my resume
online, and contacted me for a specific position that they thought
better for them to put me in. One thing to note here is, it wasn’t me
going to them and knocking on their door for a job. Now, why didn’t I
think of that? May be I still love to work here in my home country and
stay with my family? Why doesn’t Google open a development house here?
Well that would be fun!. Anyway, the interview process started with a
phone call from the technical recruiter assigned for me.
The phone call with the technical recruiter was fun. He was mostly
interested to know what are my current responsibilities, and then asked
me to self evaluate myself, on a scale of 1-10 for some specific
technologies he mentioned. I liked they way they categorized the self
evaluation scale. As far as I remember, it was something like this:
0: If you no idea about it
1-3: Heard of it, somehow familiar with it
4-6: Implemented it, can work on it given time
7-8: You are the goto guy for this technology.(been there, done that)
9: You can write a book on it (you are a star, an expert)
10: You have written a book on it. (10th Dan)
The technologies they asked me to evaluate myself included Java, C,
C++, Python, SQL, Shell Scripting, Unix Systems Programming, TCP/IP
Networking, Hacking Linux, etc. Though I have working knowledge of Unix
System Programming, TCP/IP Networking, Shell Scripting (and other
stuffs needed to know to do production deployment these days), being a
Java developer for last 3/4 years I rated Java knowledge as the
highest.
After giving the technical recruiter my self evaluation report, he
asked me some simple algorithmic questions. I’m not sure whether I can
safely discuss the questions directly, but the question had to deal
with some simple conversion of 16bit integers to binary format and
handling large scale Array (without memory limitation).
There were more questions regarding networking, unix commands and
internals etc., most of which I got right, except some odd ones. The
phone call lasted around 50mins and we ended the conversation with a
positive note of having another technical screening by an Engineer from
Google. The recruiter specially informed me that I will be asked
questions on the topics I rated myself most, so logically I though
there will be lots of question regarding Enterprise Java, and newer
developments in the Java World.
After the initial screening with the Technical Recruiter, he setup
another phone screening for me with a Software Engineer in Google (at
Mountain View, California). As per my self evaluation with the
recruiter, I was preparing myself for questions mostly on Java, and
Enterprise applications, as my expertise lie on that area. But during
the second interview, I found absolutely no questions related to
Java/JEE. The questions were mainly from networking, network protocols,
unix systems programming, shell scripting, etc. I know these stuffs,
but I wouldn’t say that I’m an expert at these. I answered the stuffs
out of my own practical experience, and passed on some questions, but
after this interview, I realized that as the recruiter was trying to
fit me in a certain position they need to fill up, my current expertise
may not match what they are actually looking for. But I think overall
it was good and they setup another interview with a Software Engineer
from their Ireland office. This phone interview was interesting as they
asked me what I have been doing here for last couple of years, and what
interests me most. They were mostly interested in my experience
regarding managing deploying JEE applications in a clustered
environment, and how the database is synchronized in different
geographical locations.
After all these phone interviews, and emails, we came up to the
conclusion that I am not the right person that they are looking for
this exact post. Well, I couldn’t agree more. Interestingly, it was a
very good experience for me as I came to know the process of the
company where every geek wants to work now-a-days.
Recently, I had the pleasure of interviewing with Google. It was
very exciting, as I've wanted to work for Google for quite some time,
and they opened up a branch near my home through an acquisition
recently. I wanted to share the process of interviewing with Google,
not because it was particularly noteworthy, but because I wondered
about interviewing with Google before I did so, and I figured others
might. I've had to sign an NDA, so I'm going to be pretty careful about
what I share in this post.
The position I interviewed for was a Software Engineer position in
the Boulder, Colorado office (near where I live), but they still
conduct their interviews from the California office. Because I'm not in
California, I had to go through two phone interviews first. The
questions Google asks are pretty interesting for a number of reasons. I
think the best word I could use to describe the questions is "fair". I
didn't get any tricky puzzle questions. Nobody asked me what I would do
if I were shrunk to the size of a nickel and thrown in a blender. Not a
single question was an "a-ha!" type brain-teaser. Pretty much every
question was a good question for figuring out if someone can write
code. Even though I was interviewing for a Java position, I only had
one Java-specific question. I could really feel from the questions that
Google wasn't concerned with me being good with a specific language;
they really wanted to know if I was just a good coder.
When I was first told by the recruiter that the questions would be
algorithm-based, I was worried I'd have to reproduce quicksort or
something. In fact, the questions were far, far more reasonable (though
reviewing sorting algorithms WAS a good idea). Most of them involved
manipulating data in an array for some purpose. I'd give an answer that
worked, and they'd ask me if there were any corner cases. I was asked
to solve the problem in a way that avoided those problems. Then I was
asked to improve the space efficiency or running efficiency of the
solution. A solution that "worked" was never enough, the interviewers
always pushed me further, trying to squeeze out performance. I had to
say the runtime complexity for nearly every solution I suggested. I
would NOT recommend interviewing with Google without a Computer Science
degree. You need to be able to look at a function and know the Big-O
for it immediately. Specifically, you need to look at YOUR OWN
functions and know the Big-O immediately.
After doing well with both of these interviews, Google actually flew
me out to California for a weekend for an all-day interview on the
Google campus. They paid for my plane ticket, hotel room, rental car,
and some food. I bought a second ticket for my fiancee and we did
touristy crap around San Francisco. Overall, it was a lot of fun, but I
couldn't help but keep the back of my head occupied with the thought of
an all-day interview.
On Monday, I went to the Google campus. In the main lobby, they have
a projector with a scrolling list of Google searches. I sat in the
lobby waiting for my interview to begin, happily watching the searches
scroll by. Lots of female celebrities were being searched, and someone
searched for "vista crack" which made me laugh out loud, ensuring the
receptionist thought I was an idiot. I sent my fiancee a text message
telling her to search for "Rod is awesome" but it didn't show up. They
also had a neat visualization showing where people were doing searches
on a spinning globe.
Pictures of Googlers with celebrities adorned the wall next to the
new Google whiteboard. For those that don't know, Google has a giant whiteboard
which was finally erased not too long ago. Before being erased, someone
took pictures and posted them to the internet. The new board was
already mostly full by the time I saw it, and a large section of it was
devoted to complaining about the board being erased.
I also had lunch in one of the cafes on campus. The Google cafes are
all buffet-style, and completely free. You simply walk in, grab
whatever the hell you want, and leave. My "lunch-date" was one of my
phone interviewers, and he took me to the health food cafe. Salads,
tofu, bean sprouts, and similar food items filled the buffet. I
searched desperately for some meat and filled my plate when I finally
found it. I'm definitely NOT a California person. People looked at me
like I personally killed a cow in front of them.
The on-site interviews were much like the phone interviews. I had
one-on-one meetings with a handful of people, one after another. Each
person asked me algorithm-type questions. I did some whiteboarding, but
was mostly able to write the answers in my notebook, which was better
for me as I could keep up with my brain much more easily on paper than
on a whiteboard. It was sometimes difficult to focus on the questions
while "OH MY GOD I'M INTERVIEWING WITH FUCKING GOOGLE" whizzed by in my
brain over and over. Luckily, pretty much everyone was extremely
friendly, which helped calm my considerable nerves.
The biggest difference in the questions between phone and on-site
interviews was how my answers had to be presented. On the phone, it was
sufficient that I explain, at a high-level, how the solution to a
problem would work. On-site, I had to actually write it out. Of my four
interviewers, two actually wanted it to be valid Java.
I finished early with one of my interviewers, and he asked me a joke
question: if a Stormtrooper shoots a red-shirt, does he hit? It was
comical how universal this seemed. Of course I'd know what he was
talking about, I write software. Luckily, I was familiar with the term redshirt
from being a film nerd, and I was able to come up with a joke answer
that didn't let him on to the fact I've never seen a single episode of
Star Trek in my life.
The worst part of the process was my fourth and final interview of
the day. The guy was from Moscow, and he had a very thick accent. All
of my life, I've had immense trouble with accents, even slight ones. My
project manager at work has a thick accent from Italy, and she
basically sounds like Chewbacca to me. I'm not complaining that Moscow
Guy had an accent (all tech companies have folks with accents), but it
sure made the rest of the interview process challenging for me. My
interview with the Moscow Guy resembled one of those satellite
interviews on the news. He'd say something to me, and there'd be this
long pause before I responded. To make matters worse, he told me his
first question was going to be "an easy one", so when I barely
understood what he said at all, I imagine I looked like a complete
imbecile. "What was that? You want me to WHAT two numbers together? Mo
de ploy? Mah dah bu? Oh, multiply! Right, two times two is four. I'm
obviously partially retarded."
To make matters worse, the Moscow guy was the only person I talked
to the entire day who wasn't friendly. He wasn't a complete jerk or
anything, but he definitely wasn't as warm as my other interviewers.
Right before the interview ended, he asked me what I'd work on for my
"20% time" project. Each Google employee gets to devote 20% of their time to a side project,
which is why so many of the Google Labs projects exist (like Gmail and
Movie Search). I actually had an answer to this question, since I
thought about it on the plane ride out to California. There's been a
side project I've been wanting to work on at home, but I haven't had
time. I figured, if I got the job, I'd just make that a Google Labs
project and do it there. I explained my idea to him, and he told me it
sounded interesting, then proceeded to write it down right in front of
me. All I could think was "I hope I get this job so I don't regret
that."
I imagine the four interview feedback e-mails looked like this:
"Candidate knew his stuff, but seemed awfully nervous."
"Candidate knew his stuff and seemed relatively comfortable."
"Candidate kept joking around like I was his friend. Clearly was
not nervous enough, given that he was interviewing at FUCKING GOOGLE."
"Candidate seemed to have the brain of a chimp. Was surprised he
could speak without forgetting to breathe. Interviewer confident
candidate eats glue."
I flew back to Colorado feeling pretty good about the whole thing.
As it turns out, though, I was told over the phone (while trying to
push a car out of the snow during the Denver blizzard) that I didn't
get the position. I need to work on my algorithm skills, so I guess I
got docked for not thinking of the best solution right away. The Google
Recruiter told me it wasn't the last guy that did me in, but I imagine
if I had tried to come up with the best solution earlier (rather than
the naive one so I could improve it) and if I had gotten a different
interviewer for my last interview, I'd be writing this blog post from
my desk at Google.
Considering how much I wanted the job, I admit I'm pretty bummed
about this. I'm allowed to re-apply in a year, but I can't imagine
improving my "algorithm skills" without more information on where my
problem areas were. What's really unfortunate is that I know if Google
had hired me, I'd have done a good job. If I see my idea appear on
Google Labs any time soon, I'm going to go nuts.
All in all, it was a pretty pleasant experience. I'm disappointed,
but I'm proud of myself for at least being considered seriously by
Google. It was honestly kind of fun answering their interview
questions. The questions reminded me of my undergraduate work, and it
was nice to think about that kind of material again. I'm bummed that my
progress into the world of Google came to such a screeching halt, but
the journey has definitely been fun and interesting. And hey, I got a
free trip to San Francisco out of it.
I also got a private e-mail. It was from someone at Google. He
explained that my post had been circulating around the Google office
and when it got to him, it piqued his interest.
Essentially, he wanted me to come work for him in Mountain View. He
was looking for Java folks for his team, and he thought I'd be a good
fit. I jumped out of my chair when I read this, amazed some additional
life had been breathed into my foray into the world of Google. The more
I considered the e-mail, however, the more a part of me wanted to say
no. Why?
His offer was essentially doing some semi-internal development for
Google. I wanted to work on their web application back-ends, so that
was a tad disappointing. Could that be the reason I wanted to turn him
down? That didn't seem right, I had been joking for a while that I'd be
happy to clean toilets at Google. Writing code is writing code.
The position was also contract-to-hire, which didn't roll my socks
up and down. But I had been saying that once I got my foot in the door,
I'd be alright. I knew I'd do fine at Google if I worked there, so I
wasn't too concerned I wouldn't be hired permanently at the end of the
contract work. No, it wasn't the contract aspect that bothered me.
He also told me that I'd have to spend three months in California
doing the job. I'd then have to spend three months in California in a
permanent position in order to "culturally integrate" before I could go
back to Colorado and work in the Boulder office. This definitely
bothered me. Since I would want to continue living in Colorado, I'd
basically have to live in a hotel in California while Julia (my
fiancee) stayed here in Colorado for 6 months. I just got engaged a
month ago, and the idea of abandoning the family I'm just starting for
Google seemed completely unfair. If I had gotten the job I originally
interviewed for, I'd only have to be in CA for one week for training,
so 6 months was a pretty big deal. When I told Julia, she told me that
she could handle 6 months, and if I wanted to take this position I
should. She was completely supportive of whatever I wanted to do. So it
wasn't even the 6 months away from my home that was driving me to turn
the position down.
I thought about this for days. I couldn't figure out what about the offer I didn't like, so shouldn't I take it?
Eventually I figured out what I didn't like about the situation and
I turned it down. I don't think I could explain my rationale better
than I did in my e-mail to the guy from Google, so here is what I told
him:
I've been thinking about your e-mail for a few days and I've finally
made a decision. This was not a decision I made lightly by any stretch.
Let me start out by saying thank you for e-mailing me and giving me
another potential shot at Google. I hope you don't mind, but I'd like
to update my blog story with this additional bit, though I won't be
using your name or any details.
As I said in e-mail and via the blog post, there is no place I'd
rather work than Google. Google, to me, is Mecca for software
developers. Google does amazing work that improves the entire world.
There is no better way to put my software development skills to use
than at Google, where I'd be doing good work to make life better for
countless individuals.
My personality, my desire to learn, my goal of improving the world -
all of these tell me that Google would be the best place I could work.
I know Google is right for me.
But am I right for Google? The interview process concluded with a
resounding "no". Google decided that I am not a good fit for the
company, and sent me back to Colorado. The fact that I made a funny
blog post describing my journey doesn't change the fact that, from a
technical standpoint, Google considers me below their standards.
Despite the conclusion of the interview, I believe I *AM* right for
Google. I believe that, if I interview again after improving my
algorithm skills and becoming more confident in my own abilities,
Google will see that I am a good fit and hire me.
In short, I want to work at Google more than I can describe, but I
want to work there because I earned it. I want to start my first day at
Google knowing that I belong there, and knowing that Google knows I
belong there.
As tempting as your offer is, I feel like it's sneaking into Google
via a backdoor. I want to enter Google through the front door.
I intend on improving my abilities and learning new skills, as I do
all the time as a developer. When I am ready, I will re-apply to
Google, and hopefully I will meet you in the cafeteria during my week
of training in California. :)
Thank you again for your e-mail.
I never imagined I would pass up a chance to work at Google, but
there it is. I think I very well may look back and regret this, but for
the time-being I'm comfortable with my decision.
This, I imagine, actually concludes this story. At least for a while.