Developers: What do you consider a 'good' interview question?

I had a great question once that didn't show my skills explicitly, but showed my reasoning skills.

Say you are at a restaurant in the city, and your friend asks how many people are on Facebook at any given moment in the city. How would you answer this without writing any code, on the spot at the restaurant?

If you're applying for an IT job, I ask if you have any personal projects in scope of the work you're looking to do that you're proud of and ask you to describe them. This is where I can typically assess someone's passion for their skills, or if they're just looking to show up and collect a check.

Not solvable with 2 seconds of Googling, not trivia, not academic, not deceptive or intentionally tricky. The best source is problems you actually have. Go over problems you currently face and talk about solving them just as you might with someone on your team.

I am not an experienced interviewer, but since I'm in a position to interview someone whom I'll work with closely I've been facing this challenge.

We're looking for a more junior level developer. We want to gauge their skills, but don't want to make any questions that are too domain-specific. I like the problems from places like Project Euler or codewars.com, but some coworkers feel they are too difficult. Solving a variation of FizzBuzz, allowing any reasonable language, even pseudo-code, shouldn't be beyond my expectations, right?

I get the best results from just asking them to describe something they've worked on that they're particularly proud of, or was particularly difficult. And keep prodding for more details to get a real feel for how the person works. Basically, pretend you have just taken over a project and are trying to get more information on it from one of the developers on your team. You'll find out a lot about the person in a conversation like this, far more than from purely theoretical or "the answer is B" questions.

I think the best questions are technical questions that give the employer insight into the scope of my skill set. For instance, my previous employer asked what "idempotent" meant. Prima facie, this might seem pedantic. But, if you think about it, "idempotent" is quite frequently used by people who work in REST APIs, which infers that I probably have been reading about REST APIs or HTTP concepts in general or at least people's blogs about REST APIs, etc.

Next, he asked me what the first argument to a Django view was. This was a pretty basic question, but if I hadn't known the answer, it would be instantly clear that I didn't have actual experience in Django, and if I did have experience in Django, the question wouldn't seem like trickery.

I like this sort of questioning, because it reminds me of the year I decided to homeschool (in high school). The tests were on the honor system of course (you could easily cheat without a teach sitting right there), so the tests' questions would be about intricate details in a large (30+ pages) text, that you couldn't possibly know without reading every last line. You could try to find the piece of text for each question, but it was quicker to just read the whole text. Guess what. I read 100% of every text book I had (I would have cheated otherwise, and then missed things like The Walden, etc. :)

Google's interview antics are one of the many reasons I'll never work for them. For one, I write business software, and am not great a some of their math-related questions (met some of their recruiters at PyCon 2011 in ATL, and they had a quiz question for the convention). Secondly, their puzzles are very "skull and bones"-esque, in a pretentious way.

TL;DR

IMHO, Google's hiring antics are the reason their software is all so terrible, despite having pockets deeper than the abyss. The only reason they're on top of the world is because they're a marketing company. Their software is undeniably bad.

This is more of an exercise than a question but...

When we interview some database people, we would ask them to whiteboard a database for a fake golf tournament we were having. What this did was force the interviewee to ask questions if they don't know golf (such as how many rounds are played, how many players, how does scoring work...etc) which tells us two things: Can they get info from a customer (internal or external) and how do they do hierarchies in data models.

Lots of responses from interviewers, but I'd love to hear from interviewees.

Former Google eng interviewer here. We never asked the stupid brain teaser questions.

I usually asked one open question, like "describe a really hard bug you found", and one technical question. The technical questions ranged by candidate, and the sorts of questions others had already asked (most candidates get ~5 interviewers).

The technical questions usually fell into 2 categories:

Algorithms/etc: These should be solvable by the average engineer, but hard to solve optimally. Questions with both brute force and dynamic programming solutions were my favorites. I had a couple of questions where there were O(N^3), O(N^2), O(N*log(N)), and O(N) answers.

System design questions: How would you build ... Google News (I was the TL at one time)? Or I would give them a specific problem, often involving distributed computing. Often candidates would have to come up with alternate solutions when things like speed of light get in the way of the problem requirements. Being able to negotiate problem definition is a great skill in an engineer. Some candidates really just tried to pound the square peg into the round hole for an hour.

Basic engineering questions that filters the 8 week bootcamp people are usually what I'd consider a good minimum for your normal wide responsibility engineering positions.

I liked one question I had a few months ago. Not verbatim: What do your computer processor and a turing machine have in common?

I think it's highly dependent on the position though. Another one I had was the all permutations of a string using dynamic programming.

Your list of basics that shows something beyond reciting how to do something in a framework will filter out most of your candidates who need a bit more polish.

I have seen a few google questions, and feel they are good quality, and nothing like the quoted question. I suspect google learned from the points rasied in thr book "how would you move mount fuji" (a now famous microsoft question). The book is well researched and has some well thoughtout advice at the back. The quoted question looks like an old microsoft question, but, I might be wrong.

Instead of asking tricky "clever" questions, I prefer to ask questions which prove basic knowledge of the language. I just want to know if the guy knows what he's doing.

Beyond that, I suggest asking to see screenshots and Github source code of previous projects.