My interviewing style has changed over the years, and of course it depends on the type of Engineer you're looking for, but in general, what do you ask an Engineer during an interview? What should you get out of it by the end?

I did about 200 interviews at Google for the FE Engineer role and was on a hiring committee for a while. Recently I've been on the other side of the interview process.

In general I like open ended coding-design questions, where I examine the process in which people work through a problem. I especially hate "trick" or "a-ha" questions for anything other than warm-up; simple if you've seen it before, but often inconclusive otherwise (e.g. implement divide without / or % operators).

Most importantly, the thing you should come away with is whether you would like this person on your team. This is obvious for small companies but needs to hold true at large companies where it's easy to say "not for my team, but maybe someone else's".

+1 to Dan's last comment.
Also, I like to ask something involving async operations and how to present or not present such things to a user.

I always fully explore two aspects of the interviewee. Fit (culture) and Finish (skills which pay the bills)

Fit: What makes them excited and gets them out of bed? What do they bring to the workplace for everyone else? Why do they want to work with me/company? General open-ended questions about engineering culture etc.

Finish: Dev questions. Code challenges. Whiteboard challenges, etc. Cover OO, debugging, optimization.

I spent a lot of time interviewing candidates for a variety of both engineering and non-engineering positions at Twitter. My answer to this will focus more on engineering interviews. I started out by looking carefully at resumes and tailoring my questions to a candidate's self-identified skillset. With FE roles in particular, I found that these questions were heavily dependent on "tricks" or domain-specific knowledge that while vaguely familiar, have since been forgotten by the candidate.

The approach that I settled on were questions focused on general programming and problem-solving skill. Problems solvable without deep knowledge of algorithms and/or data structures, but with practical application of such if that knowledge is present. These problems generally have multiple solutions of varying efficiency. From the standpoint of an interviewee, the pressure is to at least _solve_ the problem. With a staged approach, this is possible. The brute force solution comes quickly.

The candidate then has a chance to demonstrate their ability to step back and rework/refine/rewrite their solution. This is often how it works on the job. As software engineers, most of us rarely implement the best solution first. In general, the problems I like to choose have optimal solutions that look very unlike their brute-force counterparts. I think engineers should be willing and able to write and rewrite code twice or thrice.

Some candidates hit on the optimal solution immediately, in which case, there is always another problem or two awaiting them.

@all - are there any particular questions that you look for to be asked by the candidate in return, for example, at the end of an interview?

I follow a similar approach to Russ. Ask something that is solvable even if algorithms or domain knowledge are weak, but that exposes these facets if present.

For example, a tree walking question could be asked in the context of the DOM, which would give you some indication of how much web hacking the candidate has done, but the question still has depth even if you need to provide the API.

I do find though, that even if they don't hit the optimal solution that isn't necessarily a red card. Often the process, attitude, and potential are more important than the actual result.

@Dustin as a candidate, I have long wanted to ask my interviewer a white-board coding question. Interviewers often forget what it's like to be on the other side, so I see it as giving a little payback. I was always hoping (or not) someone had the guts to do that to me at Twitter.

@Dan agree with you that arriving at the optimal solution is unnecessary. I actually prefer to see candidates go through a refinement process - it's much closer to what we do on the job. It also lets me have an ongoing dialogue with them, instead of sitting there and watching them machine-gun through their old TopCoder challenges. Another nice part about this approach is that it scales well to candidates with varying levels of experience, new grad up to senior-level engineers.

@ded

Since I rarely have all day to spend with the candidate (how cool would that be), I like high-quality questions.

Like to field questions about... the codebase, the FE team on and off the job, do we have XYZ skillset on the team,

Dislikes: questions that the recruiter could answer (who they report to, what does the company do, etc).

I will occasionally field a question about where the coffee comes from which I find very amusing. Philz and Peet's.

I found some very good delivery engineers by showing code that can be optimised and has some very obvious flaws and ask them to debug. This also gave some good indicators as to how the person approaches issues and works with other people's code.

An incredibly good question I got was "when would you not fix a bug" which gives insight into how far an engineer things about the projects as a whole or potential in others to learn from fixing it in your stead.

For engineering specifically, here's what I look for in a good question.
1. Trivia-free, language independent question.
2. Simple to state and easy to understand (I once had a disaster where it became clear the candidate didn't understand the question at the end of the interview).
3. Easy warm up component, hard (but not impossible) main component, and very difficult extra optimizations. This allows for a really nice range of performance, not just binary.

4. I don't waste time with culture/fit questions, that you basically get for free.
5. When I do have extra time due to a faster performer, I either ask a product question, or a I ask an experimental interview question, so that I can calibrate it.

As for being asked a question, I don't particularly look for anything. Especially during a long series of interviews, candidates have already had plenty of chances. A question on strategy or a clever product idea can stand out, though.

Regarding Ben's (1), it can be useful to ask questions where the candidate is able to demonstrate language trivia knowledge, but it shouldn't be required for them to complete the question.

This is purely to get additional data-points, since such knowledge can give you a good understanding of experience and attitude to learning the environments they have been working in.

If you claim on your résumé to be an expert Java developer with years of experience you should probably know about generics and common collections.

If you rate your JS at a 5/5 then you should probably have some knowledge of OOP practices, whether that be prototypical inheritance or some library.