Several years ago I attended a management training course. It was largely a series of scenarios throughout which you had to apply the rules of the particular branch of management methodology to which we had ascribed.
It’s been a long time since I revisited those rules but by and large I’ve adapted them to match my personality and my own beliefs as to how a technical communications team should work. They are, as I’m sure you’ve probably realised, largely based around common sense and the knowledge that you are working with professionals. If you are not you are either working for the wrong company, or you hired the wrong people.
So, how do you hire the right person?
A quick search on the internet will return many thousands of results, featuring articles, training courses, recommendations and strategies. I’m not suggesting that my approach is better or worse than any but it’s worked well for me.
My guiding principle is not to treat an interview as an interrogation. It may sound obvious but I’ve been for interviews where you get sat across a desk from three or four interviewers who take turns in asking you very specific questions. This is fine for some roles but, particularly for technical communications, removes a lot of the value of the interview.
An interview is a conversation, during which you are trying to ascertain personality fit to your corporate culture and their abilities to fulfill the requirements of the job. The latter includes how they learn, how they communicate, how they think and plan what they are writing, as well as how they deal with challenges and adversity, and if they like pizza (an important factor in any software development office!).
That said, there is a structure that I follow and which I explain to the interviewee at the beginning.
Firstly I explain that they are free to ask questions as we go along.
Then I’ll give them a quick history/overview of the company, then outline our product set. Following on from that I’ll cover the requirements for the role and then give them a tour of the building to let them see the office and the WAY we work. Whilst I could sit and explain our development processes it’s much easier to take them upstairs to the office, show them the layout and discuss with them how we do things. It also lets them see the ragamuffins they may be working with in the future.
All of that takes around 30 minutes, and a good interview will be a bit of back and forth, a bad one is me droning on opposite a nodding head. Like I said, I think of an interview as a conversation (a focussed one, granted) and I tend to talk in an informal manner to try and encourage that.
Once that is over it’s back to whichever room we started from to go over their work experience and ask a few more probing questions. Typically I’ll include a senior developer at this point, as our product is very technical and requires someone who at least understands the basics of object oriented programming, that and it’s good to get a second opinion.
I do keep a list of questions to which I add when I hear a good one, and it’s not something I treat like a script, frequently (again, in a good interview) most of these will have been answered but the curveballs are good to chuck in now and again. Here are some of the ones I use most often:
- How do you identify audience types?
- What do you like best about being a technical writer?
- How do you gain knowledge of the topic at hand?
- How do you know what to write?
- Have you ever been overwhelmed by the scope of a job?
- What kind of manager are you looking to work for?
- Describe a recent piece of work?
- what went well
- what didn’t go so well
- What kind of things annoy you the most?
- How do you deal with sudden changes to your workload and scope?
- Why are you looking to move from your current employer?
- Do you feel you could have done a better job than your previous boss?
- How long will you stay with the company?
- How would you react if I told you this interview was terrible?
- Why should we hire you?
Once we get through that, a quick summary of the terms and conditions, salary expectations and so on and we’re done.
After all that, you should have a reasonable idea whether or not the candidate is worthy of working in your organisation. If you aren’t sure, or have any doubts about any aspect of a candidate then the best piece of advice I can give is not to hire them. It’ll end up costing you time and resource to overcome any issues, and no-one wants to have to do THAT type of management.
What about you? Do you conduct interviews, any tips or advice you want to share? Or perhaps you’ve got a perspective from the candidate side, had any interesting or challenging interviews recently?