Hacker News Reader

Comment by employee8000 | Hacker News Reader

At google, I was given some code that manipulated some bits and the interviewer, in inexplicably terrible English, kept asking me what the purpose of this code was for. He has a very thick Eastern European accent which was not understandable and I don't know how he was able to get into interviews. I could tell it was doing some sort of overflow detection but other than that I had no idea. I hadn't done anything with bits since college. He kept insisting that I keep trying to understand what the code was doing even though it was obvious I had no idea. After a 40 min, excruciatingly awkward conversation we moved onto his next question which I also couldn't understand due to his terrible English. What a complete waste of time.

View on HN

Thick accidents and borderline language proficiency is even worse on phone screens, where interviewers always seem to sound like they are talking through a sheet of plastic placed over the phone. I've lost count of the number of times I've had to get someone to repeat their question over and over and over on (not Google) phone screens. Once did a phone screen with an exec who I'm pretty certain was conducting it from his handsfree in an open-top convertible car (clearly heard traffic noise). I've always wondered how many opportunities I've missed out on due to poor audio quality.

I have a very hard time with accents. I've done a couple of phone interviews where I hardly understood a single thing the candidate said. In those cases I usually write my question verbatim in the shared document and focus on the code the candidate produces. It has probably hurt the chances of at least one or two interviewees.

> I hadn't done anything with bits since college.

No offense, but then the job probably was not right for you (which does not mean that you would not excel at other roles, of course). It then seems that the interview might have served is purpose just fine and saved both you and Google from being cast into an unfitting position.

I really wouldn't make that conclusion until you knew what job he was interviewing for. Firmware development? Sure, you might be right. iOS developer? Unlikely that low level bit manipulation is going to be a good indicator of his ability to succeed in that role. That's not to say its irrelevant, but, just not a quality indicator for that role in my opinion.

Maybe Google hires firmware developers, but I think they don't hire iOS developers. They hire "software engineers", and throw problems at them. (Or rather, these generic software engineers migrate toward problems that interest them in the long run.)

It prevents Google from having, say, more "iOS developers" than they need when they decide to concentrate on other products. We may debate the merit of this strategy, but as long as Google keeps this strategy, it makes sense to hire engineers who are willing to say "Well I haven't touched bits for a decade but let's see what we can do with them."

There is always going to a problem that you haven't done before or haven't done for a long time.

If I was the interviewer and someone was honest about not knowing about biwise operatoons but was able to ask the right questions to gain some understanding I'd be impressed.

This isn't really disagreeing with you, but I was contacted by them specifically for my iOS development experience. They have several iOS apps, and they do have a demand for that type of work.

However, everything I was tested on was general SWE data and algorithmic questions. I never once got asked about anything iOS related at all. I remember one was a Google Voice question specifically, and another was a really strange converting 3D to 2D graphics conversion algorithm question that I'm still not quite sure how to tackle, and another was like reversing the bits in an image, I think, and I don't really remember the others anymore.

Also, if you go in for iOS, do not whiteboard in Objective-C or you will have a really bad time. I kept running out of space on the whiteboard because of its ridiculously long method names.

Simple example:

Objective-C: NSString *items = [[[NSArray alloc] initWithObjects:@"1",@"2",nil] componentsJoinedByString:@","];

Python: items = ",".join(["1","2"])

98 symbols vs 27 symbols. Over 3x as long.

I've never chosen to interview with Google but I have been approached by Google recruiters on multiple occasions for iOS development. To say that they don't have a need for iOS engineers, is clearly erroneous. Google has a number of iOS apps.

Just to name a few: YouTube. Gmail. Hangouts. Calendar.

Regarding your interview experience - This is precisely why I turn down every interview request from Google. If you're contacting me about iOS dev experience, question me about that domain. I find the algorithm / data structures questions to be fitting for an entry level hire, fresh out of college.

I'm sorry that this happened to you.

But don't you think you could have prepared better? Understanding code others have written is important and in my opinion asking about bits is not unreasonable.

The interviewer really should have wrapped up the question in less than 40 mins if it was obvious the candidate was not doing well.

Reply on news.ycombinator.com