Tags: , , , , | Posted by Admin on 11/24/2008 9:44 AM | Comments (20)
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
Tags: , , , | Posted by Admin on 11/11/2008 2:18 PM | Comments (0)
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.
Tags: , , , | Posted by Admin on 11/10/2008 2:15 PM | Comments (0)
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!
Tags: , | Posted by Admin on 11/9/2008 2:12 PM | Comments (3)
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...
Tags: , | Posted by Admin on 9/2/2008 11:31 PM | Comments (0)
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
Tags: , | Posted by Admin on 10/4/2007 12:07 PM | Comments (0)
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.
Tags: , , | Posted by Admin on 9/1/2007 1:29 PM | Comments (0)
Earlier this year a friend of mine asked if he could give my email address and/or resume to recruiters at Google. Google set aside half of a day for engineers to look for resumes and contact friends who might be the type of person good would like to hire. I’d been happy with my current job so I was hesitant but I relented and said he could give them my email address. Over the next 3 months I experienced a level of disorganization that I never would have expected from a company with the Google’s reputation. The experience has soured my opinion of the company and it has given me insights on what to avoid when I take on the role of interviewer. If you happen to be reading this and you work with me at my current job don’t get too excited. I told my manager that I was interviewing with Google. I didn’t want him to hear it from somewhere else and get the wrong idea. I was completely honest when I told him that there was very little chance I’d accept an offer if given one. Contact 4/09/2007: On April 9th, 2007 I was contacted by a Google recruiter whom I will call Cathy. I made it clear that I was happy with my current job but that I would consider Google. It was an opportunity that I was willing to explore even if it was unlikely that I would accept an offer. At the very least I’d gain interview experience and see what the Google hiring process was like. Contact 4/12/2007: I emailed Cathy my resume and three days later (4/12) she called me to verify my resume. She asked me what locations I’d be most interested in as I would have to relocate if I were to work for Google. I told her I was interested primarily in Mountain View because if I were to accept a job with Google I’d want to go “all out” and work at their headquarters. I said I’d also be interested in their Atlanta development office. This was the first time that I told Google where I’d be interested in working, it wouldn’t be the last. The phone call was short and fun. Cathy said she’d be arranging a 30-45 minutes technical phone interview with an engineer. Third Contact 4/30/2007: As I said I wasn’t terribly interested in leaving my current job and uprooting my family to move to the expensive Sunnyvale, CA area. Still my wife and I have grown tired of the weather and the all too common BANANA attitude in Rochester so I decided to play along until the end. On 4/25, nearly two weeks from the time Cathy said she’d arrange an interview I decided to email her. I assumed she had forgotten about me. I heard nothing from her until 4/30. It had now been three weeks since Google initially contacted me. To give Cathy some credit she did apologize for taking so long about contacting me. She said she was traveling for work. Wouldn’t she have had access to work email while on travel? She asked me if I’d be interested in working for You Tube. I really didn’t care so I told her I’d be willing to pursue that. The odd part is that You Tube is located in San Bruno. During the initial conversation I said I’d be interested in Mountain View or Atlanta. Maybe she didn’t write that down. Contact 5/21/2007: That’s right, three more weeks passed with absolutely no contact. I didn’t bother emailing Cathy because I was annoyed enough at this point that I was more than willing to drop the whole thing. Luckily I wasn’t actively seeking a job or I would have been very angry. Finally she got around to scheduling a phone interview. Remember this is about 6 weeks from when I was originally contacted. Contact First Interview 5/29/2007: My daughter Cassie was born on 5/28/2007. I took my first phone interview on very little sleep in the outdoor courtyard of the hospital. Still it was a good interview. I had fun and the interviewer seemed honest and interested in performing an interview. I expected positive feedback. Contact 5/31/2007: Amazingly Cathy got back to me only two days after the phone interview. She told me there was positive feedback. She also asked me if I was interested in working at Mountain View or just New York or Boston. Remember that I told her Mountain View when she first asked this question and I never once mentioned New York or Boston. I would have expected a detail as important as location would have been recorded for future reference. She never mentioned the You Tube thing again. Contact 6/6/2007: Cathy tells me that the interviewer thought I’d be good as a Software Engineer or as a Software Engineer in a “platforms” position. A “platforms” position at Google is working with embedded systems (or computing appliances as I tend to call them). After reviewing the job description I told her that I would very much like working in the platforms position but I was lacking the hardware experience that was listed in the job description. I reminded her that this position was very much like the position I held for quite some time at Harris RF Communications. Contact Second Interview 6/8/2007: For my second phone interview there happens to be a thunderstorm in my area. There was a poor connection and I had trouble hearing the interviewer. I think he may have been on speaker phone as it sounded like he was typing in the background. Normally I have fun with interviews. For this one I did not. It may have been due to lack of sleep from my new daughter. It may have been the thunderstorm. It could have been that the interviewer didn’t seem completely engaged. I didn’t expect positive feedback from this interview because I didn’t have fun. Contact 6/13/2007: Cathy tells me that the engineers that I worked with thought I’d be best as a Software Engineer in their test group. I was immediately disappointed because Software Testers are not nearly as well respected as Software Engineers. I nearly told them to forget about it but I decided to play along. Contact 6/25/2007: Nearly two more weeks pass by without a word from Cathy. Finally Cathy writes to me to tell me that a new recruiter, whom I will call Jessie, would contact me for the rest of the interview process. She told me if I had any questions before Jessie contacted me to email her. I immediately wrote back asking if the next interview would be on site or if it would be another phone interview. I never heard from Cathy again. Thanks a lot Cathy. Contact 6/27/2007: Jessie contacts me to schedule another phone interview. She said internet access would be required. I was very annoyed at this point as it had been nearly three months since I was first contacted and they wanted to do more phone interviews? I guess a Software Engineer in test is different than a Software Engineer to them because they wanted to subject me to even more phone interviews. This must be because it was for a different department. But why do more phone interviews? The engineers that interviewed me before weren’t from the same department. I had already been assured that a Software Engineer in test is still a Software Engineer so why start the process all over? Again I nearly told them to leave me alone. I decided to play along only in the hopes of getting a free flight to California. Contact 6/29/2007: After expressing some of my annoyances with the interview process Jessie wrote back to me. She asked me if I was interested in the opportunity in New York City or just Mountain View. Where are they getting information from? I never once expressed interest in New York City. You’d think Google could store that information in a database or something and possibly make it searchable. That same day a different person (not Cathy, and not Jessie) arranged for a third phone interview. Contact Third Interview 7/05/2007: I was in a bad mood and very tired from dealing with a newborn for two months. The third phone interview did not go well at all. I suspect a lot of it had to do with my mood and lack of sleep. It also didn’t help that the interviewer very obviously didn’t want to be doing the interview. He completely avoided all chat and asked canned questions. For this interview I had to write code using a web based word processor. Ugh. They asked me a simple questions and I came up with a horrible solution. I can admit that. My solution was horrible. I knew after the interview was done that the interview process would be over. I was right. Contact Rejection 7/06/2007: Yet another person (not Cathy, not Jessie, not any of the interviewers, not the person that arranged the third interview) wrote to tell me that they weren’t interested in continuing the interview process. They cited my crappy code that I wrote in the third interview. I couldn’t blame them for that. This person wrote that I could re-apply in one years time. I took major offense to that. THEY contacted me. I did NOT contact them. And how is 1 years time defined? Is it one year from when the process started or one year from when it ended? That’s a big difference as you’ll notice that the interview process had gone on for a full 3 months. I didn’t bother replying to the email. What I Learned : The number one lesson that I learned through this ordeal is that asking a candidate to write code in an interview setting is almost certainly a bad idea. I’ve done this in the past and I no longer think it is a fair way to assess a candidate. You simply are not in the right frame of mind to write code in an interview setting. In the future I will present candidates with code and ask them to talk about the examples but I will not ask them to write code. I also learned that the best time to look for a new job is when you don’t necessarily want a new job. There’s no pressure in that situation and you can be highly critical when examining opportunities. What Google Needs to Learn: Google has their heads up their asses when it comes to recruitment. I’m no coding rock star but I can’t imagine that any experienced developer would accept an offer after putting up with so much crap. In fact I think most candidates would have stopped the interview process long before I did. Google is in serious trouble if they keep this up. If I had been actively pursuing another job I almost certainly would have found another job in the three months that Google dragged this out for and they would have lost the chance to recruit me. As I said, I’m no rock-star programmer. I seriously botched the third interview and I completely agree with Google for not pursing me after that. However they won’t be hiring anyone except people directly from college if they continue to recruit the way they currently are. …In “one year” I will not be “re-applying” for a job that I never applied for. Nice job Google.