Hacker News Reader

If they are being dicks and I'm certain I don't want to work with them, I would ask a coding interview question back. It was a while ago, but still got an offer this way :)

In order:

Do you use git?

How do you do ticketing?

What's it like working here?

In my experience engineers at big companies will not give you an answer to those, but canned marketing responses. I don't know why.

Now ticketing, that reminds me of the ITIL standards and reamedy fun (slang for nightmares). If a company has ITIL I always ask them what proactive support measures do you have in place, always a good question that as ITIL is in essence more reactionary/event driven and as such does not lend itself well by design for catering for proactivity. I was in a server room once, smelt burned solder type smell, traced to a server that smelt like something had blown. All services/diagnostics/monitoring checked out fine and indeed it was working fine. I wanted to plan a changing of the server/have a hot standby ready for it being proactive as literly something smelt wrong. Alas the ticketing system did not alow such a ticket to be rasied as the server was not faulty and there was no issue showing. Two days later that very server failed, turned out PSU had died and taken out the raid controller on the motherboard in the process. The impact of this was more work than had it not been proactivly addressed. That is why when they say ITIL, then I fear how it is implemented and as such ask how do they proactivly deal issues. At the very least they should have root cause analysis mentioned, idealy they will sing all about there great Q&A processes and how that is all catered though open to suggestions.

Your right about the canned marketing responses, most of those forget the interview is a two-way process sadly and deem any question you ask as a waste of there time, that is a sign you should take note of.

You have to be more sneaky. Rather than asking something as generic as

>What's it like working here?

ask them

>What do you like the most about working here?

If they give you something like "the stability" or "the high pay" those are generally bad signs. Better signs would for example be "the great people I get to work with every day" or "the autonomy to get to choose what I work on".

My favorite way of phrasing this question is "how does working here compare to other tech companies you've worked at?".

Very true, looking at the types and state of the cars in there car park and haveing a chat with the smoking cabals outside fire exits is often a easier way to get a answear to some degree.

But indirectly asking questions is the way and it is those clever ways that are the types of questions i'm realy interested in, like my question about ISO/BS standards, it opend them up to so much more than a simple yes and no and gives you insight into other area's. Like working conditions, are they documented well, badly, not at all, do they even know about those standards, is it something there looking at (often crops up that last answear on many area's sadly).

Is the pay individual perofmance based or team based and is it limited/capped in that if I do 200% better am I capped at some rate of inflation % rise anyhow. I also like to ask about problems, what was the worst day like this past year and why and how likely is that to happen again. That tells you alot about so many area's and also opens them up into telling you how it is as well as allowing you to highlight your relevant skills and chip in with did you try this or that at the right times, even if you agree and play noddy whilst they talk.

One I always ask is can I have a look around the office, the area were I would be working if I was to be offered a position. That is useful in guaging there interest as if they are not interested they will come up with a reason why they can't do that, if they are keen for that you can see what your dealing with and also get a good feel from the way others have there desks decorated. Be they anal, stuffed south park toys, simpsons posters, collection of 2600 mags. Those type of things, you can get a feel on many levels from that.

Asking them how long they have been there is another good one, longer the better, but if they sound bitter then you can take that as not a good sign as well. Though if there two hyper only been there few months then they are sadly not realy able to give you a a true picture, so again take advantage of there hyper still all new to me as well fun happy time mood and take a look around.

You can probably throw the "If you could change one thing about the company, what would it be" type question as well.

Or you can ask it along the lines of, what changes good and bad have you experienced in your working enviroment over your time here. If they can't list something in either then I'm usualy wary, most will at least complain about the canteen or some change, even if cheaper coffee. Though if there is no good changes and no bad changes they can think of then it does sound like it could be a boring company.

That's a nice play on the "What are you biggest strengths and weaknesses" interview question, in reverse. The only problem with that -- as we've been conditioned over the years of being asked this stupid question -- is to list a strength as a weakness (http://jobsearch.about.com/od/interviewquestionsanswers/qt/w...) so you don't actually get much meaningful information (other than maybe subtle red flags, like "stability" or "benefits are good", as someone mentioned).

>How do you do ticketing?

Always a good one. I also like a variant on this if they profess to practice agile development:

>How do you implement the agile process?

More times than not, it's a waterfallesque implementation.

Git chauvinism is ridiculous. Git is great for bazaar style open source. It isn't important for small teams or large coordinated teams.

Every big company uses Remedy. Some just dress it up a little.

A good way to ask questions is to use them conversationally. For example:

interviewer: What is Cassandra useful for?

interviewee: It's useful as a highly-available database if you can denormalize your data. What are you guys using Cassandra for?

interviewer: Well, we're using it to...

interviewee: Interesting. How's that working for you guys?

This not only can get you some valuable information to make your decision, but also looks confident as you're exercising some control over the interview. You just have to be careful not to derail the interview with this technique, or you'll come off cocky and arrogant.

I ask some questions about test coverage, coding standards, code reviews.. I'm sometimes more interested in whether I get the same answers from different people or not than the particulars.

I always ask for an example of a technical or tools decision that was made. I'm usually looking to see whether decision-making is well distributed or things get bottlenecked by a manage or lead.

Probably most of all I pick at how the organization decides what to build. I'll ask about features or products that have been sunset or rehashed, how requirements are discovered and communicated. How prioritization works. One of the easiest ways to get red flags here when applying for a spot on a team is to ask everyone I interview with what the team is currently working on. A large variety of answers makes me nervous.

Oh, and also big points off for "Yes" to the following: - Do you have an exchange server? - Do you have a sales team? - Is the person who makes the purchase decision for your product your primary user?

I don't agree with:

>Do you have a sales team?

If customers need to call in and speak to engineers or other non-business people to negotiate sales, that sucks. Having inbound sales people is a vital part of any good mid-sized company.

If you need humans to sell things, then of course I agree that you ought to have a sales team. I would just rather work somewhere that doesn't need humans to sell things.

The problem I have with sales is that they're often very good at what they do. Once you have sales, you have two products. Your sales folks, and the thing people think they're paying you for. It gets hard to know which one is failing, or worse.. succeeding.

At some point if your company is any good, you WILL need humans to sell things. People will want to call in for more information, and the job of the person taking that informational call is to convert them. Unless you're Google where you don't give a hoot.

Not everyone is secure with a "F you, sign up online or else" policy. Good salespeople with domain expertise can be exceedingly helpful at introducing direction to the company - not just automatons who sell things.

What company do you like that has no sales team?

And did you miss a negative in your last question?

Here's a list of 100 questions applicants should consider asking a subset of during the interview: http://www.basilv.com/psd/blog/2009/100-interview-questions-...

Joel test is far more revealing: http://www.joelonsoftware.com/articles/fog0000000043.html

The 100 questions article does mention Joel's test. I think the Joel test is mostly obsolete (it is 12 years old after all), but the obsolete parts of it can usually be fixed with either a more precise or more fuzzy question that the 100 questions may offer you so you don't need to come up with it on your own. e.g. on hallway usability tests, I think you learn more from a general "do you test the UI for usability?" which may indicate hallway tests, A/B testing, alpha or beta users, or even a response of "No, we know what works and the user will love it (and bend to our will if they don't) and companies that imitate us will get sued".

I ask, "what's the best thing and the worst thing about your job?"

Someone asked me that once, and I thought it was a great question, so I stole it.

"How stable is the team (meaning, how frequently does the team change members)"

"What is your company culture like?"