Hiring embedded software engineers

As I wrote about recently, it has been a while since I last looked for a job, but, over the years, I have frequently been involved in hiring staff and I find the process interesting. In particular, I am curious about the techniques and challenges associated with recruiting embedded software staff.

My interest was piqued recently, when Marty, a reader of this blog, emailed me to tell me about his experiences and share his ideas on how the hiring process ought to work …

I have never been involved in a highly structured recruitment exercise. When I have been try to hire someone, it has been a matter if looking at resumes to see find candidates with the right background – qualifications and experience – and then face to face interviews. I always took the view that the best people to hire were those who demonstrated keenness and ability to learn new things. Why would someone change jobs in order to just do the same thing? Well, there are several reasons, but none are very interesting. There is also the “X” factor: sometimes I would meet someone at the beginning of the interview and immediately know that I wanted [or did not want] to hire them. I can think of a couple of cases where this feeling was very strong and both of them turned out to be very successful employees. But I digress …

Marty’s experience was that a number of potential employers were no so smart about the hiring process and made some fundamental errors:

• Employ a somewhat irrelevant paper test and base decisions on that instead of demonstrable experience.
• Fail to look at broad experience and, instead, look for keywords. For example, ignore the fact that the candidate a wide experience of communications protocols, but reject him because CAN is not on the list.
• Use a long drawn out recruitment process, which only serves to motivate good candidates to look for other job openings in the meantime.

The first two of these factors are more applicable to a “mature” technical discipline. Embedded software technology is moving fast and ability to keep up is the key skill. The third factor simply illustrates that a company moves slowly and that possibility will not serve to excite prime candidates.

A better approach is to recognize embedded software for what it is and apply a little common sense:

• Look at the candidates problem solving abilities.
• Talk to them about what they do when they are not at (paid) work; what does this say about them and their motivations?
• Always ensure that two or more people talk with the candidate, preferably on the same day. Do not lengthen the interview process, but make sure that all angles are considered.
• If a candidate expresses or demonstrates a passion, listen.
• Look at the quality of their documentation and ability to organize information in a sensible manner. Look at their willingness to work with a team to make a tough project a success.
• Lastly, make sure that the candidate is clear about the type of work that would be expected of them. The exact definition of “embedded software” is not always consistent and there is much room for misunderstanding. It is expensive and unpleasant for everyone, if a new staff member leaves quickly because the work is not what they expected.

As embedded software becomes ever more complex, we will need more people. Those engineers need to be skilled smart and motivated. The only way to find them is to approach hiring staff with a clear focus.

If you have experience on either side of the process, examples of good/bad practice or other ideas for how to make recruitment work, please comment or email me.