Asking the Right Questions to a Future Employer?
coronaride asks: "One of the things that always seems to leave me stumped in a job interview is the dreaded 'Do you have any questions for us?' question. I was always taught that while it's great to have the answers, almost equally important is to ask the right questions. When interviewing for a development position, what are some good questions to ask? For you employers, how much weight, if any, do you put on this open-ended question? A few obvious things come to mind regarding benefits, atmosphere, development style, etc., but I'm curious to see others' opinions on not only what is expected, but what is appropriate as well."
Now that I'm on the other side of the table, I find myself asking candidates if they have any questions.
The primary reason is simply because I just want to make sure I answered any question the guy might have... Sometimes, the candidate's technical skills might be right, but there are other non-skill aspects to a job that makes it right for the person. Work hours, flexibility, friendliness, dress code, etc. So if there are aspects that matter, you should ask.
If you ask questions that are relevant to the company, it also shows that you've been paying attention, and that you're not just looking for a paycheck...
I like it when the interviewee asks me questions, because it shows me what they're interested in. This may be good or bad for the interviewee, but it's useful as a tool. Eg, given two similar candidates, I'd be much more likely to hire the one who asked, "What problems have you had with your architecture?" than one who asked, "What hours are expected?", because of what they intimate about the mindset of the interviewee.
Of course, I'd probably be more likely to hire the one who asked what hours are expected vs the one who asked no questions at all, since at least the one asking questions is expressing interest in making sure that the position is compatible.
Good questions, IMHO, to ask are ones that indicate an interest in the company or the position.
Why is this position available?
Is this a new position? How long has this position existed?
How many people have held this position in the last two years?
Who would be my supervisor? To whom would I report?
Whom will I supervise?
With whom will I be working most closely?
What do you like about working for this company?
What are the current plans for expansion or cutbacks?
What kind of turnover rate does the company have?
How financially sound is this company?
What projects and assignments will I be working on?
What happened to the person that held this position before? Was he promoted or fired?
What is this company's culture? (Ex: Is it rigid and formal or relaxed and flexible?)
What are the current problems facing the company (or my department)?
What do you like the most about working for this company? The least?
What is the philosophy of the company?
What do you consider to be the company's strengths and weaknesses?
What are the company's long and short term goals?
Describe the work environment.
What attracted you (the interviewer) to this organization?
Why do you enjoy working for this company?
Describe the typical responsibilities of the position.
What are the most challenging aspects of the position?
Describe the opportunities for training and professional development.
Will I receive any formal training?
What is the company's promotional policy?
Are there opportunities for advancement within the organization?
When can I expect to hear from you?
A number of other people had good questions, so this is not everything I'd suggest; I just didn't see this on a quick perusal.
Ask about their development practices. The Joel Test is a good place to start, even if you don't agree with everything he says or all of his points. I definately make sure to ask about unit testing, for instance, without which you are wasting everybody's time, especially mine as a developer. If you're going to yell at me for that, I want to know up front.
To highlight the other things I consider a bare minimum: Source control is an absolute must, or again, you're going to have to pay me a lot more to deal with the stress. Bug databases of some kind are a must. In both of those cases, it is possible to deploy such things on your own initiative, as long as no-one is actively undercutting you. You'll also get a pretty good sense of what you're going into; if the answer is not just "no", but "why the hell would you want that?", then you're in trouble.
Of course, if you yourself don't use any of these things... well, uh, more power to you and, ah, good luck with that "programming" thing...
The good news is that this will tend to greatly impress anybody else who knows what you're talking about. I pretty much sealed my last two jobs with two little words, "unit test".
There is one caveat to asking about financials. You should *NEVER* ask about the fundamental financials (i.e net income, total revenue) of a publicly traded company. Doing so shows you didn't even do basic research on them. If some information you want is not available through the standard disclosures be very specific about what you are asking for and make it clear that you have already done some basic research on the matter. But remember most interviewers (unless it is a very high level interview) will not disclose any financial data already not publicly available.
What you can ask and what I strongly urge is ask about is the competitive structure of the industry if you are not familiar with it. Who are the biggest competitors? Then you can go home and do research. If you can get easy access to whom your potential competitors do it before the interview. I have gone so far as to approach a competitor of the company I interviewed with pretending to be a prospective sale in order to get thier software and look at it prior to interviewing/accepting.