My route to the Engineering Resident position was a little unusual. I describe it in the first paragraph below. Please skip ahead to the second paragraph for actual interview information.

I was initially contacted by a recruiter about a full-time position at the beginning of September 2018. After an initial phone conversation with the recruiter and the completion of their coding challenge, they decided to move forward with my application, but only for the Site Reliability Engineering role. I then had a 45-minute coding interview over Google Docs by phone in mid-October. Because I was living abroad at the time, scheduling an onsite interview was difficult, and I ended up waiting until early November to interview onsite.

The onsite interviews consisted of:

• Three 30-minute whiteboard coding interviews.
• Lunch with a Site Reliability Engineer.
• One 30-minute behavioral interview (I was told this last interview was unique to the campus I was interviewing at).

I was told they would take 4-6 weeks to make a decision. They ended up getting back to me in mid-December, only to ask for two more 45-minute phone interviews. I completed these in early January 2019 (after the holidays) and was told about a week later that the hiring committee decided not to make an offer.

But then, about a week after that, I was contacted by another recruiter about the Engineering Residency program. Over email and when I was filling out the form she sent me, there was an implication that I would have to do yet another interview. Fortunately, she decided over the phone that because I had interviewed so many times already (SIX coding interviews!), she could just submit my feedback to the hiring committee a second time, along with my answers to the application questions. She submitted my information to the hiring committee on a Wednesday in late January, and she emailed me that Friday to let me know that the hiring committee decided to move forward with an offer this time around, and that my offer was just pending final executive approval. Finally, five months after my initial contact with Google recruiting, I received my official offer the following Wednesday.

My initial 45-minute phone interview on Google Docs went smoothly with no technical issues. The interviewer seemed pretty aloof the entire time, though I've read that this is common due to the fact that most interviewees don't make it through this round. The actual interview consisted of one simple warm-up question, followed by a much harder one.

For the onsite interviews, I was taken to a room with a whiteboard and laptop, where I remained for the first three coding interviews. I had the choice to use either the whiteboard or the laptop with syntax highlighting (I chose the whiteboard). All three of my interviewers were very friendly and engaged, and I could tell they really enjoyed taking time out of their day to interview candidates.

The first of the three interviews started with a warm-up question before an actually hard one, and the other two were just single hard questions. The fourth interview after lunch was basically just a traditional job interview. My two follow-up interviews were pretty much more of the same.

Most notably, I had some technical issues before the first interview, which ate up the 15-minute break I would have had before the second. Also, I had a disagreement with my first interviewer about my solution to the warm-up question. It was pretty silly, but perhaps unavoidable, as we seemed to have different understandings of a small behavioral detail of a utility I was using in my code.

Study up on your algorithms and data structures. Make sure you're comfortable with using common data structures and algorithms to solve more specific problems, but also be prepared to answer questions with no connection to any previously learned tricks.

You should be able to come up with time complexities as easily as breathing. For everything you write, you have to be able to explain your thinking. In some cases, you will be asked to verbally articulate a complete solution before writing any code at all.

In general, what they seem to be looking for is observable proof of your problem-solving ability in real time. You don't need a freakishly high IQ or a vast knowledge base of CS information to succeed, though I imagine that would help.

To prepare, sites like LeetCode seem to work fine, but in my opinion, they put way too much emphasis on test cases and actually running code to be used for interview preparation. I often found that I would work a problem until I'd thought of the solution, then abandon it after a few minutes of trying to debug some edge case that wasn't working. This kind of behavior is obviously inappropriate on the job, but it helped me focus on the conceptual problem-solving skills needed for the interviews.