Here's why :

>In my specific case, when interviewing in the past, things I've cared strongly about are things like test-driven development, a culture that values code quality as well as shipping products, and having a meaningful stake in the success of the company.

Platitudes like "a culture that values code quality as well as shipping products" and "meaningful stake" are useless, unless you're expecting the interviewer to say that his company values low quality code and not shipping products and that you're going to be a low paid code grunt down in the salt mines. As for testing, even if they don't use it nothing prevents them from lying - and if you think lying about it is stupid - not using testing is also stupid - so it's likely a pattern in decision making. It works the other way as well, it's really easy to fake what the interviewer wants to hear with this sort of generic questions that don't touch on the things that actually matter to the job (and I would say that the only reason to resort to these kind of questions is because you can't ask insightful technical questions, ie. talking about a previous project and the persons involvement/duties will allow you to collect actual information about the person, but you need to be able to understand what he was doing to evaluate it).

Questions and evaluations like these are things that HR people sell to management to make themselves appear useful without actually having skill to meaningfully evaluate the candidate, "corporate culture", "team player", "company values", etc. are all vague buzzwords with no quantifiable metrics behind them, but they are simple to pound on with simplistic intuition and anecdotal evidence. Even if the supposed attributes were somehow meaningful from my experience companies that focus on that sort of talk when interviewing end up with exactly the kind of people you would want to avoid - bullshiters with nothing to back their talk, that usually end up hijacking some part of the system by introducing random bullshit that only they can wade trough - to ensure job security. So even if the metrics are right the interviewers suck at measuring them. When I hear questions like these it's usually a red flag.

This makes the assumption that you just stop there and cannot ask follow up. Follow up questions that can garner a more clear answer on how code quality and shipping happens in a practical sense:

* How do you ensure code quality? * Do you perform code reviews? What's the procedure there? * What's code rollup like? * How often do you deploy? * Can I watch a deployment? * What SCM do you use? * Do you use any CR tools like gerrit or Crucible? * What's the process for a product from inception to launch?

These are just a few questions you can use to determine help you find out if the company values code quality and shipping products.

People often forget that an interview isn't one way. Just as it's important for the company to be prepared with questions for an interview, it's equally important for the interviewee to be prepared as well. However, this is often the case. People are so focused on providing good answers to questions, they forget to prepare good questions themselves. Often times good questions can help provide answers to questions not yet asked, and make the entire affair much more enjoyable.

And your followup assumes that you're talking to a programmer and not a recruiter. I guess it depends on where you're interviewing but I've had more than one interview with HR/management only (needless to say that even tough it was the "first round" I didn't stick around). Anyway I would just ask them what for a technical description of my role in the company, things like SCM and CR assume that I know what tools are good/bad, it's perfectly possible that they are using something that I think is bad but makes sense for them, so I guess it goes both ways, I expect the interviewer to be competent, and I trust my instinct on evaluating that, and then just do the trial period.

Also if you're going to ask the details, then skip the platitude entirely and focus on what you're interested, unless you consider them courteous prelude to detailed questions.

Assume? I'd know if I was talking to a programmer rather than a recruiter. Doesn't change what questions I would ask or expect answers to.

Let me ask you this: do you feel it's important that someone in HR be able to answer your technical questions? Do you feel you should be able to ask whatever programmer you interview with about compensation and moving expenses? Interviewing isn't just a one and done thing.

> I guess it depends on where you're interviewing but I've had more than one interview with HR/management only

And?

Still doesn't change anything I said.

> it's perfectly possible that they are using something that I think is bad but makes sense for them,

That's why you ask: so you can discuss this.

I don't understand: it seems like you talk about these things, but are disagreeing with me... just to disagree?

Whatever point your trying to make, you aren't making it.

> unless you consider them courteous prelude to detailed questions.

I felt that was obvious from the OP's comment. It's not uncommon. In fact, it's quite common.

Coming out and saying "What CSM do you use?" gives no real background no what you really want to know.

However, saying that "code quality is important to me. So, I'm curious about your methods of CR and SC? Also, I'd be interested in discussing your deployment methods."

And, frankly, that's what I got from the OP. Certain things were important to him. He merely didn't bother with the details, because, let's be honest, what's the point (the point is, as we both know, to avoid having people pick over that one meaningless word he used or missed).

Which leads me back to this:

> And your followup assumes that you're talking to a programmer and not a recruiter.

Yes. I thought that was obvious given the context.

I feel like those things can be handled after the initial interview - when we establish that I'm a suitable candidate and they are actually worth working for. I feel that the programmer/CTO/who ever is qualified to make a technical evaluation should be the one to approve the hire and HR can do the negotiation afterward.

I think we're disagreeing about the context tough. I was quoting his statement because he used it as a example of the argument the article made from employees perspective - and my criticism is mostly about the article/recruiters using shallow questions that provide no information and focusing on trivial things and corporate speak on "company culture", "team skills", "decision drivers" and similar vague pseudo sociology/psychology and other buzzwords that allow you to pretend like you're doing something useful when you actually aren't qualified to evaluate/manage.

Then, that really negates most of what you were saying with regards to who is being asked. With that being the case, what was the point?

> I think we're disagreeing about the context tough.

Judging by what you just said, I'd say that you're having a difficult time with the context, and should reread what was written without bias this time.

First, the question seems designed to discover either personal attributes that are irrelevant to work or contractual preferences that can be used to hardball you during negotiations. Something like the Joel test is relevant to the questions you mention above. But the OP doesn't seem interested in Joel-test like answers, he says he wants something deeper and more revealing.

Secondly, virtually everyone is going to answer questions like this with trying to guess what the interviewer wants to hear. So it becomes a stupid waste-of-time mind game. As someone mentioned below, it's a lot like the "what are your weaknesses" question.

The biggest danger in interviewing is the tendency to hire clones of oneself. Questions like this are a huge contributor to that. It would be easy to re-word this question to make it more work-related and fit the kind of thing you're talking about, but the OP doesn't seem interested in that.

Personally I'd take the opportunity to answer that question by telling the interviewer about things that I genuinely care about, and try to gauge his reaction. If he balks and any of them it's nice to know that up front and not a few month down the road.

With that said, I don't find the question any better than how it's currently done.

I think companies would be a lot better if they administered the a Myers-Briggs personality test (or something along those lines). Having people choose and prioritize options that have no clear right or wrong answer speak better to their value system.

For example, a question could ask:

What do you value when it comes to coding (priorize)?

a) Quickness of delivery b) Stability, solid code c) Building for the future d) Efficiency (code execution)

There is no right or wrong answer. Some may say, "well it depends on the situation!" But picking a priority order will speak to the default way in which people think.

[1] https://en.wikipedia.org/wiki/Meyers-Briggs#Validity [2] http://www.amazon.com/The-Cult-Personality-Testing-Misunders...

I'm certainly not going to fill out some amateur-hour multiple-choice quiz so that some HR flack or hiring manager with no training or experience in psychological screening can get an insight into my "value system". If you want to know my value system, talk to me like a human being.

[1] http://en.wikipedia.org/wiki/Minnesota_Multiphasic_Personali...

It's when HR looks at your CV / experience / whatever, and tries to match up what you wrote up beforehand to what they need.

Do you know why it doesn't work well?

It's because the items listed in the CV / etc. are not necessarily comprehensive, and the matching process is one-sided and based from a position of limited data.

This question is an attempt at psychological buzzword bingo. When I'm looking for a job, I'm always trading multiple things off with one another. There is no single ranking. I'll consider what's on the table based on a fairly complex preference function. But this question is attempting to pigeonhole me a priori, before I know where which pigeonhole the company itself thinks it's looking for. I might be a great fit but have bad luck in my random choice of pigeonhole - random because my preference function isn't a ranked list of attributes, no more than my abilities are a list of technologies I've worked with.