Bryan's Coding Corner

This is Part 3 of a 3 part series on how you should go about figuring out if a company is right for you during the interview process. In Part 1 I looked at how to evaluate the people you see outside of the interview and the equipment you’ll use, Part 2 examined some of the questions you should ask your interviewers, and in this final part I’ll look at evaluating the company’s software and development tools/methods. I’ll preface this post by stating that this is a huge topic of which a large part involves personal preference, take everything I say with a grain of salt (as you should everything you read) and feel free to comment if you have other opinions.

• Language(s)
  • What programming language will you be working in?
  • Is it a language you’re comfortable working with?
  • What is the age of the language? If it’s really old it could be a sign of a shop that doesn’t rethink its tools and methodologies very often. If it’s extremely new you might have problems finding help with problems you have. Using extremely new languages is also a sign of management that is constantly chasing buzzwords or a “silver bullet” (hint: There’s no silver bullet) to cure their software development woes.
  • Is the language still active? If the language isn’t being used anymore there’s usually a reason. Programs may be impossible to write, difficult to maintain, or the libraries just never got up to snuff. Whatever the reason, a dead language should be left that way. From a career development point of view you will be gaining few skills that will further your career (unless it’s COBOL and please don’t cause yourself that pain).  In addition to any problems with the language and/or its libraries you will probably find it difficult to get or find much help if you run into problems.
• Source Control
  • Do they have a source control system set up? I really don’t care what reason(s) they might have for not having source control, if they don’t have it you need to run. Run like the wind and never look back. I don’t care if the only development they do is for one internal user and made by one developer, lack of source control should be a deal breaker. I will modify my initial statement slightly, there is one and only one reason for not having source control and that is if you are being hired as the company’s very first developer. But on the day before you are hired they had better be asking what kind of source control you’d prefer to have. In case you’re wondering, doing diffs on archived directories is not source control.
  • It’s not Visual Source Safe is it? As much as I like to joke around I’m serious on this one. In my experience VSS might be even worse than not having source control at all. At random times it will decide to drop your files from source control while at the same time corrupting them on your local machine. I hope a coworker has a fairly recent copy and you don’t need any previous versions. Have fun.
• Bug tracking and fixing
  • Do they track bugs and does everyone use the bug tracking software? You can’t do your job well without (at the very least) some sort of bug list as well as a fixed/outstanding status. I don’t care if it’s a shared Excel spreadsheet, they have to have something.
  • Does priority go to bugs or features? This probably should have gone somewhere in Part 2 but there wasn’t a good place for it. Priority should almost always go to bugs, otherwise you will be building new features on the top of bugs and possibly relying on buggy behavior in the feature. This might be something you can help change later so it isn’t a deal breaker but you should take it into consideration.
• Testers
  • Does the company have testers? They should. That being said, I have yet to work at a company with testers. Fact: Developers are rarely good testers and are never good testers of code they’ve written. If a developer thought of a bug or security hole then they’ve already guarded against it, it’s the ones the developers don’t think of that are the problem. Good testers are deliciously, diabolically evil. They’re the type that introduce Little Bobby Tables to your search text boxes, just to see what will happen and, oh yeah, do it while using a screen reader. Is that in your normal testing repertoire? I didn’t think so.
  • Does the company have enough testers? I don’t know how many is “enough”. Testers come with a range of skill levels and, just like developers, the best will be an order of magnitude better than the average. My best guess is no fewer than 1 tester for every 10-15 developers should be the lower limit.
• Development Environment
  • Are you comfortable using it?
  • Is it the newest version available? If not is there a very good reason? Cost is not a reason, if it saves you five minutes per day the upgrade will pay for itself in a month or two. Always make sure you’re using the sharpest tools possible.
  • It’s not vi is it? Remember vi is a subset of all evil.
• Code Reviews
  • Do they do them? Code reviews are something that I’m really starting to think signify a really good software company. They help developers exchange ideas and methodologies (read: learn from each other). In the worst case the best developers raise everyone else up to near their level. The slightly less amazing developers might not always know why they should tackle a problem in this way rather than that way but they will know that they should. In the more normal case everyone learns from everyone else and code quality and maintainability go up. This means everyone gets to have a much better time getting things done rather than trying to stack kludge upon kludge to get a feature to work. There are so many benefits for the developers and yet the biggest benefit comes from code quality (see Code Complete chapter 21). Getting a second set of eyes on the code finds more bugs and other defects than almost anything else you can do. Even with all of the benefits of code reviews it doesn’t seem like most software companies do them so I would give a company that has a code review policy a major bonus over a company with no code reviews.
• Specs
  • Do they make specs before coding starts? Many companies don’t do any planning up front either out of laziness or a misunderstanding of XP practices. While this might result in an early rise in some manager’s percent completed report what it really means is more bugs, headaches, and a slower project in the long run. At the very least the overall structure of the program needs to be laid out, a feature list made, key data structures chosen, and there should be some indication of the features most likely to be added in the future. Specs are also the only way a true unit tests can be written. If tests are not written with a spec you are testing what the code already does, or if you practice test-first methodologies then you are testing what you are going to write the code to do in 10 minutes.
  • Is the spec kept up to date? If the spec is allowed to go out of date then no one will use it and the time spent making it will be wasted. Even worse is if the spec goes out of date and someone follows it. Then you have time wasted in creating the spec, time wasted writing code to match an out of date spec, and then time wasted fixing the code to make it what it really should have been in the first place.
  • How formal is the spec writing process? As much as specs help there is a big difference between writing enough of a specification to get the work done and specifying so much of the program that you essentially write the entire program during the spec-writing process (UML I’m looking at you). If the process is too formal projects tend to take even longer and the program ends up so rigid that adding features in the future will be like pulling teeth from an angry ferret.

At this point I think I would be remise without the obligatory link to The Joel Test which contains a similar list by someone I have a lot of respect for. I hope this guide has helped you to decide if that company you’re looking at is right for you. You might even be someone with the capability to make changes within your own organization, in which case I hope I’ve given you some ideas and enough of the reasoning behind them that you don’t just dismiss them out of turn. Good software, really good software, can be made. It can be done without causing ulcers, without a terrible death march at the end of the project, without having to rewrite the software with every major revision, and without that terrible dead feeling inside you that comes from something you used to love so much sucking all of life out of you.

Hiring & Interviewing