One of the best metrics I've found for determining the overall satisfaction level of a department is turnover rate.

If you ask the interviewer about their turnover rate and they hedge, be cautious. Sometimes they won't know what the turnover rate is because they're too new, or don't pay attention to it, so you can ask about the average number of years that the developers have been there (which they should know).

There are so many factors that figure in to developer happiness that it's hard to build a good checklist of things to ask about. But if you look at the evidence (how long do developers stay here?), it's very easy to tell if it's going to be a good place to work.

Of course, this doesn't work when you're talking about getting a job at a startup, but the hope there would be that you already know it's somewhere you want to work; that it's not a job that someone referred you to just because you need a job.

This is absolutely wonderful timing for this thread to come up. I've recently started at a start-up in Beijing and have been put in charge of making a filtering system for technical applicants.

One thing I was never prepared for was the sheer number of people who just lie on their CVs! After somewhat reluctantly starting to ask senior app developer and web developer applicants to write a fizzbuzz program, I was shocked to see that less than half could. This is from a group of people who claimed to be experts.

Since that discovery a couple of weeks ago, I've been building an automated grading system similar to the great FB's old puzzlemaster app. That way I can screen out those who can't do fizzbuzz and another trivial program or two before wasting our one iPhone dev's time interviewing them.

Those who do at least decently do get a chance to interview, but I'm hoping to add more puzzles to the auto-grader in the hopes of spotting applicants with stronger skills than is clear from their interviews. Any suggestions?

It also doesn't hurt to simply practice programming problems and revisit old academic excercises.

Make some flash cards with datastructures on them and use them to try and recall as many of their useful properties as you can (eg: Binary Heap, binary tree with x constraints, O(n) search, O(log n) insert in worst case; etc).

The advice in the article about honestly answering, "I don't know," is key -- don't pretend to know. You'll get called out and blow the interview. Instead, explain what you do know and think out loud when you walk through the problem with them (or how you'd go about solving it).

One way I've practiced "thinking out loud" is to get a white board and pretend you're a professor. Try to explain the solution to some problem you are familiar with in layman's terms to your pretend audience -- but do it out loud. Then find a problem online that you're not familiar with and do the same thing. Pretend you're a professor or engineer or some sort of brilliant person and walk through the problem with yourself -- out loud. Write diagrams on the board, explain your every step to your pretend audience, and really get into it. I found it helped me quite a bit and I frequently use the technique to walk through problems I'm not familiar with in my own studies.

Also, be aware that it is OK to bomb an interview. The point of interviewing is to find a match. If you and the company do not have a cultural fit, it is better to find out and both go your own ways. So I recommend above all to simply be yourself.

I don't know man, the interviewing process is just so broken. Maybe because interviewing in general is so broken or maybe it's because software development is such a new industry.

Either way, isn't it strange that the best advice for doing well at interviewing is to practice. Practice so you become better at interviewing, not necessarily better at your job.

> Also, when they do ask you about how much money you want, give them a range or a baseline (ex: I had X at my previous job, so I expect at least X or from my research people doing this job receive between Y and Z, so I’d expect something in that range). Let them come up with a number.

I don't understand this advice, if I say I expect 'at least X', then it's me coming up with the number, not them. I have always just said I'll comment on what is offered.

Interviewers who explicitly phrase the 'how would you move Mt. Fuji' or 'here's a development task outside of your stated competencies, how would you do it?' as hypotheticals or thought exercises, could save a lot of heartbreak. I can see the rationale behind those questions, but any experienced interviewer should know how tense people get during an interview: allowing interviewees to perceive those questions as being about the literal answer, rather than about the process, is kind of a jerkface thing to do. Besides, people who can't coherently explain their thought processes are going to bomb on that question anyhow - have some courtesy and give a leg up to people who are merely nervous. I'm grateful to the interviewers I've had in the past who have come out and said "this question is about the process, not about the result".

I think it's very important to reduce the tension level, because if you're asking someone a question intended to show how they think and reason, especially with some level of creativity, you risk getting a useless answer if they're tense and antsy. Nervousness and pressure often kill creative thinking: this is well-established.

Or interview at companies that aren't software giants that will actually spend time getting to know you and your past work rather than processing thousands of developers each year through standardized programming tests that do not prove anything about your capabilities as a software engineer.

I'm going to an interview this week. One thing I think that's missing in topics like this is that you are going to work for a company. This means that you need to look beyond the immediate position and take a large view to the business. I'm going to ask questions like "Why did your last custom stop using your product", "What is the company's vision for the next 3-5 years", "What are your revenue streams and how stable are they".

Knowing what dev process they use, tools, etc are all really good questions. But don't forget that the money they pay your salary with comes from somewhere. Knowing this internal information is just as important as knowing how Git works.

The bottom line, in the interview process you need to adapt to the people you are talking to.

The possible pitfalls are endless for both the interviewer and the interviewee.

And sometimes the interviewer will bomb the interview more than you. You don't see people often write about making sure the person doing the interview is any good at it.

Getting good people is really important. Possibly one of the most important things you can do for a business.

I've never come across an interviewer who is formally trained to do the interview.

With some of those "un-answerable" questions that come up in interviews I've had good mileage from just turning them around back on the interviewer. After all, a lot of the time these interviewers just ask the question because it's part of the "process" or something without fully understanding the question themselves. However, you have to read the situation well in order to get away with this!

People are on their best behavior with they are being interviewed. My manager suggested that if you notice any rude or peculiar behavior during the interview, multiply it 100x and consider whether you would want to work with that person one year from now. I've interviewed people who would arrogant or would talk over the interviewer. Needless to say, those hires did not work out. <:)

Is it worth asking about the programming environment if you're already in the office and can see evidence of it all around you?

This advice seems like it would be applicable for an interview for any type of job.