My Google UX Engineer Interview

Callie
Callie
Nov 1, 2015 · 11 min read

It’s probably a bit overdue for me to actually write this, as my actual interview experienced occurred some time ago. However, I’ve come to realize that nobody has actually written about this, so I think it’s important that I begin.

First — hi. I’m a front end engineer here in the Bay Area, and my passions are user experience, CSS, and cat videos. I wouldn’t consider myself to be much more than your run-of-the-mill mid-20s Bay Area front end developer. (Well, I guess I’m not entirely run-of-the-mill in many ways, but let’s just pretend I am, because the rest of the details Don’t Really Matter here). I’m not actually looking for a job, and I’m quite happy where I am now (and intend to stay there at this point). Edit to add, because I think this is relevant — I do not have a degree. I am working on finishing mine, but I absolutely do not have any degrees past high school.

Several months ago, a recruiter reached out to me. I have a special folder for recruiter emails —Gmail named it “spam” for me, and the cool thing is that it cleans itself out automagically. However, this one actually got through, so I opted to take a look.

It was, as you might guess, a Google recruiter. I kind of took a second look — verified that the headers didn’t point toward some other odd site and that it wasn’t from some outside recruiting agency (I try to avoid those — poor experiences in the past).

So I responded.

Getting started

If you’ve interviewed as much as I have, you know the general way that technical interviews and hiring go. You begin with the phone. In this case, the recruiter had actually emailed me about some really cool full stack opportunities — that didn’t match my passion or skill set. This was Google, though, so I unabashed responded back with how my passion’s not necessarily full stack but with the overall user experience.

They forwarded me to another recruiter, and we had a quick chat, and I officially applied for an User Experience Engineer position.

The phone screen

As per most technical hiring processes go, before you ever get to shake hands or see the insides of any campus, you have to do a phone screen. You can probably read a few accounts of how Google does theirs; for UX engineer, it wasn’t too different.

The question was incredibly easy. I don’t recall the exact one, and even if I did, I’m not really at liberty to say (mostly because I said I wouldn’t, and I like to keep promises).

Needless to say, I’d classify the question as something that anyone should be able to write if they can do basic DOM manipulation with vanilla JavaScript. The interviewer himself was extremely helpful and polite, and at the end, I had a pretty good feeling about it — and I knew I really, really wanted to get this. There were also a few intermediate-to-advanced CSS questions to ensure I actually knew how selectors and specificity worked (kudos for that — far too many front end interviews completely ignore this).

To Mountain View!

So, as the header implies — I was very shortly informed that I’d be interviewing in Mountain View! I expected that it’d be some time before I could get down, but boy was I wrong.

Large companies have become infamous for incredibly slow interviewing processes. This was not a slow interview process, but rather a very quick one. My date was set only a few weeks after my phone interview — not giving me terribly much time to cram.

The person setting it up asked if I would need any arrangements for travel or anything, really. Because I live just an hour or two away, I opted to pass on travel arrangements — but still stayed closer to campus at a friend’s house. I didn’t want to be tired the day-of.

In preparation, I consumed everything I could about data structures and JavaScript. I re-read JavaScript: The Definitive Guide and JavaScript: The Good Parts. I picked up Learning JavaScript Data Structures. (Regardless of if you’re interviewing or not, I strongly recommend all of these texts.)

Additionally, I reviewed everything I could think of in terms of CSS and user experience. I even bought a whiteboard and practiced writing search and sorting algorithms and other similar problems on it.

By the end of my preparation, I felt incredibly exhausted and ready to go.

And finally, the big day

I arrived at Mountain View only half an hour early. I stayed in my car, and spent some time doing some last-minute review, and attempting to calm my nerves. (Relevant to mention here — I have an awful anxiety disorder. I become physically ill under pressure. Think test taking anxiety on steroids.)

The campus was overwhelming. I can’t quite encapsulate the feelings of being there — of being at Google. The excitement felt almost tangible; I’d become a kid in a candy store. The South Bay area can be described as many suburbs, with lots and lots of traffic and lots and lots of big companies. Google’s campus has more or less taken over a greater part of the Mountain View area. Covered in trees, the buildings aren’t particularly towering but they are still formidable and neat. Near the center of the particular part of campus in which I’d be spending my time, there was a bed of rocks. I assume that this would have been a pond if the entire west coast weren’t enduring a pretty harsh drought.

