How do I hire a really good build / install engineer ?

Question

I'm a big fan of giving candidates practical tests during the interview process. It's relatively straightforward to give a developer candidate a programming test or a tester candidate a sample app to see how they would test it, but I'm not so sure what to do with a build engineer.

Added to this difficulty is the fact that I've come across a number of sub-optimal build engineers in my time, but it's hard to identify what makes them sub-optimal until they're already on the job. (No offense intended to all the build engineers out there, this is purely my personal experience - and I've been lucky enough to work with a couple of really stellar build engineers too, it's just that they are never available when I want to hire them !).

I've worked with a number of people who have turned out not to fully understand the tools that they're working with and/or have implemented overly complex and brittle build solutions that are hard to maintain and extend.

What are the qualities of a great build / install engineer, and how can those qualities be tested for during the recruitment process ?

Answer 1

I guess this is just one aspect of the job. But I'd ask what install systems they've worked with and the pros and cons of each. Their answer should tell a lot about their understanding of building good installers.

Not to go too far off on a tangent, but I went through this myself and fell in love with NSIS in the process. I talk a little about that in this article. It's definitely a situation where using the wrong tool for the job can create a lot of wasted effort while negatively affecting the end product. To me, InstallShield is the Microsoft FrontPage of install systems. It's decent for cookie-cutter installers but it's a painful experience the minute you want to customize things. NSIS, on the other hand, has been nothing short of stellar for the things I've used it for.

One more question -- I'd ask how many users the biggest product they've worked on has reached. If you're developing something for a huge audience then reliability issues in the installer are more frequently reported. And that creates an accelerated learning experience for the build engineer. It's that trial by fire experience that I'm sure you'll want this person to already have before you hire them, not after. ;)

Answer 2

Ask the philosophical questions during the interview: What are the pros and cons of this approach? What are the most important aspects of an automated build system, etc.

Then bring them in on a temp-to-perm contract. If they work out, great. If not, it doesn't cost much to get rid of them.

Answer 3

Depending on how your builds are done and what experience the candidate has, there may be some value in printing out a script and asking for something like, "What if I wanted to put in a new target?" or some other minor change that should be straightforward if someone is familiar with that kind of build.

How are your builds done now? This is where I'd say the meat of the interview has to be, particularly on what parts of continuous integration work and why is this a good idea. If you build web and desktop apps, then it may be worth asking various MSI questions and see if the candidate has rolled up their sleeves and gotten dirty with how code is made.

You may want to ask how they would automate builds and how often should builds be done, does that integrate with source control and if so, how, and various other things that you'd think such an engineer should be able to handle, even if that includes learning how to build something they have never used before.