Interviewing @ Google - The Internship

---

Interview 1

The phone wouldn’t ring.

It was time for my first interview with Google. An empty notepad ready to go. My notes prepared with delicious anecdotes and resume accomplishments. The latest brainteaser jostling in my head. Any potential stress knocked out by a jaunt at the gym. I was a lean, mean, interviewing machine. I was ready.

But, the phone wouldn’t ring. Three minutes passed. Five minutes. Eight minutes.
Something was wrong, and I had a hunch it was my future intern prospects at Google.

I finally checked the phone to realize that it had shut off the cellular radio. The “No” symbol almost nagging me:

• Do Not Receive Calls.
• Do Not Receive Interview.
• Do Not Receive Internship.

The poor little radio had given up hope of ever receiving a signal from the gym lockerroom and had taken a nap. Even an hour or so later, it was oversleeping. Panic started to creep in as I restarted my phone.

Sure enough, a voicemail from a very prompt and likely very busy Googler sat on my phone accusingly. By the time I returned his call, we had already eaten up the interview time slot. He took the situation well, and figured we’d simply reschedule. Now, despite the way he made it sound simple, I couldn’t help but consider I’d already ruined my chances. No one simply doesn’t pick up when Google calls – at least, potential future employees. Once that feeling abated a bit, I began the process to reschedule and got something later that week.

Interview 1 – Redo

Same prep as before. Cute stories. Delicious brainteasers. A freshly restarted phone. I was taking no chances with a fatigued radio.

And, ultimately, it was an interview. A rather normal interview. Nothing overly Googly, complicated or nerve-racking. There were the general ‘Tell-Me-About-Yourself’s. There were a mix of behavioral questions and a handful of tech-related questions. There was a chance to learn about the role, the culture, and the challenges at Google. But nothing out of the ordinary, at least, until one of my metaphors failed me.

It was a simple question: Explain object-oriented programming to a five-year-old/grandmother/tech-illiterate person.

Well, whether it was nerves or just plain mental fatigue, I felt I did not answer this to the best of my ability. I used a very simple metaphor of vehicles such as cars and motorcycles with certain similarities such as engines and tires to try to cover inheritance and polymorphism. Trust me, that sentence sounds better than the blather I remember leaving my mouth at the time. For some reason, my metaphor didn’t flow as neatly as it could have. It was disheveled and worn. I felt that sense of devastation rise back up as the interview came to a close.

Well, I couldn’t help but think that my Google experience was over. I had missed an interview call. I had bedazzled my way to an ugly answer. There were obviously candidates that already showed greater promise than I, surely – more clarity in their answers – more reception in their cellular radios – more likelihood of continuing.

Interview 2

Well, I was definitely a little surprised when I got the email scheduling a second interview. I prepped similarly with another cell-phone restart and a greater sense of what to expect.

This interview was wonderful. It was conversational. It had the same mix of tech-related questions and behavioral scenarios. Have I ever had to tell a client No? What are certain command line tools? And, it had one rather simple brainteaser. I don’t even know if I can call it that, actually. There were no blenders and microscopy involved. There was no man-hole cover shenanigans. It was much more of a simple problem solving question that involved a 3D object - a rubix cube. So, it was basically just a math problem that involved mental visualization and counting corners, edges, centers. So, if you can picture that in your head, you could've answered the question.

All in all, I left this interview very hopeful.

Interview 3 – The Code

The final round – complete with instructions on how to write code in a Google Doc for the interview.

I was a little worried. To put this in perspective, I was at that time a business student. Before that, I was a consultant. I had not touched code professionally in over three years. I hadn’t even touched it recreationally outside of HTML and some CSS tweaks (which don’t count). So, I definitely tried to prepare. I started trying to write little python scripts by hand. Instead of doodling during classes, I was reviewing arrays syntax, linked-list puzzles, and transversing trees. Real hardcore freshmen CS-student level stuff. While my peers were learning microeconomics, I was reviewing my undergraduate education in data structures.

The interview started simply enough with some basic tech questions on my experiences with mySQL. Basics that I only distantly remembered from my days as a developer - UNIONs, JOINs, IN, OUT. I was able to toss an answer together from sparse memory, but I was starting to worry. The mental perspiration resting on my brow. Finally, the battle was moved to the Google Doc. I was provided with a simple algorithm and told to go.

Well, long story short, I’m pretty sure my code wouldn’t run. My syntax for one my loops was wrong – a pretty simple ‘For’ loop too. I knew it was wrong, but I didn’t quite know how to fix it quickly without a large refactor. Time was running out. I told my interviewer this. That I would have to review the syntax. He calmly told me to just put a comment at the line in question. He calmly told me that interviewers weren’t necessarily expected to write working code. Of course, like any sane interviewee, I didn’t believe him. Once again, I assume my competition wrote flawless code – a perfect program worthy of printing and framing (assuming such an ideal exists). I assumed my competition would get the job.

I figured this was the end of the line for me. Do not pass Offer. Do not collect Google Internship.

However, I still had some hope.

This was not my first programming interview. This was not the first time I had designed a simple algorithm for an audience. And when it comes down to it, I am not a horrible computer scientist. Before I wrote a lick of code, I fully captured my inputs, my outputs, my edge cases, my potential exceptions and my future tests. I asked, clarified, and slowly deciphered the algorithm. I also did it out loud. If my interviewer wanted a tour of my thought processes, I was going to be the best guide possible.

Once I fully understood the problem and how I was going to test my solution for success, only then, did I put code to doc. This part actually did not take all that long. (It was a pretty simple algorithm.) The code had a safe landing place of process and consideration. I knew what was going in, what was going out, what success conditions and failure conditions were. In short, I MBA'd the algorithm.

Lastly, for almost the last third of my time, I tested my algorithm out loud. No command line. No console. I took the tests I had determined previously and walked my interviewer through my code for each test. I worked through the zeroes, the extremes, the zigs and the zags. Only when each one of them passed was I proud to say I was finished. My solution had been fully explored, written, and tested.

Ultimately, my code may not have ran, but my algorithm certainly worked.

return Conclusions

Well, in the end, I received an offer. I was still kinda shocked. I assumed they would let me down by phone, and I was not expecting anything positive. I thought I failed the first interview. I thought I failed the third interview. Deep down, part of me doubted I even deserved the opportunity (I was just a chicken farmer from Ohio). There had to be a mistake. There had to be more effective candidates than little ol’ me.

Anyway, there is an interesting comparison with my business school peers. The majority of them strained, practiced, and learned how to handle a case interview. “Case in Point” books got passed and borrowed. Practice cases filled most breakout rooms on weekends. Where I had to solve a problem with code, they had to do it with a table and business frameworks. However, the questions are very similar; they are all just dressed up problem solving. Code interviews, case interviews, and brainteasers are all just wrapping paper to a problem. The point is to see how you unwrap that problem. And, whatever the kind of interview, whatever the kind of question, the first step is to always, always, fully understand your problem.

---

PS My first day at work was briefly made Internet famous on ValleyWag

---

_{Hero Image - Flickr}

---

_{Career and Job-Seeking Posts
Starting at a Startup}
^{The Modern Job Hunt}

---

^{Follow Me|| Google.init || SomethingSubtle.com || New to Steem?}