Finally, with ten minutes remaining before the appointed time, I got out of my car and went to the lobby to check in.

The lobby area can only be described as purely Googleish. Out here, it’s pretty common to have lots of colors and people dressed casually. This lobby had a Maps car outside, and had the palette that you’d expect from Google. The person at the front desk verified my ID, and then directed me toward a kiosk where I’d make my badge. The kiosk itself was a bit difficult to use; the touch screen lagged a little bit and made it hard to scroll (I’m a UX person so yes — this does stand out to me pretty clearly as probably the most negative experience I had all day. [Please read that sentence with the hint of humor it is supposed to have.][But seriously, if you work at Google, PLEASE fix that poor kiosk’s touch screen!]) I finally found the name of the person I needed to connect with, and out popped a badge. There was a bin of clips that you could choose from — they were all Google colored clips. I chose a red clip.

Another girl sat in the lobby area; she’d finished checking in just as I’d entered the room. We talked a little bit, about what we were interested in and what we were interviewing for. I’d rather not go into details here, because I don’t want to give anything too revealing.

Finally — the recruiter stepped out. It was time.

Four scores, and several other bad puns ago

The recruiter went over the schedule with me. I would be having four interviews, and one lunch that she promised would not be an interview.

By the time the first interviewer stepped into the room, my stomach was ready to serve my mostly-digested breakfast to him. I’m very glad it didn’t, but I’ll go ahead and use that as an excuse as to why I did poorly on this problem.

When I worked customer service, we used a term on really angry or upset customers. When a customer is extremely upset, they stop listening and their head gets all tangled up. They kind of withdraw. We call this going turtle.

I went completely turtle.

The problem was a much more advanced JavaScript problem. It didn’t involve graphs or anything like that. I won’t tell you the question (as I mentioned — I promised that I wouldn’t), and even though I had never seen that problem before, its still one I should have gotten correct pretty easily. However, by the end, I took a breath and collected my thoughts. I didn’t finish the problem, but I did my best and got pretty close, I think. In fact, I looked it up later — I did get pretty close. Had I not spent the first twenty minutes tied up in a shell, I probably would have been fine. The problem itself dealt with how events are handled with server-side JavaScript — likely because of my background in developing on NodeJS.

The interviewer just reminded me — when he saw my crestfallen demeanor, I’m sure — that it wasn’t about getting the right answer but actually showing how I thought. I took it as a sign that I wasn’t completely out.

He left.

The second interview began shortly after that. This one went so much better! I actually worked through the problem, and even got to do a ton of refinement on it. This problem involved dealing with lots and lots of data, with some performance optimization thrown on top. I felt that it really got into how I approach front end performance on mobile.

I can’t tell you how well I did on it, or other specifics, but I will say that I feel confident that I did as well as any candidate with my experience would have. The interviewer and I talked a little bit, and she and I discussed other methods of resolving the problem. I’d come out of my shell at least a little bit — maybe I had some hope after all!

She left.

My third interview would be with a designer. This would not necessarily be a design interview, but rather more of a soft-type and actual UX interview.

It’s difficult for me to say what part of the entire day was my favorite, because I greatly enjoyed all of it, but I think this was very high up there. We discussed lots of topics relating to UX, how I — as a front end engineer — interact with designers, and other HR-type questions. In addition, we discussed a few UX-centric questions. I greatly enjoyed this conversation because — in general — I really like talking about UX. Not to mention, I love many of Google’s products. While I use an iPhone, I may as well still be on Android — because the entire Play suite compromises the main apps that I use on iOS. So, discussing UX and Google at the same time would certainly be something that makes me very happy.

He left, and it was time for lunch.

In an all-day interview panel at Google, lunch is not supposed to be an interview. I’m not entirely sure that mine was. I met up with the Googler that I’d be having lunch with.

