Category Archives: Interviewing

Clarification on Why Study for an Interview

I had mentioned this in the Tips section, but some people on some sites might still get the wrong idea about studying for my recent Microsoft interview, so I want to write this post, which explains my opinion more (and it really is just my opinion–I have no idea what Microsoft’s policy or opinion is).

I want to make clear that cramming for a job alone will not get you this job. It didn’t get me this job, and it won’t get you a job at any place that really tests you. Thinking it will is a backwards approach.

The two books I mentioned, as well as the links I pointed out, are merely resources to help you focus your efforts. If you have to memorize the questions and answers rather than understanding them, you have a problem. If you didn’t do well in your CS algorithms class, chances are, memorizing the answers isn’t going to do much for you. If you don’t really understand pointers by this point, no amount of memorization is going to help you debug your C++.

Those resources are a way to reflect back on what you’ve learned through your entire career, starting in school. Let’s face it, how many times have you had to implement a hash table, or a heap sort, or even a binary tree? Those basic pieces are always provided for you–almost nobody writes them from scratch in production code. But should you understand them thoroughly? Yes. Should you know common gotchas? optimization techniques? how to write them? Yes, Yes, and Yes.

Even if the interviewer asks you to do some basic problem like writing a linked list function, and you’ve memorized it, then what? Ok, so you write it on the white board. Guess what the interviewer is going to do next? They’re going to ask you to analyze it, they’re going to say things like, now let’s make it circular. How do you detect a loop? Now it needs to bi-directional. Now it needs to be split in half. Now each node also needs to have children. Now it needs to be sorted. Now it needs to represent terabytes of data on disk, now it needs to be faster, smaller, smarter, better in every way.

And that’s only if you answer the problem perfectly at first, which is pretty hard to do.

You see where I’m going with this? It doesn’t matter how well you know the initial question, they will always get to a point beyond where you’ve prepared and you need to actually apply knowledge and skill and come up with something you haven’t thought of before.

I can’t remember where I read it, but someone said that Microsoft will deliberately ask you questions you can’t answer. This makes perfect sense–asking questions you know the answer to does not demonstrate the limits of your understanding. As an example, if I ask you only about basic addition, I learn little about your mathematical skills–only that you’re at an elementary level, which isn’t helpful. I have to ask about multiplication, division, fractions, algebra, trig, calculus, linear algebra, differential equations, etc. up to the point where you can’t answer anymore before I know what level you’ve achieved. It’s the same with programming.

Why did I work so hard for this job? A few reasons, I think. First, I’m a bit of a nutball. Second, I saw an opportunity I was not going to let go through any fault of my own. In the end, if they didn’t want me, so be it, but I was going to satisfied that I did everything possible to ensure success. Third, I expected the interviews to be harder than they ended up being, and I expected them to ask obscure questions about all sorts of data structures. Knowing what I know now, a lot of that preparation wasn’t necessary, but I don’t regret it–for the confidence alone it was worth it.

In the end, I thought they did a great job of discussing only basic data structures and algorithms, but really making sure they got you to think. No interview system is perfect, but theirs is really good.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

Microsoft Interview Experience – Summary

Some people (I’m looking at you reddit), have complained about the length of my interview story. So sorry. I wanted to document the entire experience, for myself as well as others, so I included a lot of detail. I know a lot of people enjoy it. There are plenty of shorter experiences out there, so how else am I supposed to distinguish myself? hmmmmm?

If you don’t want to read the 9-pages worth of material, I present this summary for your edification:

  • I wanted this job bad so I killed myself studying.
  • Microsoft takes good care of you.
  • Food.
  • Golly gee, they’re nice people. Smart too!
  • The interview lasted 9.5 hours and was both difficult and fun.
  • I got an offer. I accepted.

Thank you. Please resume your comments now. :)


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

My Interview Experience at Microsoft

(If the thought of reading more than 4,500 words makes you hyperventilate, please go instead to my summary)

Please also read my Clarification on Why Study for an Interview

Like this? Please check out my latest book, Writing High-Performance .NET Code.

My Microsoft Background

Before I go into the specifics of the interview experience, I want to explain my background with Microsoft.

When I was just starting college, I got into an online community called DevHood. It was a student-focused .Net community where you could share tutorials, tips, code, and ask questions. Loosely associated with this were monthly .Net user group meetings on campus. My friend Ammon was the Microsoft student ambassador leading these meetings. By the time I’d graduated I was one of the leaders on DevHood (I’ve since dropped a few places–the site is now mostly inactive), and a strong desire to some day work for Microsoft was born. That desire has been occasionally reinforced by various MS events that I’ve been to, people I’ve spoken to, and blogs I’ve read.

