[rdtsc]

I hate little programming puzzles that you have code by hand or little word problems, or trick questions that you have to think "out of the box".

In many years of programming I don't remember having to write a binary search in C, by hand, in a text document, without being able to compile and test. Or having to dictate a Python program over the phone to someone.

I certainly do not remember ever having to solve stuff like:"One train leaves Los Angeles at 15mph heading for New York. Another train leaves from New York at 20mph heading for Los Angeles on the same track. If a bird, flying at 25mph, leaves from Los Angeles at the same time as the train and flies back and forth between the two trains until they collide, how far will the bird have traveled?" NEVER.

I had to implement & modify algorithms from scientific papers, I had to work with complicated lockless versions of data structures, but I probably couldn't write the binary tree search in C over the phone. If that's that Google uses to hire then I will never work at Google.

EDIT: Alright, got a angry and used the 'fuck' a little too much.

[mdwrigh2]

So, to be fair to Google, I was not once asked anything like the train question nor was I asked to write a binary search in C then to read it out over the phone. I did implement a few things in Google docs, which is kind of ugly, but it wasn't anything ridiculous, and most of the functions were fairly short (20-30 lines).

They did, however, ask a whole bunch of conceptual questions, but I don't think this is all that surprising.

[Lewisham]

I'm an intern right now. Just today I saw Neil Fraser [1], who wrote MobWrite [2]. I shook his hand and thanked him, he's probably one of the reasons I actually managed to pass! My third phone interview had code in MobWrite, not Google Docs, and it was so much better.

I'm going to try to find a way to feed it back to HR, because it really is much easier to think about code when what you're doing looks like code.

[1] http://neil.fraser.name [2] http://www.mobwrite.net

[mdwrigh2]

That's awesome! I'll have to play with this, and suggest it whenever I hear the topic of coding interviews come up.

As a side note, if there's any chance of you being in the bay area this summer (Mtn. View specifically), I'd love to grab lunch with a fellow HNer. I'll be interning at Google starting early May and know a sum total of 0 people out in the area. If you're interested and possibly going to be around, my e-mail is on my profile page.

[mak120]

I interviewed with them recently (got through phone interviews and am waiting for a visa for my onsite interview), and I never got any trick/puzzle questions that need no programming to solve. I did get questions about simple CS concepts and had to write code for programming problems on a shared google doc. Nothing any ordinary CS graduate wouldn't know. I made mistakes, which my interviewers always guided me to correct. They don't expect you to write a flawless binary search - they know you'll make mistakes. What they want to see is how you think and how you code, and how you recover from mistakes. Also, that you know what binary search is in the first place.

That was my first interview, and they said at first it was going to be a coding interview. My next interview was a design interview. We talked at length about designing a simple web application, which got increasingly sophisticated as we progressed. But my interviewer did ask me to write code to demonstrate what I had in mind from time to time and I had to code up some small methods and classes to show him. No puzzles. No CS theory or abstract problems. Just what I would do if I were building a real world application.

Oh, and they asked about what projects I had worked on both interviews.

I have been an interviewer in the place where I work currently, and I always asked candidates to write code. Some guys here ask puzzles, but I don't like that. Puzzles (like how to find you who's lying in an island on people or something) don't really show anything in an interview situation. But a short programming problem, demonstrating the ability to identify and use a well known data structure or algorithm, or to use good sense and understanding to design a solution to a problem does go a long way to show that a candidate can actually code and get stuff done. I've seen lots of bad candidates impress us with their knowledge of tech buzzwords, past projects in their CV and even talking about design patterns, but fail miserably when asked specific questions or writing even the simplest amount of code.

But if someone asks me about trains and birds, I would seriously reconsider working there

[rdtsc]

> I have been an interviewer in the place where I work currently, and I always asked candidates to write code.

Agreed. It doesn't have to be perfect. They should be able to talk and explain it. Whiteboard design sessions are my favorite A good marker and a whiteboard are indispensable for me, and I use it in interviews as well. I present the situation as here is a typical problem we are solving, let's solve this together.

I also give plenty of chances to let the candidate tell me or teach me something they are excited about.