If I was interested in interview questions like "Describe how you explained a difficult technical issue to a non-technical person" I would use the Googles to search on communication skill interview questions.. But, what I really would like is to have someone actually explain to me some sort of relatively difficult technical issue. So I'm interested in are answers that identify a useful topic for this purpose or examples of what others have do to create scenarios for the purpose of evaluating a candidate's communications. In other words some exercise that actually forces the candidate to communicate something challenging rather than describe some time in their past when they were required to do so.
Agree with many of the comments, that this seems overly contrived/complicated but...
It seems you have a few choices
- Ask a question from a domain outside of the field of expertise - "Explain how a transmission works" Which helps you see how they communicate their understanding of black box systems.
- Ask a question from inside the programming domain - "Explain how distributed version control works" Which helps you understand how they understand something you both know and have experience in.
- Ask a question that targets their understanding but not yours - "Explain to me the X algorithm/system/interaction you worked on for those five years from 2003-2008" Which helps you understand how they communicate their (deep) understanding to a novice. (note - you can also separately test for correctness of their understanding in another part of the interview, you don't need to test for communication and correctness together)
I'm probably missing one or two :-)
Easy, ask what they've worked on, or what tools they used, or what techniques were used. Whatever, it really doesn't matter, as long as you don't know about it. Everyone has some bit of niche knowledge about the last thing they worked on.
Then ask him to explain it to you. Not just what he did, or how he did it, rather get him to explain how it works. Like if his last job included hashing algorithms. Ask him to explain them to you. Maybe not the actual hashing algorithm, but how they work, what they're used for, their limitations, you know, technical stuff.
In short, to test his communication skills, you're going to have to communicate with him.
If you wanted to test their ability to communicate with non-technical people, pull in a non-technical person and quietly sit to the side as the interviewee explains something to the non-tech. For this, I'd choose a topic that you're familiar with, so that you can detect bullshit. But remember, no analogy is going to be perfect. Also, make sure that the non-tech is at least a little interested, or is willing to put in an effort to learn something new. Horse -> water.
If you're trying to evaluate how someone communicates, it'd seem like a good idea to hold what is communicated constant. Give the candidate all the information they need -- maybe a chunk of code or a diagram of some sort of system -- and sufficient time to digest it. Then ask the candidate to explain the information to you, or ask them how they would explain it to a smart but non-technical person, etc.
By providing the subject matter, you put all the candidates on an equal footing, and you can also make sure that you understand the material yourself.
Persuasive communication is a form of critical thinking and the hardest form of communication. So, I would test their ability to consider competing ideas and formulate a rational argument supporting one of them.
- Ask them a question that is loaded with heated subjectivity, such as their preference of static typing or dynamic typing. A good result would be if they objectively evaluate the facts, the applicability of both approaches in different situations.
- Ask them a question that is ambiguous and open-ended, such as "What is the best sort of developer to have on a software team?" A good result would be if they list a handful of attributes that are characteristic of all good developers and then discuss how a team-oriented philosophy doesn't require all developers to have the same set or level of skills; rather, you want at least one developer with skill set A and other developers with skill sets B or C.
- An open-ended question involving technology choice could be "What is the best programming language for a web application?"
- Or design-related: "What are the most important design patterns to have in a code base?"
Bad responses would have:
- Unclear rambling
- Primarily subjective preference
- No objective evaluation
- No consideration of opposing viewpoints
Most programmers are adequately skilled at procedural description (i.e. the how question) since that is how we communicate with computers, so I would test their ability to formulate an answer to the why question. By asking an open-ended question, you get to discover if they are able to distill the possibilities into a useful and wise conclusion.
Relatively difficult could be a rather loaded term to my mind. Was it just difficult at the time? Difficult as in the problem could be a Ph.D. thesis? As difficult as one of the Millennium Prize Problems? There are various interpretations of the term here as one could infer that this was just the hardest problem someone faced to date, hardest someone faced and resolved, or hardest someone ever read to give a few different directions here.
What you may perceive as difficult may or may not be to someone else. Thus, I'd suggest breaking the question down into 2 parts. First, have the candidate identify their hardest past problem and tell just the facts about the problem. The second part is explaining where was the difficulty, which is giving an opinion on where was the challenge and how was this seen and tackled. While this starts with what was done, the second part is where there may be all kinds of follow-up questions to see how did someone see this as hard.