Around the time I graduated I made it into an “interview” situation with Microsoft in the career center. I failed miserably. It was the first-ever interview I’d ever done with anybody, I didn’t prepare (at all), I was nervous (to the point of becoming very hot and sweating), and for some reason I thought I wanted to be a PM. Yeah….they never called me back. But it was a learning experience.

My freshman year in college is also the year I moved from using Borland C++ to using Visual C++ 6. I was also an early adopter of .Net and have generally been a fan of Microsoft. (You could maybe call me a fanboy, but I don’t think I’m completely one-sided. I consider myself pragmatic. Apple is just as good in many things as Microsoft, but I am really annoyed at the press it gets and the Apple fanboys. I think the biggest differences in OS X and Windows for most non-technical end-users are aesthetic.-Ed: please see clarifying comments below)

The effect of Google

I interviewed with Google last year, a process which I documented. Thank goodness–that experience really prepared me for this, though there were some big differences. For one, I don’t think I wanted the Google job. It was fun, nice to do, gave me a good experience, but in he end I wasn’t that disappointed. Microsoft was different. I wanted it and I prepared accordingly.

A month of e-mails and phone calls

It’s been a few months since this process started, so some of the details of timing or exact discussions may be off, but the overall story is correct.

A few months ago, I was contacted by a staffing firm that works directly with Microsoft to fill positions in various teams. I quickly responded, expressing my interest. The staffing agent who initially contacted me referred me to her boss, who was an extremely nice lady who works out of her home. She did initial questions like what kinds of things I’m interested in, can I relocate, etc. Mostly, she told me about the team that she is looking for: Live Search. She also acted as the buffer between me and Microsoft. She referred me to a Microsoft staffing person who also worked specifically with the Live Search group.

The Microsoft staffer talked to me first on the phone, about my projects, goals, Microsoft, the Live Search team, and how interested I was. He then setup a phone screen with the development lead of the team I was interviewing for, which was to take place about a week later. This phone call was postponed because of a meeting at Microsoft, and I actually did it a few days later than planned. No big deal for me, though it was a little hectic because family was visiting and I didn’t want to discuss my interviewing with them at this point.

Phone Screen

I prepared for the phone screen by writing questions for the interviewer, preparing standard HR-type questions and answers, and figuring out what I wanted to say about myself (overall), my interests, projects, current job, why I want to leave, why I want to work for Microsoft, and anything else I could think of. I also researched the team a little (I didn’t know which specific team it would be at this point, so this was mostly learning the major components of the Live Search group). I did not practice writing much code at this point.

The actual phone screen was easier than I thought, up to the end. We started with a little chit-chat, then he asked me about my current projects at GeoEye. He did go into technical details, but not too much. He asked me about my opinion on testing and other software engineering practices. I discussed unit testing and the efforts I had made to impose best practices in my current team. I was pretty emphatic in my description of software engineering practices, since I had seen such dramatic benefits in my work. We had a pretty good discussion about this sort of stuff and I felt like I was being taken seriously because of my experience. We also talked about working in teams.

After 30 minutes or so, he asked, almost apologetically, if I had time to do a coding exercise. Of course, I said yes. Oops. I didn’t do so well. With him on the phone, I e-mailed him my code at regular intervals. I took about an hour to hack out a recursive solution to a problem which I had actually never solved before. I think I panicked and not having immediate feedback I went down the wrong path for a while. I also should have thought of the design of the problem in terms of data structures, rather than just think of a vague code solution and go for it. I learned a lot from this exercise.

Even with that, he said, “I’m going to recommend you come in for an in-person interview. The coding was a little weak, to be honest, but I think you have great potential.”

He also specifically recommended reading Programming Pearls by Jon Bentley. This book was on my to-read list, so I gave it priority and ordered it, along with Programming Interviews Exposed: Secrets to Landing Your Next Job.

Preparation

My preparation for this interview was intense. I went through as many problems as I could think of. With Programming Interviews Exposed, I read 2-3 chapters at a time, making sure I understood each problem and the answers thoroughly. Then I went back and solved each problem on paper, without cheating and looking at the answers. Most problems I could have done without reading the chapter beforehand, but a few were new to me so the book helped a lot. It also helped show how many problems can be solved with creative application of basic CS principles. It also has good advice for handling salary negotiation and other non-technical aspects of the process.

Programming Pearls was even more helpful for formulating a mental framework for solving problems. I cannot recommend it enough. The material is much more deep than Programming Interviews Exposed and it will force you to think a lot more. I read the entire book and did as many problems in each chapter as I could. Most of them are thinking questions and not necessarily coding questions.

I also found and downloaded every list of programming questions I could find:

I did problems almost every night until I started to feel burned out. I solved every problem on those lists, other than some of the database/hardware/irrelevant questions. Whatever you do, don’t give in to temptation to look at the answers until you’re hurting with the effort of solving them. Memorizing the answers isn’t enough–you really do need to understand them, whether you figure it out yourself or look them up.

