Comment by moonchrome | Hacker News Reader

Comment by moonchrome | Hacker News Reader

Parent Full thread

>I'm not sure why people are so offended by this question.

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.

> Generic platitudes like "a culture that values code quality as well as shipping products" and "meaningful stake" are useless

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.

>This makes the assumption that you just stop there and cannot ask follow up.

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.

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

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.

>Do you feel you should be able to ask whatever programmer you interview with about compensation and moving expenses?

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.

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

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.

Yes, although I believe there is a component of conversational implicature in these phrases. Mention of "corporate culture" implies the speaker is interested in control--and probably more interested in the control of behavior than technical subjects. The emphasis on corporate culture, team playing and company values indicates the extent to which management values will be imposed top down. The preference for platitudes over definitional clarity indicates a lack of candor and the intention to conceal motives. Talk of silo busting is, in my experience, uttered by individuals inhabiting impenetrable management silos.

But all of those answers can be followed up by more detailed questions with specifics. If you are a company that values code quality, how do you back up that value? Do you have coding standards, do you do code reviews and so on. Either way, this provides a jumping off point for further discussion. If the interviewer cannot provide information about why working for them would satisfy those wants, then that company might not be a fit for you.

TBH my criticism was mostly related to the original article and the suggested kind of interviewing, from my experience they don't go in to details, it's a jumping off in to more useless buzzword questions and pseudo psychoanalysis (does money matter to you, what are your goals, what are your motivations, etc.) without touching on the important stuff (like can you code, did you work as a part of a team environment, what did you accomplish) I'm a fan of "describe a project you were involved in and feel is representative of your skill" as a jumping off point.

Reply on news.ycombinator.com