Tips on Hiring an Automation Engineer

Many QA managers don't know what to look for when hiring an automation engineer. They'll specify some generic criteria (knowledge of C#, knowledge of [insert major commercial tool name here]) and stop at that. Then, when an applicant comes in, the manager asks if they meet those criteria, and the technical side of things stops there. So here are a few tips I'd like to pass along when interviewing a candidate for an automation job.

Be wary of "automation engineers" who only know how to use commercial UI automation tools. Those tools are great, and they have their place, but they are not the end-all be-all of test automation. You also want to make sure they can write their own code outside of the automation tool. For example, many commercial vendors use VBScript as a programming language. If your candidate claims they can write VBScript, ask them to describe how they would perform a scenario outside of the UI tool in that scripting language.

If you already own a UI automation tool, don't hire someone who is an "expert" on a different tool. You're probably thinking that the candidate should be able to pick the other tool up quickly enough, and that may be true. But on a number of occasions I've seen people gripe and complain about how their favorite tool does A, B and C better, and this product is garbage. Some will even try to force a change in the department, to displace the existing tool with their preferred tool. This is disruptive and nothing but a time sink. The time spent arguing about tools is time that should be spent testing. If you've made an investment in a UI automation tool, hire people who are comfortable with that tool.

Describe your development process, and the app being developed. Then ask them where they see opportunities for automation. If they focus exclusively on the UI, then you have someone who won't be as effective as someone who talks about unit tests, who talks about testing an API, or testing the backend database. The key here is that a good automation engineer will look for places throughout the software development lifecycle where automation can be applied.

Ask if they've ever built their own tools, or if they've done any programming for fun. Someone who really enjoys coding will be much more effective than someone who just does it as a day job. Plus, someone who can build their own tools will be able to continue to automate in areas where commerical tool vendors don't. For example if you need to test against a beta operating system, db server or UI element, commerical tool vendors won't support you. Someone who can build their own tools will still be able to create automated tests.

Finally, and this is the most important, do they know how to test? Automation folks are testers too, and you don't want to hire a script monkey. You want to make sure that, as Karen N Johnson put it "...you feel confident that [they] can be handed an application, learn at least its primary aspects at a fairly rapid pace, jump in, join this project and find bugs." You want to make sure that these people can come up with useful scenarios for automation that will add value to your team; you don't want someone who's only able to take a manual test plan and turn it into an automated UI test.

What tips do you have for hiring an automation engineer?