On the plane trip out, I reread Programming Pearls and did the problems again, making sure I understood nuances that I hadn’t noticed the first time around.

The Trip

About a week after my phone screen, I was contacted by a travel specialist who organized my trip. I was asked to provide some basic information, such as 5 dates when I could interview. I was nervous about this since I didn’t really want to ask for more days off from work, but I just went ahead and hoped it worked out. Once the date was established (nearly 3 weeks in the future), I was sent some documents on Microsoft’s online careers site. Logging in with my Live ID account, I filled out forms specifying my travel preferences, chose travel dates and times (I picked early the morning before, a Sunday, and to leave the morning after the interview). I also chose a rental car since I didn’t want to rely on a taxi. Microsoft makes all of the arrangements for you once you fill out this form.

On July 27, my wife took me to the airport for the direct flight to Seattle. It was a 5-hour trip, during which I re-read the entire Programming Pearls book. I had an aisle seat. At Seattle, I picked up the rental car from Avis–an SUVish Ford. Redmond is about a 30 minute trip up the highway and thankfully it was easy to get there. I had printed directions before I left home. I did drive right by the hotel without realizing it, and had to circle around–they’re a little back from the road, and the single sign was facing the opposite direction.

After I checked in, I went out almost immediately to find Microsoft. It was right across the street. I needed to find building 19, which is about a 5 minute trip. I then went to Azteca, a Mexican restaurant near the hotel. It was good food–too much, but very good. Microsoft pays for your food–keep your receipts. When I checked into the hotel, they told me that I could get any food from the little shop or order in and Microsoft will pay for it. I didn’t make as much use of it as I could have. I didn’t want to binge on junk on the theory that a healthy body is a healthy mind.

After eating lunch, I went back to the hotel to study for the rest of the afternoon. I went through the rest of the list of problems I had printed out. I was so exhausted by the evening, being 3 hours behind my home time zone. I had some chips and juice for dinner, and went to bed at 8. I knew it was early, but I thought I could sleep for 12 hours. Nope. I woke up at 3:30 am the next morning. Oops.

I got up, read a bit, exercised until I was bored, took a long, long shower, ate a big breakfast, and reviewed a few other coding questions. At 9:15 I gave up and left the room. My appointment was with the staffing representative at 10:00. I was there at 9:20. One thing I noticed–lots and lots of diversity. People from all over the world walking around. I reviewed a few things some more and went into building 19 at 9:40.

I got my name badge at reception and then sat down, eventually moving over to the Microsoft Surface that they had set up. The Surface is an awesome piece of machinery. There are a number of demo apps which are a ton of fun to play with. There were games, a piano, and some graphical visualizations that all interacted with multiple fingers at a time. They also have a number of PCs and an X-Box 360, which had a couple of people playing Rock Band on it.

A little after 10, my representative came out to meet me. He said he only had 30 minutes to talk, but I think we talked for almost an hour. We discussed fairly typical HR-type things. He went over some numbers related to Microsoft, then leadership of the teams from Live Search on down to the team I would be interviewing for. He discussed benefits, and then explained the day’s events. He gave me a piece of paper with an interview schedule that went through the 2-3pm slot. He said, “I can’t tell you who comes after this. If you do well, the last interviewer will take you to the next person. If you don’t do so well, they’ll take you back here and we’ll talk about it.” Yikes.

When we were done, he escorted me outside to a waiting Prius, part of their shuttle fleet that anyone can use to go among the various parts of the campus. I was headed to building 88.

The Day of Interviews

This is the part where I’m sure I’m going to disappoint some people because I’m not going to tell you the specific problems they asked me. I don’t think that’s fair, and there wouldn’t be much point anyway. I may tell you a rough description just to give you an idea.

Each interview followed a similar pattern: discuss your work, tell me about [software engineering topic] and your experience with it, now let’s do a coding problem. Sometimes I did a problem quickly and they made the problem more complicated, or gave me a completely separate one. I was not asked riddle-type questions. I was not asked dumb, typical HR-type questions (“What’s your biggest weakness?”).

Between every interview they will talk to each other and they will send e-mails to the other people in the interview loop. Yes, they’re talking about you behind your back. And yes, they will tailor future questions to cover areas missed by previous interviewers, or to follow up on a weakness. Also, not every interviewer is on the team you’re interviewing for. I liked this because it gave me an opportunity to learn more about other groups.

In the first interview, the coding problem was to generate a well-known data set. I first considered how to generate the nth iteration of the dataset, but she quickly steered me to solving iterations 1-n (which is much easier). I went over the algorithm in my head and out loud, before writing any code. Then I wrote the simplest, naive code that I could think of. I immediately saw some inefficiencies and worked to address them. She prodded me slightly to the answer she was looking for (I would have gotten there).

The first interviewer was also my lunch escort. We went to a cafeteria in a nearby building. I got a salad–not trusting my stomach for too much more. The food is not free, but it seems pretty cheap (coming from DC). The drinks are free. I got water. During lunch, I spent most of the time asking her questions about what she does, working at Microsoft, and the Redmond area.

After lunch, she took me back to the lobby to wait for the next interview. I took the opportunity to use the restroom and look at the art (there is original art everywhere). I liked the boat made from junk.

The interview after lunch was with the same person who gave me the phone screen–the dev lead for the team. He asked me if I had looked at the project they work on, and as soon as I said I had, he asked me what I thought they could do better, or features to implement. I was prepared with some intelligent things I noticed (which luckily coincided with some of the things he had first noticed when he joined the team). We talked for a bit about software engineering, testing, and task “chunk” size–i.e., how big of a task am I comfortable accepting at a time. This was an interesting topic which I hadn’t really considered before, but after a little time understanding the question I used my experience to give an honest answer.

He gave me two coding problems. Actually, before that he had asked me if I had ever done a certain problem and I answered that I had. So he gave me another one–a geometry/graphics-related question (not too deep). I had seen the problem before when taking computer graphics in college, and I knew the form of the answer. I just had to write specific code. Then I had to explain as many test cases as I could for the function. That problem didn’t take too long so he gave me another–a function to score a round in a certain game (one that I hadn’t played for a long, long time). He explained the rules, I explained them back as I understood them, and then I verbally sketched an algorithm to solve it. I wrote the naive code, fixed some algorithm mistakes and inefficiencies and I was done. I think I did well on this.

Then he took me to my next interview, which was the dreaded 2-3pm one. The same pattern ensued. This was a maze problem, and though I struggled a little solving it, I had immediately known that depth-first search was the way to tackle it, which was what he was looking for.

And…what happened next? Was I done? Do I get to continue until 5pm or am I done?

He took me to the next interview. :)

The next one might possibly have been my favorite. The guy I talked to had a lot of patent cubes, so I asked him about those and what his previous projects were. He then asked me a very interesting conceptual/coding problem about how to design a filter for the Live Search engine. We talked through it, and I came to a decent solution, which I then had to code. Definitely the most interesting problem of the day.

Then on to the next…it’s 5pm now. They’re offering me food, but I’m politely declining because I just don’t eat in high stress situations like this. That might be bad, but it worked for me.

A little bit of talk about software engineering practices, working in a team, etc. Then he gave me an array-summation problem. I was very familiar with this problem and explained that I knew a naive way, but that it wouldn’t work in all cases (i.e., bad input). He asked me to explain the problems, which I did. It was more like a discussion. He then gave me a tree-related problem, which I solved very quickly because I had practiced the exact problem before. Then he made it harder. He gave me a hint which at first confused me, but once I understood what he meant, I grasped the solution.

It’s now 6pm. I was sure I’d be done. There are fewer people in the halls now. The day is over.

He takes me to the next interview.

This is with the boss. The dev lead’s boss. I’m unsure of his exact title, but he was in charge of the team I was interviewing for and one other.

We talked for 45 minutes without a hint of coding. This was a wide-ranging discussion about everything from MS benefits to housing to traffic to the future of the team, the impact of Yahoo, comparison to Google, and culture at Microsoft. I gained a lot of insight and appreciation for what they’re doing. At one point he started talking salaries and benefits, and I got extremely excited and I had to fight to keep a smile off my face (hey, I don’t want to look like a dork too early). I was thinking that they were definitely going to make me an offer. Then he said other things which made me come back to reality. Finally, jokingly, almost reluctantly, he said he may be obligated to give me a coding problem, so let’s do a quick one.

Looking back, this should have been the easiest problem of the day, but I just got off track and missed the (now, painfully-) obvious solution. It was a problem about finding the nearest object in a geographic region. I cringed when he suggested the golden hint to me, and my thought was DUH. Maybe it was too late and I was tired.

Finally, at about 7:30pm I was done. He called the shuttle dispatch and walked me out, where we chatted for a few minutes before I insisted he didn’t have to wait with me.

Aftermath

I drove to the hotel and called my wife. I was elated. I knew I hadn’t been perfect, but I had just gone through a 9.5 hr interview. That couldn’t be bad. I thought for sure I was going to get an offer.

I ordered some Thai food from a delivery service, which I ate starting at 9pm. I watched a little TV, then went to sleep. I woke up at 4am the next morning to head to the airport for an early flight home. It had been a very long day.

The next day I talked to the staffing guy (the one who had started my interview day) about the experience. He was very…confusing? not sure how to describe my interaction with him. He told me that they were very happy with me and I did very well, and yet some of the feedback indicated slightly weaker coding than someone else they were interviewing. He needed to hear back from the team about the other person before a final decision was made.

Needless to say, this was not what I wanted to hear. I was pretty upset about it so my wife and I indulged in a little night out dinner to assuage the disappointment. I was sure I was not going to get the offer.

Two days later, I was at work when I got an e-mail from him. They are going to make me an offer! I quickly left the room (I share it with a co-worker) and called my wife. She was ecstatic. I was ecstatic. I was not expecting it, after the previous conversation. Looking back (and considering other conversations), I wonder if he was trying to gauge my dedication and desire for the job. My other, more cynical, thought was that he was trying to prep me to take a lower salary or not negotiate as hard because I must have “just squeaked by.” Maybe it’s just to make victory all the more sweeter. Most likely he was on the level, but I do wonder… it just seemed odd.

That night when he called, I was feeling pretty miserable because I think I was food poisoned that day–I was feeling horrible–vision was literally shaking–very scary. But I kept it together and we talked benefits, salary, relocation, and the next steps. We did the “what-salary-do-you-want/what-is-your-offer” dance, which I lost of course. Does anyone get an offer without stating their expectations first? In any case, the formal offer was worked out over the next few days. I was on vacation in Utah when I got it (all electronic). It was acceptable and I am now going to be a Microsoft employee in September!

Random Thoughts

I’m going to go work on a team that is a direct competitor to Google, and they are a very significant challenge. Microsoft has a lot to do to catch up to Google, but there is something exhilarating about working for the underdog. Even once the technology is better than Google’s, there is significant mind share that needs to be won. We all have our work cut out for us.

This is completely subjective and I’m biased, but I thought the people I interacted with at Microsoft were nicer than at Google. Maybe it’s because I did better, maybe it was my attitude, or maybe I was lucky with the people I spoke to.

When I drove up to the Microsoft campus the first day, it felt right.

There’s a lot to do in the next month–prepare the move, finish up stuff at work, prepare to buy a house, gear myself up for a difficult, demanding, but rewarding job–it will be a lot of work, but hopefully fun at the same time.

Tips

My tips for the Google interview experience apply here. In addition:

  1. Be enthusiastic. I got the distinct impression that they value this highly. Demonstrate it with your projects, your interests, your conversation, and even your tone of voice. That last is a hard one for me, especially over the phone. I’m enthusiastic, but I definitely have a hard time showing it verbally.
  2. Practice, practice, practice. Spend a lot of time practicing with pen and paper. Write out every search algorithm by heart. About half the problems they asked me are in the two books I recommended above. But beware that they’re going to expect you to go beyond those problems. Consider these problems as refreshers in basic computer science, not a primer to help you get the job.
  3. Know your computer science. If you don’t understand serious computer science, memorizing answers to lists of problems isn’t going to help you. Understand recursive and iterative solutions to common problems. Know data structures, big-O, and common algorithms. Know what methods and data structures can be used to solve which problems. You probably won’t be asked about advanced data structures or techniques–you just need to understand the basic ones really well.
  4. Know the team. Research as much as you can. In my case, I knew what the project was and I could actually use it and come up with suggestions. This may not always be possible. If not, learn about the larger organization that you can get information for.
  5. Have lots of intelligent questions. Many questions I asked to most people. Here is a sample: Favorite thing about working at Microsoft, Least favorite thing; My specific role. How big the team will be grown, impact of external events, comparison to competitors, strategy, where will the team be in the future, what’s your commute like, work-life balance, what do you work on (since not everybody you talk to is on the same project), what is your specific role, what other projects have you worked on at/outside of Microsoft, why did you move to this team, and lots more. The important thing is to be genuinely interested. If you are, then coming up with questions on the fly is easy, and you will have a natural discussion rather than reading a script. I moved from “script” to “natural” through the day as I became more comfortable.
  6. You must know what you’re talking about. This allows you to have nice conversations instead of feeling like you’re being quizzed. You’ll feel more like a peer, and hopefully so will they. You’ll already belong. Also, you can’t fake this so don’t try.
  7. The interviewers at Microsoft seemed much more willing to give me instant feedback than Google was. I could ask them what they thought of my code and they gave me honest feedback. I appreciated this.
  8. The book I read on the way home was The Neutronium Alchemist by Peter F. Hamilton. It’s the sequel to The Reality Dysfunction. Highly recommended for sci-fi fans.

Redmond, here I come.

Related links:


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

6 Programming problems you don’t want in the interview

1. Write out all floating point values between 0 and 1.

2. Write tic-tac-toe in Brainf*&$

3. What is 2128 in decimal?

4. Solve traveling salesman in constant  time (O(1))

