Interviewing at Google

Yesterday I had two technical interviews for a software engineering internship position at Google. This article is an attempt to motivate people to apply and tell them what to expect. So, here we go.

The first Google engineer called me around 14:30. The connection was not optimal from the interviewers side so instead of a phone interview we had a Google Hangout interview. We shared a Google word document where I should write all my code (yes, a plain and simple Google doc).

The interviewer was nice to talk to, his first question was : “What made you apply at Google ?”. Well, everybody knows that I am an Android geek/enthusiast/dreamer. So that was my answer. Also, interning at Google will give you experience in the field which you can impossible learn in school. Things like for example : scaling of systems, coping with huge datasets, an extremely large codebase, etc. After that we proceeded towards the first question, which was something like this :

Question 1 : Assume you have a sentence represented by a string-object. Write a function (in Java) that will swap all vowels with a vowel at the end of the sentence. So for example : “United States => “Enated Stitus”.

Basically the approach here, is to work with an array of characters and work your way down the sentence using 2 pointers. One pointer points to a vowel on the left half of the string, the other to the right half of the string. If the right pointer is smaller than the left pointer, work is done and you can return the string.

I did OK on this question, had a little bug with my pointers that were incremented in the wrong place. But the interviewer pointed me to it, and I resolved it rather quickly.

Question 2 : Write a class called CollectionsIterator that is capable of iterating over a set of iterators. Make sure this class can hold Iterators of any type.

The interviewer thought this was the difficult question but I found it rather easier than the string traversal. Approach is again, rather easy. Create a class that implements the Iterator<E> interface. Use a field for a current_iterator and a field for the main_iterator. The main_iterator will loop over all the iterators and the current_iterator is the one that is providing the elements of a certain collection in the set of collections. Sounds easy, but tricky when implementing the hasNext() method. In the end, my first solution was perfect and that concluded the end of the first interview.

After a 15 minutes break I got the second interview. This one was by phone and again on a shared Google doc. This interview was not as good as the first one. The question was also more difficult than the first one.

Question 3 : Write a function that has as input a list of strings and will print to stdout strings that are rotational equivalent line per line. So all strings on one line are rotational equivalent.

I struggled the most with this question, due to the fact the interviewer started with the question : “Do you have any experience with rotation ciphers ?”. Sure I do know what they were, but never really implemented one so I didn’t know all the details about them. This threw me off a bit, but in the end you didn’t need to know exactly how they work. Just the notion how a string can be rotated over the alphabet.

So the approach I took for this question was looping over the strings and computing their fingerprint. Basically the fingerprint(String s) function should be a function that returns the same string for every rotational equivalent string. This can be achieved by using the convention that the first character of every string should be ‘a’. So we calculate the distance from the current first char to ‘a’. (only taking into account the chars a->z) and we rotate the whole string over this distance. We then use a HashMap to store a mapping “fingerprint -> set<rotational equivalent strings>”. In the end we write a prettyPrint() method which will iterate over the set and print out one set of rotational equivalent strings per line.

I needed some help, the interviewer for example pointed out to use a fingerprint method. After this I came up with the whole solution. A last question was what I thought was good/bad about my approach. At this point I perfected my code and told why I used some data-structures (like hashmaps and sets).

In the end it was a pleasant experience, much better than interviewing at Facebook. I have a good feeling, but if I don’t make it now , I can’t really be sad as I couldn’t do much more. At least I’m chasing dreams, as everybody should do !

Cheers,

H4

About these ads

4 comments

  1. FYI, Google interviewers would really prefer that you not publish the questions they ask. It won’t affect your chances of getting an internship, but it’s not very nice because it means the question has to be retired. Coming up with good questions that strike the right balance of simplicity of explanation, difficulty of solution, feasibility within the context of a short interview, and open-endedness, is hard.

    Further, “calibrating” the questions, meaning building a sense of exactly how well good candidates answer them, is very time-consuming. Google interviewers normally try their questions out on several Google engineers before using them with a candidate, and then have to try them on several candidates before gaining a lot of confidence in how to evaluate responses.

    Believe it or not, it also does a disservice to other people who may interview at Google. You might think having seen a question before will help the candidate, but it doesn’t. It’s very easy to tell if someone has already seen a question before, but it takes getting into the solution a bit, so by the time the interviewer realizes that this question isn’t going to provide any useful information about the candidate, several minutes have been wasted. Actually, as a candidate, the very best thing you can do if posed a problem you’ve already seen is to tell the interviewer you’ve seen it. You’ll get points for integrity and won’t waste time.

    So, I highly recommend that you not do this, as a favor both to hardworking interviewers and to people who might be interviewed. It’s not very Googley :-)

    (FYI, I’m a Google engineer. I work on Android OS security. And one of the questions you just posted was one of my favorites to give in interviews! But now I can’t use it any more…)

    Oh, and best of luck on your internship! I have hosted interns in the past, and worked with a lot of others, and without exception it’s been a great opportunity for both the intern and Google. I’m sure the same will be true with you.

    1. I did not think about it that way. I prepared by solving problems coming from Glassdoor, where a massive amount of interview questions are posted so I did not saw the ‘wrong’ in doing this on my own blog. However it was only to share my experience, which was quite pleasant, so kuddos for that :-)

      Secondly, why is no feedback given instead of just a standard reply mail that I do not possess the technical skills to fill the position ? I don’t even know where I went wrong. I can imagine you guys keep an internal document with the reason I failed. Would be nice to know where to work on.

      Lastly, very interesting to know you work on Android OS Security. I did my own master thesis proposal which will be research on android os security, which got accepted. So I’ll be starting that next masters year.

      Cheers,

      H4

  2. I don’t know anything about your specific situation, of course, but in general it’s not really possible to give good feedback to candidates. What it ultimately boils down to is that you didn’t impress the interviewers. That may be because you don’t have the skills, or because you just didn’t present your ability in a way that impressed. Don’t feel bad about that, though, the interview process is designed to be hard, and to err on the side of rejecting good candidates over accepting weak ones. It’s generally accepted that if you were take a successful Google engineer and run them through the interview process as though they were a candidate, they often wouldn’t get “hired”. This sucks, and everyone knows it, but rejecting good candidates does less damage in the long run than accepting weak ones.

    I encourage you to try again.

    BTW, what aspect of Android security are you researching?

    1. Hm yeah. I kind of get the strategy behind the hiring process. But oh well maybe I’ll try next year. We’ll see, my internship now is quite interesting (also android security related :-) :-) )

      I will focus my thesis on the security of web-based Android applications. As I am just starting on my thesis the scope is still rather large. Initial research questions will focus on the security model that is in place now. As we see a rapid grow in applications based on the WebView class or ported web applications by frameworks like Apache Cordova there are some questions that we can pose. I will try to research how the security model for native apps differs or is compatible with the security countermeasures that are in place for web applications. With SOP being a focus point as starter. I hope to come up with improvements or even a next-generation security model in the long run. I got some ideas on the JS Api access for example :-)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s