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.

  • 2
    This seems awfully contrived. What's wrong with "Describe a difficult technical issue to me"? That seems perfect. What's wrong with it? – S.Lott Jul 11 '11 at 20:46
  • @S.Lott: so that I can evaluate not only how something is communicated, but whether or not it's actually true. And, have point of reference for comparison between candidates. – orangepips Jul 11 '11 at 20:51
  • 1
    I'm not sure you can evaluate how they exmplain something if you don't know the answer ahead of time. – JeffO Jul 11 '11 at 21:03
  • 3
    @orangepips: "wether or not it's actually true". How do you establish this for any part of the interview? – S.Lott Jul 11 '11 at 21:13
  • 2
    @orangepips: An interview involves significant judgement of veracity. This is what the task is. Creating or finding a tidy problem that the questioner has somehow "pre-studied" -- without any mistakes or errors -- before interviewing a technical expert seems to be impossible. I can't see how this would work. Can you clarify how it's possible for the questioner to be an expert in advance of interviewing a technical expert? – S.Lott Jul 11 '11 at 22:05

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 :-)

  • +1 - first two bullets are perhaps the most concrete examples of any answer thus far. – orangepips Jul 12 '11 at 17:03

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.

  • Great answer. There's always something on their resume I haven't used before. And you can always verify the facts after the interview if the answer sounds fishy. – Karl Bielefeldt Jul 11 '11 at 21:39
  • +1 fair enough. Do you think it's possible to evaluate that person's communication skills with a non-technical person using that approach? In other words, say the idea would be explaining hashing algorithms to an accountant instead of a programmer. Would you evaluate that differently? – orangepips Jul 11 '11 at 21:55
  • I don't think this is challenging enough. Procedural description (i.e. the how) is a relatively easy form of communication, one in which esp. programmers are skilled because that's how we communicate to the computer. A greater challenge would be tasking the interviewee to communicate the why. That is the gist of my answer: programmers.stackexchange.com/questions/91984/… – Matthew Rodatus Jul 12 '11 at 17:03
  • @matthew Rodatus: ehhhhh, "how they did it" is procedural. "How it works, what it's used for, and it's limitation" goes a bit beyond that. You have very good advice, but it gauges their rationality more then their communication skills. Although that's arguably more important. – Philip Jul 12 '11 at 18:14
  • If your own communication skills are suspect, you may not be the best evaluator of someone else's skills. Get a skilled communicator to do the evaluation (or at least observe). – Alex Feinman Jul 12 '11 at 18:37

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.

  • +1 this is along my lines of thinking, looking a good example of that constant. – orangepips Jul 12 '11 at 9:30

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.

  • +1 for the "it takes a village" sorts answers these questions require. – orangepips Jul 12 '11 at 17:04

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.

  • I'd like to think that answers provide possible topics for this purpose. I'd suggest that's what Programmers stack exchange purpose is: answers to qualitative questions, whereas SO wants quantitative. – orangepips Jul 12 '11 at 16:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.