5. How many grains of sand are there in the Sahara (at a given instant, assuming constant, well-defined boundaries)?

6. Implement quicksort on a spherically linked list.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

Free Resume Review – Professional Service

I’ve mentioned Free Resume Review before, but I want to now mention their paid services. In addition to their free offerings, you can make a payment and get even more options and services, including:

  • Increased chances of securing employment. Our resumes have a high rate of success in landing interviews.
  • A contemporary, stylish, unique digital resume or cover letter.
  • A personalized resume or cover letter. No templates!
  • Free review of your new resume or cover letter as often as you like.
  • Confidentiality: Unlike some other sites, we will not share your personal information with anyone.
  • Personal contact and expert advice from a resume or cover letter professional.

Go check them out if your looking for resume advice, need a career change, or just want to see how your resume measures up. Also, thanks to them for sponsoring BuyMeALego.com!


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

More on Google interview

This a follow-up to my previous post about my interview process with Google. Once a post gets as long as that one did, I’m sure to forget to say some things. Rather than updating that post, I thought I had enough new to say to warrant a new post.

First is the picture I got of their development process. There are plenty of other places on the Internet about their development process, so I won’t go into detail about what they told me–it pretty much matches up with the available information. It really sounds like they try to match the amount of process required to the specific project at hand. Projects with a huge public impact have lots of process (Google’s front page, indexing, etc.), while those that are newer and much lower impact (stuff in the Labs section, and even graduates of the Labs) have a much more flexible, agile process, designed to get improvements out the door very quickly. I like that–no mandatory bureaucracy where it doesn’t make sense.

Aside from process, however, it seems that they are very intent on giving developers an environment designed to help them succeed. From what I understood, the company actively tries to remove stupid barriers to productivity (needless paperwork, poor IT, bad workstations) and give you whatever you need to do your job how you think best. Obviously, there are rules and standards, but it just sounded more flexible. It really sounded like an ideal development environment: Obstacles removed, needs granted. Now, how much of that is the official “show” they put on for all interviews, who knows, but Google is obviously doing something right.

Bottom-line is that Google is a company of engineers for engineers. They’re the ones in charge of what the company does. That is a very nice place to be if you love coding.

Also, I should mention that the Google Boston office is MUCH smaller than their Mountain View headquarters. The way things are done, while it will still be “Googly”, will most likely have a different feel and pace than at headquarters. I had read many reports on the web about how people worked late hours, on weekends, and basically sacrificed their lives for the company. I did NOT get that impression in Boston. They were definitely smart and very hard working, but it sounded more like the company was flexible and if you got your work done, who cares? (That’s the way things ought to be done for sufficiently self-motivated employees). I did ask about inordinate over-time (mistake on my part?) and work-life balance and I came away with a satisfactory impression. Whether this means Boston is special, or the accounts I read on the Internet were not representative, I don’t know. Probably a lot of the latter, for sure.

I also wanted to address my final link in my last post. I know it can be a little disappointing to read that kind of post and realize it’s not talking about you, because you’re interviewing for jobs. I wouldn’t take it too literally. Maybe my link text is a little black and white. I think the principle is definitely valid, though. The better you are, the more freedom you have to choose where you work and what you work on and the less chance your going to fall into a company’s hiring process. It’s really more about statistics from a company’s point of view of finding the best, not necessarily for individuals.

Hopefully, that’s all I have to say on the subject, but if you have questions, just leave them in the comments and I’ll try to answer them!


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

My interview experience with Google

(See also part 2 of this article).

A few months ago I received an e-mail from a recruiter at Google asking for an opportunity to talk to me about available development positions. Needless to say, I was pretty excited. I’m fairly happy in my current job, but–it’s GOOGLE. You don’t say no to an interview opportunity at Google.

Like this article? Check out my latest book, Writing High-Performance .NET Code.

I’m writing this account in order to contribute to the meager resources available on the Internet about the Google interview experience. I signed an NDA, so I’m not going to say what the specific questions were, but I think I can give a pretty good idea of my experience. I apologize right now for the length.

I traded a few e-mails with a recruiter in Mountain View. I had a phone conversation with him, wherein he asked me general questions about my skills, desired work locations (giving me a choice of Santa Monica, Mountain View, and Boston). I have no desire to live in California, so I chose Boston. I was then passed to another recruiter, who setup a phone interview with an engineer in Mountain View. There was a false start, when they couldn’t do the interview at the original time, so we postponed.

The phone interview went very quickly. He was very nice and asked about my specific talents, things I enjoy doing, and projects I’d worked on–especially those I listed on my resume. He asked about the ray tracer I wrote in college, since he had an interest in that. He also asked some general questions about the stuff I do for work. Then he got into the technical question. It was an interesting problem, and I asked follow-up questions, talked out loud, wrote things down in front of me (and told him what I was writing and why). I immediately thought of the naive solution–always a good place to start. He was interested in the asymptotic complexity. I knew there were better ways of doing it, so I started thinking of optimizations to the algorithm, trying to come up with ways of caching information, reusing previously-computed values, etc. He gave me some gentle prodding, and I think I understood immediately where he was going. I answered the question fairly well, I though.

And that was it–just a single question. I was surprised. The entire thing lasted less than 30 minutes. I was almost disappointed, and thought–“well, that’s that–I won’t hear back.” I really wasn’t expecting any follow-up.

The next week, I got an e-mail from my recruiter who said I had impressed and was going to get the opportunity for an in-person interview in Boston! They hooked me up to a travel coordinator, as well as the recruiter in Boston.

Very exciting. I had a convenient time to go, so I set that up, took time off from work and went up to Boston, staying in the Cambridge Marriott. Very nice hotel. 40″ flat screen TV in the room ( which I never turned on). All expenses paid for, of course. :) I did have to pay for hotel and food up front, and save the receipts. (And yes, I promptly received a reimbursement check from them a few weeks after I sent them in.)

I arrived on Monday afternoon, figured out Logan International (a very confusing airport, I thought), and got myself to Cambridge, in the heart of MIT, an hour or so later. I checked in, then went walking. I found the building Google is in on the very next block from the hotel. They have a floor in a building that MIT leases to startups, tech incubators, and the like. There are plenty of news articles about the Google Boston office–just…you know, Google for them.

I walked past the ultimate geek bookstore–

Quantum Books. Discount tech books. COOL. I would definitely have to stop there later. Then I got some cheap, awful Chinese food at the food court

right under the hotel. Why? When I could go out on Google’s dime? I think I was just tired and wanted to get back to the hotel soon and start studying.

I ate dinner in the room, took pictures of the wonderful view of the Boston skyline.

Boston Skyline (Day)

Boston Skyline (night)

Studying

What did I study? I brought two books with me: Robert Sedgewick’s Algorithms in C++, and a C++ reference manual. I went over advanced C++ topics, STL, simple sorting and searching algorithms, properties of graphs, big-O, and anything else that popped into my head.

By far the most valuable thing I did was write out algorithms before-hand. I picked something and wrote it out by hand in a notebook. It was hard going at first, but I knew it was the best thing I could do to prepare. I did selection and insertion sort in both array and list form. I did string reversal, bit reversal, bit counting, and binary search. All by hand, without looking in a book at all. As well you might know those simple algorithms, it’s harder than it sounds.

I went to bed relatively early–9:30, and woke up the next morning at about 6. I went to breakfast in the hotel restaurant, got a rather large meal, and then headed to my room to study more. I wrote more algorithms and redid some I had done the previous night.

Oh, I also wrote down in my notebook (beginning on the plane ride up) questions for Google, as well as answers to questions they could ask me (standard interview fare–projects, favorite project, languages, strengths, passions, getting along with people).

My interview was scheduled for 10 am–I checked out at 9:30 and left with my bag (I had everything in a single bag I could carry–it was very heavy) and sat in a little square for a few minutes. At about 9:50, I went in, took the elevator, and was greeted with:

.

. (ready for it?)

.

The Google

Dr. Seuss land! Yes, that was my first thought. I think the door was green, the reception area was very colorful. The receptionist was very nice and asked me to sign in on a computer, which printed a name badge for me. They had some research papers by Google employees on a wall, so I grabbed a couple (their hard drive failure study, and map/reduce). After a few minutes, my Boston recruiter came out and greeted me, offered me a drink from their free fridge, and took me to a small conference room, furnished, it appears, from Ikea. It was simple, clean, and very nice. There was a white board. I would get to know that whiteboard very well.

My first interviewer came in and we got started. I talked about my projects for a bit, they answered my questions, and then we got to the problem. Each interviewer asked me to solve a single problem (could be some sub-problems involved), and I had to do it on paper or on the board. I wrote C/C++ code. They take note of what you write and ask you further questions, especially if your first solution isn’t optimal.

I tried to take extra care with my code and not let stupid mistakes creep through. I used good variable/function names, made sure my braces matched, and I ran through the algorithm on the board once I had written it.

The first interview was one of the toughest. I was more nervous. I think I made more mistakes–I didn’t see things as quickly as I did later.

I had three interviews before lunch. They then handed me off to someone else who would not be evaluating me, but would just be an escort for lunch. The Google cafeterias in Mountain View are legendary, but the Boston office is far too small to warrant such lavishness. Instead, they have a catered lunch every day. It was wonderful. They also have all the free drinks and candy you could want, available all the time. I spent much of the time asking my escort questions about Google, what he was working on (couldn’t tell me), the area, the office, the commute. We were also joined by the head of the office, who didn’t realize I was an interviewee, and we had a nice conversation as well.

