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?
Hey- that would be a great interview with you! Your previous post had me thinking about interviews for a few minutes the other day. I would add the following question (which might just be a reformulation of your final question):
What will you add to our group?
I have another question that might cross the lines toward inappropriate, but that still doesn’t stop me from wanting to ask it. Many us work in the software industry, and presumably most of us have computers at home. So I think it’s a fair question to ask (privacy concerns notwithstanding):
What type of computer do have at home?
I’m not sure of the best way to frame the question, but the answer should illustrate the interviewee’s level of enthusiasm or recollection of detail for technical things. It might not be everything, but to me these are important considerations for a TW candidate.
You’ve got a very clear idea of how you structure your interviews. This is the most important thing. It’s critical to have a plan and structure when interviewing – otherwise it’s too easy to get off track. The one thing I disagree with is the order you do things. I like to stay away from a detailed discussion of the requirements and expectations of the position until after I ask the work experience questions. I do this to try to assess the experience objectively, without the candidate trying to spin their experience to the requirements.
w0 – given that I believe that technical writers should be TECHNICAL then I think the computer question is a good one.
Gary – that’s true, although I discuss reqs up front because I want them to try and relate their experience. I’ve been through many interviews in this format and you’d be surprised how many people have a ‘rote’ set of responses around their CV/work experience. It’s like they haven’t listened and, in my opinion that marks them down. I guess it’s almost like a judgement on how well they can think on their feet?