Slashdot Mirror
What Questions Should a Prospective Employee Ask?
Mortimer.CA writes "Even though things aren't great in the economy, it's prudent to plan ahead to when things (hopefully) pick up. In light of that, I'd like to update a previously asked question in case things have changed over the last four years: What do you ask every new (prospective) employer? When you're sitting in the interview room after they've finished grilling you, there's usually an opportunity to reciprocate. There will be some niche questions for specializations (sys admin, programming, PM, QA, etc.), but there are some generic ones that come to mind, such as: what is the (official) dress code?"
Similarly, what questions should you avoid? Read on for the rest of Mortimer.CA's thoughts.
He continues with these suggestions:
"What about my resume caught your eye? What hardware/software am I expected to use at my desktop (e-mail, OS, editor, source control, etc.)? Are there team lunches or get-togethers? What are your goals for the next six months, one year, three years? What ticket/issue tracking system do you use? Do you have separate build/stage/QA/etc. environments? How do you keep track of documentation? What are your full names (so I can Google them)? What are the typical hours of the team members? Those are some of the ones I've thought of after some digging around. Are there the generic ones that you ask? What are some question for various niches? (e.g., for sysadmins: what config mgmt software do you use?)"
"What about my resume caught your eye? What hardware/software am I expected to use at my desktop (e-mail, OS, editor, source control, etc.)? Are there team lunches or get-togethers? What are your goals for the next six months, one year, three years? What ticket/issue tracking system do you use? Do you have separate build/stage/QA/etc. environments? How do you keep track of documentation? What are your full names (so I can Google them)? What are the typical hours of the team members? Those are some of the ones I've thought of after some digging around. Are there the generic ones that you ask? What are some question for various niches? (e.g., for sysadmins: what config mgmt software do you use?)"
I often ask what are the actual (real) work hours. In my experience, a contract with an IT company at a programming job, states a basic outline of the work hours that are demanded of you (09:00-18:00, for example). Most of the time these work hours are just formal and not actual, since these types of jobs are very demanding (the needs of meeting goals and dead-lines). The kinds of hours that you'll be working may differ from the ones stated in contract. This information is quite important if you have some kind of routine - if you study part time, for example.
It is the universe that makes fun of us all.
The best questions are almost certainly those that are specific to the employer and the job which they might hire you for. These are excellent because they show that you've taken an actual interest in what they are doing and may have something to contribute to the overall team in the first 6 months or so. Which isn't to say that the other questions (e.g., generic "what are employment conditions like on the ground" checks) aren't good, but if the boss-to-be thinks you care, it's a big way to stand out for the better.
Or at least that technique has consistently worked for me so far, and people who ask such things do stand out when you're on the interview panel. Too many people just do generic applications for jobs and don't seem to care what they actually end up doing...
"Little does he know, but there is no 'I' in 'Idiot'!"
'Can I see an example of your code or documentation?'
If they don't keep documentation or their code tends to be messy and undocumented then you're going to spend half your time trying to figure stuff out rather than doing productive (and thus interesting) work. If a company's business is in a complex field (finance for instance) and the code/system has built up over many years there is a fair chance that both will be pretty incomprehensible to start with and if they haven't got reasonably documentation the your job is going to be harder and there is a chance that you'll never feel you full have a grasp on *everything* that is going on.
Apart from that, it will show that you give a damn about documentation and are organised.
Maybe not that, but "What keeps you up at night?" - obviously not asking about scary movies or a noisy neighbor, but about issues within the organization. I have found that this way of asking the question (as opposed to "What are the biggest problems?") seems pretty disarming and I've heard prospective employers divulge more than they probably originally wanted to.
Quidquid latine dictum sit, altum sonatur.
Where is this American "freedom" I keep hearing about? It seems than Americans are free to become slaves to their corporate masters.
We have acceptable labour legislation and single payer health care where I live. I get 3 weeks vacation after a year of employment, overtime after 40 hours a week, protection from many workplace abuses and I can quit my job without losing my health care.
These are basic rights which any worker should have. Economic freedom is also freedom.
I like: "What's the staff turnover rate like? How about in the dept I'd be joining?"
Yes, though personally I tend to be more direct than euphemistic: "How many people have left the company/department in the past year? Why did they leave?"
The thing about "dangerous" questions like these, and asking about realistic working hours, and asking about IP clauses in the contract, is that good employers will usually be more than happy to have chance to explain why they're not like the bad employers. Most will enthusiastically tell you that they have low staff turnover. In terms of copyrights, particularly at the young companies looking for good people, I've had a senior interviewer tell me immediately that he himself had got the contract adjusted to clarify that, and it certainly wouldn't be a problem. For working hours, I've had a much wider range of answers, but usually pretty honest.
I have never, to my knowledge, missed out on an offer that I would have accepted because I asked such questions. I may have lost at least two offers, but in both cases I already knew I wouldn't accept anyway after evasive or outright damning answers to the working hours question, so the question served its purpose.
Clearly YMMV, particularly if you're desperate for a job or if you're happy working for corporate behemoths that tend to have less flexibility in their contracts (and whose HR people may black flag anyone who asks too many questions).
The other thing I always like to ask, though it's probably best to leave it until after the first interview, is to see a sample of their code and documentation. Just as they can tell a lot about me from my solution to a coding problem, so I can tell a lot about them by seeing what kind of code they actually write. I have never been refused this request, though most places ask you to wait until the next visit, so it might be worth mentioning it in advance if you're going back for a second interview and know it's likely to be the last one.
My experience is that once you're past any HR goons and you're dealing with techie folks you might actually be working with, good people will be quite enthusiastic to show you something they consider good code and happy to accommodate your request. It puts them on familiar territory, and makes for a more interesting (and memorable) interview for them than the other ten they've done this week. As a convenient side effect, as well as giving you chance to see their code, it also gives them a chance to show off and creates an atmosphere of fellowship and professional respect--a good discussion about their code can make them start to think of you as one of them before you've even left the interview.
Again, I'm not aware that I've ever missed out on an offer I would have accepted because of asking this question, though again there have been a couple of places whose offers I would probably have turned down if I'd received them after seeing the sort of code I'd be working with.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
This is the worst advice I've seen on Slashdot. I'm a hiring manager. I conduct several interviews per week. It is a terrible red flag if someone does not have any questions. It demonstrates a lack of curiosity and empowerment. I need to hire curious people who will find and solve interesting problems for the business. The questions the candidate asks are a means to deciding if the he or she has what it takes.
If you expect to be in and gone in one year, ask for salary on the high end of the scale. If not, try to pick a range that won't see you the first to go at the first round of layoffs.
Remember, some positions are hired on pure speculation - the BDM is "90% sure we're going to get this contract so we have to ramp up". This sort of position is a wee bit volatile, and far too common for comfort. You'll need a bit extra at the end to finance the next job hunt, so don't live too high in the meantime.
Other questions: "What happened to my predecessor?" - If you have no "predecessor" then the job is a new opening. Follow that bit of data with "How is the job funded?" These are the sort of questions that can be hugely useful, as well as make a decent impression. If you don't like the answers, back out with a smile - if the job isn't backed with a good business case, it's waste of everybody's time to proceed further.
Do not mock my vision of impractical footwear