Lunch was an hour, and then I was back in the conference room. I had two more interviews. Then the recruiter came back in at about 3:15 or so and debriefed me–asked me my impressions, how I felt. I reiterated what I had told him on the phone previously, and that morning before we started: that I was trying to take this as easy and nonchalantly as possible, to have fun, and learn, and let it be a good experience. I had a job that I enjoyed, and didn’t NEED this one, but I think I would do well there and enjoy it very much. They came to me, after all.

I think by the end of the day, I was really pulling that off well. Once I got over my nervousness in the first interview, I really did have fun and enjoy it.

General Notes

They didn’t ask me any stupid questions. None of this “what’s your biggest weakness?” garbage. Not even the recruiter asked me anything like that. Nothing silly at all. They also didn’t ask me easy technical questions. They got right into the problems and the code. I had to describe an algorithm for something and write code for it. It was serious, they were all nice–I met people with serious reputations online. I felt like they were respecting me as a fellow programmer–almost. I wasn’t one of them, but they really wanted to see if I could become one of them.

I did receive prompts to get through certain problems, but not overly so. I answered every question they asked. Some I answered better than others, but the ones I didn’t get right away, I had alternate solutions, and I understood where they were going as soon as they started talking about it.

Why I didn’t get the job

Well, companies these days won’t tell you why. I think they fear it opens them up to lawsuits. I think that’s silly. It prevents those of who really do want to learn and improve from knowing what we’re deficient in. Oh well. They told me that they thought I would do well at Google, but that it wasn’t a good fit at the time, and I should apply again in the future. (Of course, I didn’t apply in the first place.)

My suspicions, however, are that I lean too much towards Microsoft technologies. I do a lot of work in .Net. That’s where more and more of my experience is. I do consider myself very good in C++, but I’m doing more and more C# work. I’ve always been a Microsoft Windows developer.

I also am not really interested in web-centric technologies, and I told them so. I’m more interested in client apps on the desktop, and server apps.

Of course, it’s very possible I just didn’t answer the questions to their satisfaction–that I needed more prompting than I should have. Oh well.

It could also be that my GPA wasn’t what they wanted. I goofed off my freshman year of undergraduate work. I really hurt my grades. I came back, though, and got straight A’s for my last few years where I took the hard CS classes. I also got straight A’s in my Master’s program while I was working full time. I don’t think this was the issue, but it’s possible.

Lessons

  1. Having your own web-site is a no-brainer. Do it. Update and maintain it.
  2. Do personal projects. You must be passionate, you must love programming. You must be good at it. Not average. You must aspire to excellence and be working towards that.
  3. Know what you’re talking about it. Don’t show off–just display your knowledge as it applies to what they asked you.
  4. Use an interview with them as a learning opportunity and ensure you have a good experience regardless of the outcome.
  5. Don’t take the interview too seriously. Make sure that not everything rides on the outcome. You must be comfortable, confident. You must try for success in every possible way, but yet be completely prepared to fail–and have that be ok. This is a hard balance to achieve, but I think it can really make you have a healthy outlook and have a good time while still showing your best self.
  6. If you don’t get an offer, realize that even being selected for an on-site interview by Google puts you above the ranks of the average-good programmers. Google gets 1,500 resumes a day. You’re already in the < 1% percentile.
  7. Practice writing code by hand in a notebook. This helped more than I can express. Do stuff that’s hard that you don’t know how to do immediately. Time yourself. Make the problem more challenging. If you can’t stretch yourself, they will and you’ll probably break. They did not ask me to do any of the specific questions I had practiced–but the experience writing out and the THINKING is what helped.
  8. Be able to explain your background (90% technical / 10% personal) in a few words. At some point you’ll be asked.
  9. Have a lot of questions for people. You’re interviewing them too. Make sure they’re good questions. Asking about salary is not a good question before you’ve been made an offer.
  10. I let the interview build my own self-confidence. I have no doubt that I could walk into an interview anywhere else and it would be laughably easy.
  11. Don’t ignore obvious, simple solutions. Sometimes a table lookup is better than an O(n) algorithm.
  12. Bring a good, FUN book for the plane ride back. On the way, I focused on the interview, but on the way home I wanted to do anything but, so I had my current novel (Dickens’ Bleak House–very good book, by the way).

If you do all of those steps, it actually doesn’t really matter if you apply to Google or any other great/famous company–you’ll probably get the job you want for the pay you want anyway. Somebody, sooner or later, will come across you and give you the opportunity.

Great programmers will rarely, if ever, need to look for jobs.

I hope this long, rambling essay is helpful to some. I make no claim that my experience is typical or that I’m being completely objective. In other words, YMMV.

Read part 2 of this article


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at: