I've encountered a few questions that I find problematic. Here is a selection, along with some suggestions for improvement.
"Tell me what you do."
This is just plain lazy and thus rude; it means someone hasn't bothered to read my CV.
Before an interview, I always try to read up on my interviewers, and certainly on the company's products (often to the level of doing a mini product review including notes on performance/design issues). I expect the same in return.
Summarizing my CV for someone is a complete waste of time that could be better spent talking about more interesting details, technical problems, etc. I find it's most productive to dive directly into the most crunchy parts of a conversation.
Occasionally this gets to the level of outright incompetence, like where an interviewer is unable to substantiate claims they make in their advertising, explain in relevant detail what they are looking to do in the near future, etc, beyond the superficial level of someone who doesn't know anything about what they're talking about beyond rereading the copy. Fortunately, this level of incompetence is rare.
Solutions:
1. Always have the first interview be by someone technical. They're the only ones competent to screen for skill, and the only ones able to give the kind of details that someone skillful will want to know.
2. Read the candidate's CV / resume / website first, at least enough to be able to quickly get to non-rote discussion of interesting issues underlying what they've done before or expressed interest in.
For instance, I love talking about the issues involved in correctly asking and answering questions like "how does this feature affect user satisfaction", "given [specific technical problem], what are the possible solutions and are their tradeoffs", etc.
These are topics where you can quickly get to novel territory - beyond the parts that are rehearsed. And therefore they are also better for mutual skill and style assessment.
"What would be your ideal job?"
Ideally, I would have enough money to never have to think about money again, and therefore to be able to hire people to work for me. I have enough ideas and interests that I'll never be able to do them all myself anyway.
Practically though, that's not (yet) the case, and it never will be from working for someone else. Like almost everyone, I trade in some of my freedom to work on whatever I want for a dependable salary - and for the benefits of working with others. (I continue to work on my startups on the side and between jobs; effectively I'm trading time for equity compared to a VC deal.) So I think my ideal is simply not pragmatically relevant.
Like most hackers, my optimal productivity and optimal satisfaction metrics are actually very similar: I'm happy when I'm productive, self-directed [0], and learning; when I have people of similar or higher skill to work with; when what I'm doing makes a real improvement to the world; etc.
In many situations, however, asking anything like this is really fairly moot. Some jobs are simply a company filing a fixed need, with relatively little ability to tailor it to my interests. In those cases, the real question is "Can you do this job and be satisfied?". That's a worthwhile and direct question.
Another situation - one that I'm fortunate, because of my relative breadth of high level skills, to sometimes have - is where a job does have leeway to tailor a position to my interests, or to tailor my hiring to available positions. But I'm not psychic; though I know the metric, I don't know what the available solution space is.
Solution:
In situation where flexibility is available, a better question would be "We have the following points of flexibility [list situation from employer's perspective]. How can we have you work for us that would be optimally productive?"
When an employer has this flexibility, and can tell me the details, there's definitely a mutually beneficial optimization to be had here.
Without that information, though, this question devolves to being merely about my flexibility - and given the extreme range of my skills and interests, that's not very useful.
"What are your salary expectations?"
This is really part of a negotiation. Like in any negotiation, you always want the other person to name a number first. If it's in your favor from your erstwhile opening, you win; if not, you can bargain.
However, I think that as part of a job interview, it's somewhat deceptive. The defining factor is not my desires but a combination of the state of the market and the actual value I bring to a company. The employer (or recruiter) has far more information about these things than a prospective employee.
I have a fair notion of what people with my skills make [1]. I think it's a reasonable salary that meets my needs. Why dance around it, as if going rates are a secret?
Not to mention that there are lots of factors - even when talking cynically about raw compensation - other than money: benefits, stock, random perks, performance-contingent bonuses, etc.
Solution:
As I said above, I think that all of those things are really a matter of taking the issue of compensation off the table by offering what is mutually agreed to be a fair package based on known market rates. You can just say early on what your range is, agree that you're in the same ballpark (i.e. ±~15%) of what would be mutually satisfying, and move on to more important things.
Things other than raw compensation that I (and any other hackers worth hiring) care about are:
Is my work environment cognitively ergonomic?
E.g. will I have a decently powerful computer, 2 full-size monitors, a decent chair, a keyboard an mouse of my choice, an OS configuration of my choice, food/drink within easy reach, etc? These, like compensation, are almost always a case of removing obstacles (even small ones) rather than adding luxuries.
Are there opportunities for play?
E.g. Rock Band is good for reinforcing group cohesion, and play is a fundamental part of all creative professions. Don't worry, professionals care deeply about being productive.
Who do I get to work with? What are their skills?
I want to know what kinds of sounding-boards I'll have, what things I can delegate to others, what things I can take off others' workloads, etc. And I want to know what skills I'm going to learn on the job.
What kinds of problems are available for me to work on?
I want to be challenged, because if I'm not, it means that my skills are stagnating. That's kinda the point of hiring a hacker - you're getting someone who really deeply cares about having a very high level of skill. This is necessarily a moving target.
Fortunately, I am broad enough in interests that there are tons of things that can attract me. You just can't easily predict what, and you can't depend on it being the same thing for a long time.
"How would you rate your [technical domain] skills, 1-10?"
This question is a measure of confidence (hilarious study pdf), not of skill (which is what it's intended for). It only ever seems to be used by people who either don't have the time and/or skill to actually assess my skill.
It might be interesting, however, to use this question together with an actual skill assessment, as a way of measuring someone's metacognitive accuracy. But I suspect even thus it would be useless, as practically everybody will say they are above average, which reduces the information back down to a skill assessment; the measure is simply not sufficiently sensitive.
There are surely some situations where mere confidence, independent of skill, is useful. Sales, for instance, has a dramatically evident self-fulfillment rule here.
But I think that technical work is not one of them. One needs to have an accurate metacognition, so that one can know when and where to look for help. (I certainly look up things I don't know quite routinely.
Memorized knowledge of syntax is like memorized knowledge of mathematical formulas. It may help one to bullshit through a stupidly written exam, but it does not particularly help with real world problems, other than a very minor speed gain - one that comes quickly with familiarity. What is more relevant, IME, is the ability to explore solution space well, understand the tradeoffs of various techniques, and - critically - to know when your first notion is probably a Bad Idea™ and you really ought to look up how to do it better.
Solution:
Have a person of at least moderate technical ability to the first pass skill screenings. Ask about routine problems that you actually have that are relevant to the job. (E.g.: "The sql server crashed. What do you do?" [provide responses to ongoing hypothetical investigation]) Ask about routine coding issues (e.g. "How do you prevent SQL injection from user-entered text in Rails?").
Once you've screened out the incompetent applicants, have the second pass interview be by the most technically capable person you have, and have it immediately go into as much depth as possible on hard and poorly defined problems.
Never have non-technical people attempt to assess someone's technical competence. They can't, and they're hugely vulnerable to skills you want to actively reject, like BSing.
"How would previous coworkers describe you?"
This is only marginally better than the more transparent version, "What is your biggest flaw?" et al.
If people could be honest here, this might be useful. Unfortunately, in a job interview, one can't really say what one's flaws are - if indeed one even is aware of them.
So, pragmatically speaking, this question is a test of bullshitting skill: whether you can come up with something that sounds vaguely flaw-like but is actually a disguised compliment. (e.g. "I work too hard.")
Again, I don't think that bullshitting skill has any place in technical work - though it may in sales and marketing. Even no data is better than data that's too prone to be BS.
I think that hypothetically it's possible that an interviewer could actually prefer honest self-assessment to nicer-looking BS. But that would have to be demonstrated very strongly.
Solution:
Call someone's references. Ask them for other references.
Ask about what someone would or did do in specific situations. Try to find out what they really care about, and get them on a good rant about that.
And... don't treat jobs as permanent placements like a marriage. At some point you just have to guess that personality will be a good enough match, try someone out, and find out from actually working together what the fit is like. The first few months are basically like dating anyway.
Anything short of direct experience working with someone is fundamentally unlikely to answer this question well.
[0] "Self-directed" does not mean "working alone". It means having substantive control over decisions that matter to my work, which is really just the ability to exercise my skills.
I'm perfectly fine deferring to someone else, so long as their decision is reasonably justified (e.g. in the many cases where there's no clear One True Answer™). And I far prefer to work together with others of equal or greater skill, both because it tends to sharpen my own skills and because I think that having discussions amongst peers is critical to figuring out what the best solutions are.
I think many non-technical people underestimate the degree to which programming, for skilled people at least, is more an intellectual exercise in exploring solution space than a clerical exercise in writing it down so the computers can obey us.
I, at least, would be very bored by a job being merely a fancy scribe. The challenge of solving problems, and indeed of defining the problems in the first place, is much more interesting.
[1] Granted, programmers do make a fairly wide distribution of income, in the US.
Raw entry level: ~$35-55k
Moderate skill: ~$70-90k
High skill / middle management: ~$100-125k
Management: ~$120-170k
Entrepreneur: ~$0-$5M (startups are a "become rich or broke" gamble)
