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.

This. A thousand times this. Each candidate is different. You should be asking questions to figure out what they know. Requiring specific experience is often a bad idea, because, for example, I can train you how to use our custom codebase, but I don't have time to train you on basic coding skills. You should be able to fully describe a project you built, from start to finish, discussing problems and obstacles and their solutions.

I also think it's perfectly okay to say "I don't know off the top of my head, but I can find out" when asked a question. Or alternately, "I don't know off the top of my head, but based on what I know about other things, I would start here..."

I like this a lot. You can ask a lot of follow-ups that tie more into the skill set while staying inline with something they're passionate about. Good stuff.

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.

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.

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 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?

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.

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.

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?

How is this not a "how many ping pong balls fit in the empire state building" sort of estimating question? Am I missing something about it?

This seems as if the answer is pretty related to how profiling works, i.e. you would use the restaurant's clients as a sample set and sample it at regular intervals and then use the average scaled to the city's population.

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.

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

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.