Since I’m looking for work these days, I’ve been doing a lot of interviewing. An interview is a potential employer’s chance to learn more about me, but it’s just as important that I learn about them. I think in an ideal interview, I spend at least as much time asking questions as answering.
Over the years, I’ve created a standard list of questions that I want answered.
- What do you like best about working there?
- What do you like least?
- What would you change if you could?
These are all pretty obvious questions. If the person you’re talking to doesn’t have anything that they dislike, then I know they’re lying to me. No employer is perfect, and honesty is important.
- What’s your remote work setup look like?
Telecommuting can be very isolating, and the burden is really on the employer to make it work.
If the employer isn’t already set up on some sort of chat system, that’s a warning sign. If the primary form of communication between their existing devs is shouting over the cubicle wall, then it’s probably not a good place for a telecommuter.
- What’s your dev env like?
If they say “we don’t really have one” or “one shared machine with one shared database”, that’s bad. What I want to hear is “you can check out the source, run 1 (maybe 2 or 3) commands, and start hacking”. That said, I’m willing to work on getting them to that point if they’re willing to pay me to do so.
- How are conflicts resolved? technical, social?
This comes from a past position where management effectively did nothing in the face of conflicts, both technical and social. Conflicts need to be resolved. This can be as simple as “Jane is the tech lead” for the tech side, and “the manager gets the conflicting parties in a room to talk” for the social side.
- Do you have any sort of technical principles or vision?
Or is your code base a mish mash of whatever anyone felt like doing at the time. See above about resolving technical conflicts.
- What end-users do you deal with? How do they feel about the app?
I (strangely) like to talking to customers and understanding how they use a product. If the tech side never interacts with customers, that’s a problem. If the customers hate the app but have to use it anyway, that’s demoralizing. I’ll pass.
- How do you balance technical/business goals?
- Are there reasonable goals & expectations? How are missed deadlines handled?
Does the business side realize that developing software requires more than just building new features? You need to keep the code base manageable, fix bugs, and work on infrastructure. If it’s just features, features, features then it’s not the right fit for me.
- What is your level of tech debt?
- Testing? release with failing tests? source control? code reviews? continuous integration? docs? QA group?
This is my truncated version of The Joel Test.
If you don’t do any of this stuff, then you can hire me to introduce good dev practices. But I’m too cranky to just maintain your giant ball of mud spaghetti indefinitely.
- How would I fit in?
- What might a typical day look like?
I like to know that the employer has some idea of how they would integrate me into the team and what work I’d be doing.
- What’s the policy on releasing open source?
I’m more concerned with being able to release bug fixes for my existing projects than entirely new ones. If I fix a bug in Moose or DateTime at work, I must be able to release it, no questions asked.
I’d love to also package up work code for release when appropriate, but that’s more of a nice-to-have.
I won’t be working 50 hours a week. I have a life and other things to do. The occasional crisis happens, but some places are in permanent crisis mode.
I also plan to do things like go to conferences and visit my in-laws in Taiwan. The American standard of 2 weeks is terrible.
I don’t really like the idea of being on-call, but if there’s a reasonable rotation and compensation for being on-call, I’m willing to do it occasionally.
What else should I be asking? Tell me in the comments.
Robert, on 2011-04-22 12:39, said:
Sometimes I am point blank and ask “Why should I work here?”. I am surprised sometimes by the silence that follows.
Dave Rolsky, on 2011-04-22 13:35, said:
@Robert: Yeah, I sometimes ask that one too.
Ron Savage, on 2011-04-22 17:11, said:
At one recent interview, the guy said he was working 117 (sic) hours per week. OK, so he’s a control freak, and can’t delegate, and yes - it’s a permanent crisis scenario. But I see that as an abusive situation, and said: I work to live, not live to work.
Anonymous, on 2011-04-25 09:03, said:
Yes the U.S. standard of 2 weeks is inhumane, I grew up and worked in the U.S. and have lived now in Europe almost a decade where the minimum standard is 4 weeks (usually 5) and sick days are *not* counted as long as you are really sick (duh) and don’t abuse it. One huge difference I’ve learned (and this is anecdotal not scientific but it slaps me in the face it’s so clear) is that Americans are so darn tired/overworked all the time they actually do less at work per hour and seem to not be able to focus. True, total productivity of Americans is slightly more than Europeans because they are working that extra 3 weeks of work per year, but I bet if someone did a per hour calculation Europeans would beat them in most work categories.
And you very rarely see a European blurring the lines between private life and work so much that there is no difference, here they understand work is to be left for work time and private life is for me and never to mix the two. And guess what? Everything here in Western Europe runs really really well, in fact better than in America and people are never stressed about work. Most Americans have no idea that things can actually work properly like this.
Americans are getting screwed by U.S. corporations and their corrupt politicians who would never dare put a law in place that everyone has to have a minimum 4 weeks vacation or *gasp* actually a living wage (I mean can anyone live on what is it 7 bucks an hour?? It’s just modern day slavery)
errr, on 2011-05-21 12:57, said:
so did you get a job ?