Bruce Eckel has posted a short post on 7 questions to ask an interviewer:
- If I want to buy something like a book or a tool, how does the process work (how hard is it?). What’s the cost limit before the approval must go up the management chain?
In my group the process is simple, if it might make you more productive and costs $500 or less we’ll just order it. If it’s a bit more you might need to make a bit of an argument for it. And books, well if you need them we’ll order it today. The signature limit for a line manager in our shop is a few thousand dollars.
- What’s the noise level like during the day?
Fairly normal corporate shop with cubicles. Noise abatement comes down to coming in a little early, staying a little late, and probably wearing headphones some of the time. We’re moving to a new building so things may improve.
- How many meetings am I expected to attend, and how long do they usually last?
One 30 minute or less team meeting per week. A one-on-one meeting for 30 minutes per week. Probably a daily standup 15 minutes per day on your project plus a full planning day once every 30 days. Plus any meeting you agree to as a team on that project. Anything other than that is an exception. I can’t protect my developers from an occasional ‘All Hands’ meeting or HR session, but I will push back to not have them attend no value meetings.
So for an average developer on a Scrum project a total of 2.25 hours of meetings per week.
- Is there a dress code?
Yes, business casual with the typical Friday more casual. Your manager will probably always wear a tie, but that’s how you can tell him apart.
- Can I work from home sometimes?
Certainly, but we do believe in collaboration so you can’t hide out at home.
- Does it matter when I work, as long as I come to meetings?
Nope, if you can get your work done and make meetings you can work all the odd hours you want.
- How many projects have succeeded/failed in the last five years? To what do you attribute the failures?
Maybe 50 successful projects and two big death march failures. The death marches both started out with almost no requirements, then a overly complex architecture was setup to solve the poorly defined problem. So the failures were both a lack of requirements or decisions on what the client wanted and an over-engineered solution. Adopting Scrum especially for high profile large projects makes this possibility much less likely going forward, but no promises.