We went to one of Google’s many cafes. The food there is free, as you might imagine. That cafe happened to be serving some kind of enchiladas. I had those, a salad, and some sort of cookie. The food was very good, though admittedly I barely remember it.

At lunch, the Googler and I just talked about life at Google, the kinds of projects I was working on, and what interested me. He had noticed that one of my projects pertained to World of Warcraft — so there came the expected question of why I wanted to work at Google more than I wanted to work at Blizzard. I skirted around it, as I always do, and even here I will skirt around that question. I only mention it because — it seems — even the lunch knows your resume and what you’re up to.

We also just discussed interviewing in general. He apparently worked with the person that I’d be interviewing with next, so we discussed a little bit of what to expect.

If there’s one thing everyone tells you to study before you interview with Google, it’s your data structures. I’m glad to announce that studying my data structures came into play here.

He escorted me to my next interview with his coworker.

All of my interviews — and even the lunch up until this point — had been a one-on-one. Google takes their interviews very seriously, and has people actually train to do interviewing. I mention this because, part of that process is that a future interviewer will shadow another interviewer. In this case, my interview would be shadowed by someone working in a role similar to mine.

This is the interview I was probably most prepared for. I don’t know how many problems I actually worked through, but it was a lot. And they were fun. At one point, we even did a problem I’d seen before. Word for the wise — if this ever happens to you, gently let the interviewer know. Sometimes, as in my case, they’ll have you work it out then and there. I showed my solution, so the problem was given a twist and we went into a couple of optimizations that were very nit-picky. I think the only data structure we didn’t cover were linked lists and graphs, actually.

Because I’d blazed through the problems and their variations, there was lots of time at the end for the shadow and I to go over things. We did a few CSS exercises, which I was told would not be part of my overall assessment. This made me sad, because this was the only time I was actually given anything related to CSS all day.

At the end, we kind of just chatted. My day was done, but these guys were pretty neat. They worked at a company that I could never have even dreamed of ever interviewing with, and they were pretty cool people themselves.

Oh, and they’d also noticed my project with World of Warcraft. We talked a little bit about the just-announced expansion. I still played coy (I’ve been bred with the notion of never, ever mentioning my gaming life to any employer, ever). But, it’s still cool that the engineers were interested and shared something like that in common.

I drove home feeling happy, but I had the feeling it would be a no.

Why it’s going to be a no

Google’s a pretty particular company. For any candidate which passes through their doors, you can bet that they will find anything that they can say no to. They will contact previous colleagues of yours if they work at the company (I had one or two which I mentioned to the recruiter — actually, I’m told they set up my initial phone screen almost immediately after my Googler friend gave his recommendation).

After your day of interviews, your application is sent to a hiring committee. Google attempts to avoid any type of bias in their hiring process, as they are hiring for the company as a whole — not one single team.

This committee typically meets on Thursdays. I had interviewed on a Thursday, so I had to wait an entire week to get back the bad news.

In addition to finding anything they can to deny a candidate, Google cannot give terribly much feedback. In my case, the recruiter informed me that I actually did really well in the interviews. However, I just didn’t have the experience the hiring committee wanted. Reading between the lines, it came down to the fact that I’d mostly worked short-term contracts and hadn’t been at any one company for more than a year and a half at that point. I think that’s fair enough, even if I had good reasons for not having been anywhere for terribly long at that point.

While many people think the automatic no is a bad thing, the entire process can be incredibly expensive for Google if they do get a false positive. I do agree with their philosophy of preferring false negatives over false positives. It’s much more difficult (and expensive) to get rid of a bad engineer than it is to not hire a good engineer — especially with the many, many applications they receive all the time. I can see where it’s even more expensive if that particular engineer has a history frought with layoffs and contracts. This goes into the rabbit hole of how our generation finds it difficult for many reasons to be at any one gig for a long time, so that’s as far as I can really discuss that.

Overall, though, I think I will take the recruiter’s advice and reapply next year. The worst that can happen is another no, after all.

tl;dr — If you work at Google, could you please poke someone to revive the Google Voice team? The UX is awful and there are still people that use it.

Web and Data Developer. #Doberman lover. Confusing relationship with #C++, #JavaScript, #PHP, and #CSS.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade