After the Offer Come the Questions

There are some questions that are appropriate to ask in an interview and some that should be reserved until there is an offer.  Somehow I became “famous” for the questions that I ask after I’ve been extended an offer.  For me, these are important to give me a more complete view of the working environment and attitude of the company and team that I might join.  It also gives insight into specific policies and practices.  I like to have as much information as possible when considering an offer. I also want to reduce the number of surprises after an offer has been accepted.
I’ve been asked several times for the “list of questions” that I ask and I’ve promised a blog post for a while, so here it is!  Here are the categories that I am interested in with questions that I’ve used in the past for each.  These, of course, need to be suited to the particular situation and some you may not care about.  And some I will ask in an interview depending on how well I know the interviewer.  Enjoy!

1. Hardware
1. What is the hardware setup for developers?  Desktop/laptop, monitors?
2. Would I be able to choose anything about my systems or is there standard hardware across the company?
3. How often is hardware replaced?
4. With hardware, would I be able to choose my own mouse and keyboard? 
5. Is it okay to bring in personal hardware?
2. Software tools
1. What software tools does the company provide?  (Resharper, NCrunch, profiler, etc) 
2. Does IT have heartache over what's installed on a developer's box (other than file sharing software or other things that would eat bandwidth)?
3. What source control repository do you use?
4. What sort of testing environments are there?
5. What test testing frameworks do you use? nUnit, xUnit, mbUnit, mSpec?  Acceptance tests?  Fitnesse or something similar?
6. What sort of tools do you have/build/maintain around the health of your systems (to monitor, alert, etc)?  Is this something the dev team works on or is there an Ops team?
3. Physical environment (usually you get to see this as part of a tour at your interview, but if not for some reason)
1. What type of desk and chair are provided?
2. Would travel ever be a part of this position?
4. Learning
1. What sort of policy does the company have around budget for learning?  For example book purchases, conference fees/travel, online courses.
5. Company Policies
1. What does the performance review process look like?  What criteria are used?  Are employees evaluated on an absolute scale or on a curve (with respect to their peers)?
2. What does a "typical" annual raise look like?  What does an extraordinary annual raise look like?  What criteria determine this?
3. What does the title/level system look like?
4. Is there a Moonlighting Policy?  For example if I write a project at home (on my own time, on my own hardware with my own tools) am I able to retain rights to that software?
5. Is there a policy on contributions to open source projects, either out of something at work or on my own time?  What about use of Open Source Projects?
6. Dress code - is there one and if so, what is it?  (and is it strictly enforced if there is one)
7. Is there a policy on bereavement leave?
6. Team Culture/Process
1. Iteration/release cadence - What does an iteration look like (planning, retrospectives, review)?  Do you have a daily standup? Who attends?
2. Requirements - how are requirements expressed in the team?  User Stories?  Use Cases?
3. How are they tracked?  Is there a big visible board somewhere or is it tracked electronically (and if so, what software is used).
4. Where do these requirements come from?  How is the backlog generated?  Are stories decomposed into tasks or is a story the unit of work?
5. Estimation - Do you generate estimates and, if so, what method/process is used?
6. Are you currently doing continuous integration? If so, what platform are you using to do that?
7. What about continuous delivery?
8. How much code is the team responsible for?
9. What is the test coverage like?  Is TDD used on the team?
10. What percentage of the time is the team pairing? What activities does the team pair on and which do they not?
11. How does this team interact with other teams in the company (if there are other teams)?
12. What is the team culture around lunch?  Do most people work through lunch, eat at their desk, go out alone, go out as a team, go out with other people in the company or outside the company? (I'm guessing that all of these happen occasionally, looking more for what the norm is)
13. Are there any snacks/food provided by the company?  Any pot luck events?
7. Career Path
1. Are there continued growth opportunities available without moving into management?
2. Are there opportunities to move into management?
3. I'm interested in knowing what you feel I would bring to the team (how I could contribute immediately and longer term), how you see me fitting on the team, what the main attributes that you see that led you to extending an offer and what things you see that I would need to work on.

There are also questions about benefits and such, but those are very specific based on the information provided.
There is another list that I’m starting for the team that I’d be working with.  Here is what I’ve started with:

1. What do you enjoy about your job?  What are some of your favorite things?
2. What are some of your least favorite things?
3. What changes would cause you to leave?  (as a fill in the blank: If ______ changed, I would leave.)
4. What would another job offer that would cause you to go somewhere else (excluding money)? (as a fill in the blank: If another company had _______, I would go there.)
5. What, if anything, do you miss from a previous job?

So there it is.  I hope these are useful but you’re probably thinking “duh, of course I ask those things.”  In that case, the curtain has been pulled back.
Is there anything that I should add to these lists?

Employer Investment in Employees

Uncle Bob has a pretty clear opinion on who has the responsibility for a programmer’s practice/learning:

Professional programmers practice on their own time. It is not your employer’s job to help you keep your skills sharp for you.

Uncle Bob in The Clean Coder Chapter 6

Here Uncle Bob is talking to programmers, to employees.  What I hear is “don’t expect your employer to help you out.  If they’re not, that’s not an excuse.”

So, my question is, does that mean that employers should not provide any learning opportunities for it’s employees?

Sure, programmers are responsible for their own learning opportunities but could part of that be making sure to find an employer that provides those opportunities?  I personally take some time outside of work to sharpen my saw, but I also look for an employer that cares enough about me to invest in me.

Here is my reasoning why an employer would want to provide learning:

• Hiring is hard and expensive. If you have people that are a good fit, it’s usually easier to improve their skills than to hire someone new.
• Learning opportunities at work can inspire people to pursue outside work opportunities.  I have has several people that I work with start attending Utah Software Craftsmanship, Utah Code Camp and Coderetreats because of things that we’ve done during working hours.

What do you think?  Should employers provide opportunities for practice and learning?

The Perfect Job: The Company

Is there such a thing as the "perfect job"?  I sometimes wonder what that might look like... and a result of those daydreams I've come up with three main components necessary for the "perfect job".  I see these three as all necessary, like three legs of a stool.  That stool is not very comfortable if not at the proper height and the legs are not properly balanced.

The first component is the company itself that the job is at.  This includes a wide range of issues from the company in general down to the development department and the specific team that you're working with.

Things like pay, benefits and culture (including the company's attitude towards developers) are all pieces of the puzzle at the company level.  If the company values developers there are a few ways that this is manifest. 

• All the developers have boxes that have been recently upgraded.  Nobody complains about how long it takes to do stuff on their machine because they all know that they have the best hardware available or at least what is necessary to get the job done.
• All the developers have the tools that they need and/or want including add-ons for your development environment (in my case VS2008) and licenses for utility programs to help automate tasks.  (I'll do the obligatory tool list at some point... 'til then there is Hanselman's crazy long list).
• Training materials and opportunities are abundant and current.  This can manifest itself in different ways.  Some send all or a subset of their devs to conferences or other outside training.  Some shops buy books or study them as a group.  A good sign is a shop that has well stocked (and not dusty) bookshelves in each developer's work area and more importantly some of those books out, open and in use.
• Men much smarter than I have noted that if a developer is worried about the size of his paycheck then one of two things is happening.  Either he's severely underpaid or there's something else wrong and therefore the issue is "I'm not going to put up with this unless I get more money" which means other issues need to be addressed... fast.  So pay needs to be fair, hopefully above "average" and increasing based on performance.  Remember to consider all parts of compensation (salary, bonuses, health benefits, retirement, etc).

Overall, employees are valued.  From that post, Gordon Bethune is quoted as saying of Herbert Kelleher (founder of Southwest Airlines):

“He recognized that good employee relations would affect the bottom line. He knew that having employees who wanted to do a good job would drive revenue and lower costs."

If you didn't read the post yet, go read it... I mean it!

Another way that companies show that they value their employees is through attention to "hygiene" issues.  These are generally issues such as:

• Enough workspace.  This includes floor space (I think private is the way to go even though the industry seems to be moving towards open space... either way, not being crowded is important) and desk space.
• Areas for teams to meet.  This might be ample conference room space, big enough offices to accommodate groups or open common area.
• Quiet... minimal disruptive interruptions.

There's more that can be found in the classic Peopleware.  I'm sure that at some point I'll have to write a post just on workplace hygiene issues...

At the department and team level, you can tell that the culture is healthy for developers in a couple ways...

• Strong technical leadership is critical.  This might be coming from an individual or a group, but regardless, there needs to be strong sense of expertise on technical issues in the department or team.  There should also be a sense that management recognizes the technical leaders as valuable.
• Related to the previous item is the fact that the status quo should never be good enough.  Constant improvement should be part of the culture. That improvement should come from the top but should primarily come through organic efforts and supported by management.
• Good practices abound, including a good score on the now famous Joel Test.
• Developers feel like "part of a team" and take ownership, both individual and collective, of their code.

All these issues are rooted in company culture and are, unfortunately, hard to change.  I'll post later about what you can do to help your company improve if they're lacking but in the mean time, take an inventory of where your current company is at and what you think they (and you) can do better.

Stay tuned for the other two legs.