03 March 2008

The Richard Test

The Joel Test is now 7.5 years old (!) and while it's a good first start, I've decided to fork my own version to suit my own preferences. This test is to be used once you've done some research on the company and found out as much as possible about the position. You should be able to ask many of these questions during the phone screen, and you should also let everyone involved know that you'll be asking more than a few questions.

Some notes about prescreening a position
If the job position is vague or contradictory, be wary: they make things up on the fly, and if you're okay with that, this test is definitely not for you. Have fun in Hacks and Deathmarches 101, though. It's right down the hall, inside the room with all the pizza boxes outside...

If the company has a lot of openings relative to the number of employees, be wary: they either have a problem keeping people or they're growing too fast.

If they're looking for junior developers and don't mention mentoring, be wary: they're cheap. There's nothing wrong with being thrifty, but cheap means they think they can get more for less. You don't want to work for a cheap company.

If they talk too much about how everyone socializes after work, be wary: they're a cult.

If the company is a software company and the person running the company has never written code for a living, be wary: while I've seen this work okay (as in my last job), it means that software people will be second-class citizens and management will never really understand schedules. Conversely, most technical people are not suited for management, so like everything, there are tradeoffs. A good software development manager can insulate you from much of the nonsense, but they're rare.

A corollary: if the software development manager has never written code for a living, look elsewhere. While they might have a rudimentary ability to cut code, they don't really understand the issues.

And now, on to the test.

The Richard Test

1. How do you manage version control?

Good answers are git, subversion, Perforce, ClearCase, etc.

Best answers include some mention of configuration management.

Bad answers are SourceSafe, CVS, and "What's version control?"


2. How do you build your products?

Good answers are CruiseControl, CruiseControl.NET, etc.

Best answers include a fully automated system for pushing builds to a repository, website, etc.

Bad answers are "We tell Jeb over there to send the build off his machine."


3. How do you manage issues and defects?

Good answers are FogBugz, JIRA, TestTrack, etc.

Better answers include some mention of a process which includes automated testing (when possible) for each fix. Give them a gold star if they have a way for customers to report bugs directly into the issue tracking system.

Bad answers are Excel, Post-Its, emails in a folder, etc.


4. How do you manage requirements?

Good answers include some discussion of features and some discussion of ranking them.

Better answers include some mention of traceability matrices, Steve McConnell's book, etc.

Bad answers are "We have the marketing people write them, and we just implement them."


5. How do you manage schedules?

Good answers are mentions of Agile practices, so long as they don't mention XP. Look up how successful the big project all the XP guys like to talk about really turned out to be. For that matter, if having two programmers "pair code" is good, why not have 3 or 4? Heck, have the whole team pass around a wireless keyboard in front of a projector and see how much code you get written. There's a reason John Carmack is one of my heroes...

Better answers include evidence-based scheduling (hey, I'm still a huge fan of Joel, even if I have the hubris to update his test).

Bad answers are "We try to figure out what we can deliver to the customer without having them sue us." I've heard this at one of my jobs. Seriously.


6. What best practices for software development do you encourage?

What I'm looking for here is some discussion of coding and design standards, test-driven development, design reviews, code coverage, etc.

Better answers include some mention of Code Complete or similar books.

Bad answers are "What do you mean by best practices?"


7. Describe your software development process.

This is a bit of a setup. What you're really looking for is whether they have enough of a process to describe it coherently without sounding like they're just thinking about it for the first time.

Better answers should mention that the process exists in some printable form.

Bad answers are at both ends of the bell curve: either they have no process and make everything up on the fly, or they have too much process and you have to fill out a form to make a change to the code. We're looking for a happy medium here.

Lots - and I mean LOTS - of companies are still at the left end of the bell curve, unfortunately.


8. What development tools would I get when I start?

Good answers are a new machine with the standard Microsoft development stack.

Better answers add a second machine, dual monitors, an MSDN subscription, and - depending on the specifics of your work - some additional tools like Visual Assist X, TOAD, etc.

Bad answers are a crufty old laptop that a couple of other people have used. Again, this is what I got on the first day at one of my jobs.


9. What are your offices like?

Good answers are individual offices with doors. Note that I said individual office.

Better answers are decent seating (Herman Miller, for example) and good desks with lots of work area and storage.

Bad answers are cubicles or shared offices. If they mention bullpens or team rooms, run AWAY!


10. What do you do to support professional development?

Good answers include reimbursing for books and tuition.

Better answers include sending employees to one conference or training session per year, or maybe letting them spend one week each year working on a pet project (learning Ruby on Rails or Python, for example: something technical).

Bad answers include asking "What do you mean by professional development?"


Extra credit
Some other things to ask about:
  • telecommuting
  • flex time
  • core hours
  • geographic location of the team (outsourcing is another sign that the company is cheap).

No comments: