Late 2013 – mid 2014 was a busy busy time. I was employed full-time, but was not happy with pay or benefits. I interviewed at several high-powered places, and a startup. It was a lot to keep up with. I made this table to keep track of everything.
Sent email to hiring manager for several positions
Accepted permanent offer
Contacted me via LinkedIn
Hiring manager sends me email
Applied and immediately turned down
Talked to manager of one team
Talked to friend from Google
Contact from LinkedIn
Another phone screen
Technical Phone Screen
Technical Phone Screen
Technical Phone Screen
Technical Phone Screen
Onsite Interview – Seattle
Onsite Interview – Mountain View
Onsite Interview – Mountain View
Announcement that Klink was shutting down
Mozilla CEO scandal – manager reconfirming acceptance
Last day at Klink
First day at Mozilla
So, at the end of this process, the company I had been working at disappeared, and I got only one offer rom the other places I interviewed at. The real bummer is that all of the other opportunities were software developer or software manager positions, but the offer was for a QA job. That was disappointing. Nonetheless, I needed the work.
Right after the new year, I got a message on LinkedIn:
How are you? I see you are at Klink, is that still correct? We know there is awesome talent coming from that company so naturally I wanted to reach out to you.
I’d love to have a chat with you about some of our confidential projects at our headquarters in Mountain View, California and ultimately see if your interests align with things we have going on over here at Google right now, or in the future. I’m available most days, what time and day would work best for you?
Look forward to hearing from you!
So, the last time I had interviewed with them was in 2000, which was before they went public, and before they became “Google” and started interviewing “the Google Way”. I also applied to them in 2008 when they had their first Austin office, but they turned me down. In the 14 years since I first interviewed there, they had become one of the most famous companies for software engineers. The thing that Google did from the very beginning is: They got rid of schedules.
There is a lot of literature out there about scheduling and managing software projects, starting with https://en.wikipedia.org/wiki/The_Mythical_Man-Month written about the OS 360 project at IBM in the late 1960’s. The conclusion that all of them have reached is that scheduling software is hard/impossible. There is a lot of literature that hard dates are one of the most destabilizing constraints on a software project. So Google got rid of them. They embraced software management methodologies such as Agile are a way to promise small, discrete deliverables. They had started writing books and giving talks about how they did things.
In 2000, they were just another startup, with all of their engineers on a death match towards an IPO. In 2014, they sounded like a software paradise.
And they were recruiting me. Wow!
I was star-struck. I knew that if I was hired by them, I would have to work in California, but from what I understood, it would have been worth it.
I replied that I was interested, and the recruiter wrote back:
Thank you for getting back to me so quickly and I am glad to hear you think so highly of Google and that you are interested in possibly exploring opportunities. I am looking forward to chatting with you soon.
How does your schedule look next week? Does Monday, January 6th work for you at 9:30am PST? Let me know if that works for you.
An updated copy of your resume along with the names of any current Google employees you know will definitely help us to streamline our conversation and the process as a whole.
Looking forward to chatting with you soon and happy new year!
I sent her a list of 19 people I knew were currently working there, and my updated resume. And we talked. She talked about their organic product model. She also mentioned that if they did make an offer, I would have 90(!) days to report. The next step was a technical phone screen.
And they sent me an email with all kinds of information in it, such as the following links:
And then, they sent me a tome on interview preparation. The first part:
First off, don’t be intimidated. A lot of candidates find the interview process to be challenging, yet fun! That being said, candidates who spend ample time preparing using the below guidelines tend to do far better than those who do not.
There were then pointers on planning ahead, what to expect, how to succeed, what Google is looking for, further reading, and technical preparation tips, including studying complexity, sorting, hashtables, graphs, math, operating systems, coding. Coding could include constructing/traversing data structures, implementing system routines, distilling large data sets into single values, data transformations, …
And it finished with:
I know this was a lot to read, but I wanted you to be prepared.
It was very long email with a lot of detail, and despite the admonishment not be intimidated, it was totally intimidating. So I started reading my old algorithms book, but realized that a book where the pseudo-code was written with Pascal might be a hindrance. I bought the more modern version in Java, Algorithms, 4th Ed (Sedgewick/Wayne)
Then, one of my old friends from Apple who was working at Google got in touch with me, and chatted with me about the interview process at Google. It was good to hear from him, but he basically repeated what that long email had said.
So I did the phone screen. A man from Singapore called me(!). The problem was a reasonably simple graph algorithm problem. I thought I did well on it.
They took quite a while to decide on next steps. I told them truthfully that I had two onsite interviews scheduled in the next couple of weeks (one at Amazon, and one at Mozilla). She acknowledged that, and said that she would “try and speed up our process on my end as much as possible.”
A couple of days later, I was informed that they wanted to interview me onsite! That was exciting.
The logistics were fun; I was already interviewing at Mozilla in Mountain View on the Tuesday after President’s Day. Working with both companies, we agreed that they would split my travel costs, and that I would interview at Google Thursday after President’s Day.
I got yet another copy of the long email about preparing for the Google interview, except they told to expect 5 45-minute technical interviews with a Google Engineer.
The day finally came. I arrived at the GooglePlex to discover that it was really different than when I went in 2000.
Looking back on it now, I can see that I did not do particularly well.
Session 1 was some kind of string processing problem. I remember doing well on this one.
Session 2 was about what it he minimum number of squares/moves that a bishop would need to move on a chessboard. I tried to solve it with math; probably would have done better using a graph.
Session 3 was an architecture session. I never know how to gauge these; I still don’t really have enough experience in this area to do super well on these.
Had lunch with an engineer. They were totally boring. Gave one or two word answers to all of my questions.
Session 4 was all about figuring out how many regions a given point touched. I had a brain fart on the exact terminology for exponential complexity, but this seemed fine.
Session 5 was a disaster. The interviewer’s English was really hard to understand. The problem seemed really really basic, but required a large amount of code. I kept trying to find clever ways to avoid writing all of that code, but the interviewer was having none of it. I wrote and wrote and wrote, and I still feel I missed some point somewhere that would have made the problem easier…
And that was that.
The next post will wrap up the late-2013/early 2014 job search, with a timeline, and what actually ended up happening.
After the day of interviewing at Apple, I had dinner with a good friend who I first worked with at Cygnus. After discussing the individual interviews, he asked if I were interested in working at Mozilla, the non-profit responsible for Firefox. He and I had worked on open source software at Cygnus, and Red Hat, so I was intrigued. He mentioned that his former boss at Cygnus, a truly great manager, was the head of QA, and that we had another couple of friends who worked there as well. I told him I would look at job listings when I got home.
I applied to five positions, and used his name as a referral. However, Mozilla told me that nobody was interested in any of the five positions I applied for. My buddy then told me that I should contact our mutual manager friend.
I managed to get that guy on the phone. We caught up a little bit, and then I told him that I had had dinner with our friend, and that he had expressed interested in my applying to Mozilla. VP of QA friend told me I should email this other manager, who, in the interest of not getting lost in all of the different people I talked to, I will call Cliff. I sent Cliff an email right before the winter holidays, and waited to hear.
Right after the holiday, Cliff put me in touch with a hiring manager on the Firefox OS team. Firefox OS was Mozilla’s attempt to write a phone operating system, whose apps were all based on HTML5/CSS. They were ramping up automation testing. I talked with that manager, and things seemed to go well.
The next person in line, a few days later, was a veteran QA engineer. We talked about testing methodologies, and the like.
I then talked to an engineer that I had worked with at Cygnus/Red Hat. We talked about strategies for automating testing. He described to me a rig he built to test the camera phone made out of Lego Mindstorms. That was fun.
Phone screen #4 was another veteran QA engineer. He asked me the following:
“You have 2 bugs that you think should prevent shipment. You are about to go into the final release meeting. How do you break the news?”
I basically answered that it was a situation which should have never happened. The only time this should happen is if the bugs were found less than 5 minutes before the meeting. If there are bugs in the product that serious, they should already have been discussed by management, and a decision should have already been made about them. Bringing it up in a meeting like this does nothing but alienate everybody from you. It might get the bugs fixed, but it might also get you fired. I don’t want QA to be a Product Prevention department; we are all trying to ship good software here.
This interview was scheduled for 45 minutes, but he talked to me for at least one hour and fifteen minutes. At the end he said,
I have one last question. Dev, or QA?
I had to pause a minute. Then I answered:
I am interviewing for this QA job. I know it’s there, and if I get an offer, I need the job. Is there a dev opening? Would it prolong the interview process?
Yes, it would.
Assuming I did a good job for a couple of years, how hard would it be to transfer to a software engineering roles?
That happens all of the time.
And so I told him that I was going to continue to apply to this QA role.
I was interviewing for several jobs at once during this time. I am going to wrap up the results of these in one post, after I discuss them all.