I am sure there are lots of people who ask the question, "What have you been asked at interview?".
I want to turn this on its head and ask the community what question do you wish you had asked the interviewer before accepting, or not, a role.
I am sure there are many circumstances where a sensible question asked at interview would have saved a lot of pain later.
Apart from asking about your work environment (the team, your machine, cubicle/office, compassionate flexibility), you could also use the Joel Test [1] to rate their development process (not trying to be a fanboy! ;-))
I personally always ask to physically see the area I'll be expected to work in.
[1] http://www.joelonsoftware.com/articles/fog0000000043.htmlI don't go through alot of interviews, but for most I do, I usually ask more questions than the interviewer does. I have honestly lost my list, but off my mind:
Technical:
I always ask "Why do you enjoy working here?" Depending on the panel/individual you get some interesting answers and body language. If questioned back, the reason I ask is that who would be better able to speak about the workplace than those that have been here and are looking for me to potentially join the team. Overall it has served me well.
I also ask about their thoughts on training, further education and the like, as well as some that were previously mentioned.
Not programmer specific but some of my favourite and most useful questions to ask a potential employer include...
1 - Describe a typical day for me.
2 - Tell me 3 things you’d want me to achieve in the role.
3 - Do you have any concerns about me – I’d like the chance to address them.
4 - What qualities would your ideal candidate have?
1 - Oddly, this throws many interviewers. Whether it's my temerity in asking it or their inability to adequately answer it, I don't know. Even though it seems a perfectly reasonable question to me, I've never had a very good or detailed answer. It does help me get an impression of the person interviewing me though (usually the person who would be my manager).
2 - Again, it's rare that they are equipped to answer this but helps me form an impression of them and the way the company works.
3 & 4 - I ask these at the end of the interview (some might argue they are best asked at the start). I often find the interviewer will reveal his/her thoughts about me when they otherwise wouldn't, giving me a chance to allay any fears they have about me and put my 'case'.
There is a similar question [1].
Here is my answer to it.
Where do you see me in 5 years time in your organisation?
How have you learnt from mistakes made in your previous projects? if the interviewer says they don't make mistakes they are wrong and ego centric. If they do post mortems then great.
How do you ensure quality software? You'll be amazed how many people just don't test or expect code to be done right and first time and then complain about bugs
Do you regularly have late night sessions to meet deadlines? an indication of how much time you will be expected to put in and perhaps unrealistic deadlines
Do you have a training budget? How do you expect developers keep up with the latest advances. no training or investment in developers should ring alarm bells
If the company is not using the latest bleeding edge technology ask what are there upgrade plans. no upgrade plans may make business sense but as a developer you may not want to be stuck working with legacy technology
[1] http://stackoverflow.com/questions/11350/what-questions-should-be-asked-to-a-potential-future-employer-during-an-intervi#11360One I always ask is: "Can I work from home occasionally?"
In fact I rarely do work from home. My aim with this question is to find whether they trust their employees but you can't really ask that directly!
My worst job was when an interviewer lied about the role. I'm still unsure how I could avoid that pitfall again.
It is hard to ask probing questions of the interviewer when you really want/need the job. Not least because you feel awkward pressing for extra detail on fuzzy answers, which is often all you get back.
In the standard situation of being interviewed by a HR person and a senior coder I always play close attention to the answers and demeanor of the latter. Since he/she doesn't interview people as a core skill and isn't always comfortable toeing the company line, it's a lot easier to get indirect info about how developer-friendly the company is.
I agree with the "Do you enjoy working here." If you literally hate going into work, nothing else really matters. My first job out of college I dreaded going into work. It was boring, I wasn't doing anything I learned in college, and felt I was wasting all of the money I spent on school.
In my last interview, I asked "Do you enjoy working here." the interviewer asked "What do you mean?" that was a signal right there. I ended up going with another company.
Since most people at human resources have no clue about the work of a developer I would ask if I could have a chat with my (possible) future coworkers :)
One I like is, "Why did the last three developers who left your organization leave?" Their explanations and reactions will tell you volumes about the potential problems within the organization.
Also if you have any concrete requirements, you must be up front about them. For instance I need a flexible schedule to make childcare requirements work around my wife's busy job, so I'd have to ask how flexible they are willing to be on the schedule.
if it's a start-up firm, be sure to ask "Are you fully funded? For how long?"
well i dont know about other countries but in india you can never tell what your job exactly is going to be ... every damn HR person will blab on about "open environment ..flexibility environment .. dynamic growth opportunity" ... and when you join you find out its a all a truckload of crap ... unfortunately you can never ascertain such things upfront ... but i generally ask whether they have a specific role for me in the organization ... or am i just a brick in the wall ... (of course you can never tell whether this would be truthfully answered or not)
My favourite two, which tell you a lot from their reactions:
The second one is a good one to ask if it's the kind of interview where they ask you things like how you deal with co-workers, describe the worsts conflicts you've dealt with at work, how you resolve disputes etc.
One thing I have learned is to be sure to ask about the number of software developers in the company and also the number of development teams. If there are a smaller number of developers and teams, this means there are not as many opportunities to work in different areas. Likely, you will continue working on the same products over and over which can become quite stale after a while.
How does the company make money?
How fast does the company make money?
How fast does the company spend money?
What does the future look like?
'Is your coffee filtered or instant?'
'Is your coffee free?'
This sort of question is a nice, light note to end an interview on and can also give you an indication of how well they treat employees without asking a no-go question like:
'do you think your developers are worthless code-monkeys or important assets to your company that should be treated well?'
I like knowing the following, though I probably wouldn't ask all of them in the interview.
And less-work-related:
I've only had one job since graduating from college but one question that I asked was "Do you have a dress code?"
I always think that if you're a candidate that's worth considering, then you should have questions that you want to know if you were to have a think about it.
Surely if you're about to start in a new company there must be things that you want to know.
I don't think there are things that you should ask.
Ask whatever questions help you figure out the true essence of the business; the core function that produces revenue. It's important to be a part of the core revenue-producing part of the business (i.e., be software developer at Microsoft, or be a marketer at an advertising agency, but not the other way around).
They typically explain what I will be doing fairly well (domain, technology...) so I tend to have this quite clear after the first part of the interview.
I like to ask:
"What is the timetable?"
If they do regular unpaid overtime they are usually not very aware of how much of a red sign this is for me, and for some reason they will almost boast it, like "Uh, you know when you come in but not when you come out". As a bonus, I get to know if they reduce the working time in summer, and whether they have a flexible timetable (in the good sense).
If I haven't been shown the workplace (their mistake), I ask where I will work, is it a big/small office, where it is located, etc.
I also like to ask: "Do you do unit testing?".
Also, "Do you do code reviews?".
At some place I asked whether they had a source control system. They didn't.
These two questions tell me a lot about whether or no I want to work for someone. If the management keeps getting involved in the details, I (and others, I know) are not happy as I don't like micromanagement. Basically if you're hiring me to do a job, please just let me do it. Also, if the developers don't take a leading role in development policies and procedures, it becomes a lot harder to change bad ones and adapt to new situations and technologies where old policies don't apply properly, or needs to be updated. To me, this goes a long way toward telling me about how comfortable I would be working for the company.
How important is peer review/buddy checking in your development process?
What Unit Testing framework do you use?
What SCM do you use?
If its related to a certain project or product, I would ask where the project is headed towards. I'd be interested in what their plans are.
What sort of personal development budget do you have? Would you pay for me to achieve certifications (e.g. Microsoft Certifications) as part of my package?
Could you show me round your development infrastructure. I'd like to briefly understand your build process, documentation process, source-control, etc., etc.
The best interview I ever had took about 4 hours, as they showed me every aspect of the way they worked, and that's what sold me to take the job.
What is the companies business model?
Do you want to work for someone who has very good sales people, who can sell poor quality software and then make money selling training and consultancy on how to use the product they've bought?
Do you have any staff dedicated to helping customers resolve their technical issues with the product? What is the procedure for escalating a customer's technical issue to the attention of the development staff?
Some companies expect developers to get on the phone with non-technical end users who work for important clients and hold their hands while they are learning to use the software. Others go to great lengths to address customer technical issues without bothering the developers whenever possible.
This tells you a lot about how they interface with their customers, where they see the programmers in that scheme, and how they value programmers' time. It also tells you how much they've thought through their business model — it hasn't occurred to management at some places that they will need to support the product after its release. When they haven't thought that through, that role tends to devolve onto the development staff, which creates a frustrating work environment when your coding is interrupted to spend an hour providing technical support to a secretary at Important Customer Inc. who can't figure out how to submit a web form.
My favorites include:
Also, if you are talking with someone who has a similar role/responsibility, asking what a typical day is like can be very enlightening...
Any "yes" answers to any of these might represent a good reason not to take the job,
I think asking the JOS checklist might be a bit offensive, especially if the organizatoin doesn't follow any of those practices. Simply asking them about their current process can determine the same information, without sounding high and mighty.
And of course we all want to work on good equipment :)
How much process not directly related to the customer value of the product is applied? I.e. find out how many hours a day you're supposed to be focusing on the customers problems and how much is spent filling in forms and going to meetings not related to the product or problem domain.
What kind of development processes and practices are used? And tools. Is the company process purely managed by sending huge Excel sheets around? (I kid you not, I've seen 40k-lines+ documents being passed around for updating)
I haven't had time to try those two out, so I haven't come up wth a good way of putting it. Other than that, the the Joel test, probably.
"What is the career path like for a technical person"
Basically you are looking for how many levels there are before you are forced to be come a manager if you want a promotion.
I've found that the Joel test (yes, I know that Joel is one of the creators of SO, and that did not influence the content of my post at all) is a great start for questions to ask a company.
Personally, I think a software shop that doesn't pass the test can drive a developer crazy after a while.