A few months ago, my friend Patrick Caldwell started a series of blog posts about how to land a programming job (Part 1, Part 2, Part 3, Part 4, Part 5, and Part 6). I like his advice and think that it's quite helpful to aspiring developers. However, he did miss one aspect of the job hunt: finding a job you'll like. Since "like" is a subjective term I'll just describe the questions I ask prospective employers during interviews. Currently I work at ThoughtWorks and I love it. I researched the company very thoroughly before joining. I either asked or discovered the answers to all of these questions before I accepted their offer. I'm glad to say that working here has met all of my expectations and more. Here are the questions that I need answered before I'll work somewhere:

Can I use Open Source Software?

I recently witnessed a project where the team had to move off of Git for source control because the client had a policy against using GPL software*. This was rather absurd because they had no plans to distribute Git or anything using it. It was merely their source control system.  Policies like this cause a number of problems for developers and the team as a whole.

• They limit personal freedom by constraining you to a smaller set of tools than you would have otherwise. They hinder productivity because, for certain classes of software libraries and tools, the best options are open source (Web Browsers, Source Control, ORMs, IoC, etc).

• These policies limit your experience and growth. To take this idea to an extreme consider if you could only use a proprietary language and framework invented by the company you work for. How useful is that experience to you or your future employers?

• Policies such as these typically demonstrate a lack of maturity in the organizations software development practices. Unless your goal is to bring that maturity to the company then this would be a reason to stay away.

* The funny thing is that their dev severs ran Linux. *

How many different projects will I work on in a typical week?

My motive behind this one feels like a personal preference but I have yet to meet another developer who doesn't feel similar on this topic. Before ThoughtWorks, I've had multi-month stretches where I'll have to work on more than 5 projects a week. Often multiple in one day. This makes work feel like such a grind. It's unproductive and harmful to both you and the projects themselves.  Task switching constantly might make you a little better at multitasking, but it will never be as effective as single tasking. You will also likely develop some nasty habits:

• You'll likely goof off more because you'll seldom be very engaged in what you're doing.

• Switching tasks will be the norm so as soon as a new one becomes available you'll be more likely to hop right on it thus losing all the context you've built up for your current task.

• Since you'll be more error prone (multi-tasking increases your error rate) this will make you more accepting of errors in your work.

I would be very hesitant to take another job where I'll typically be working on more than one project in a week.

How do you estimate the time needed to complete work?

Let's face it: there are better developers than you. There are faster developers, there are more thorough developers, there are slower developers and there are sloppier developers. Couple that with the fact that any estimate is just that: an estimate. Be wary of places where the developers doing the work are not the ones doing the estimating.

What is your software development process?

You should definitely know and be comfortable with how they develop software. If they have a process, how that process works, how you as a developer fit into that process, and how flexible they are with that process. I almost titled this question "Are you Agile?" but decided that would be too vague. Many companies will claim to practice Agile, XP or Scrum, but without the details of what they're actually doing you risk making some incorrect assumptions about how they interpret those labels.  Ask specific questions around this topic.

Can I talk to someone else? Lastly, you should ask to talk to other people you'll be working with. Ideally that would include developers, BAs, QAs, PMs or team leads of any kind.  Find out how much they like their jobs and try to get a feel for how you'd like to work with these people. Your instincts know more than you may think so you should probably trust your gut on this one.