How to answer interview questions that don't have a concise answer?

Question

I've worked in the software industry for about a decade now, but I have a penchant for being extremely terse. So in interviews when asked questions with a specific answer I do fine, but when there really isn't any concise answer I tend to lose the plot a little bit.

Just as an example I get asked "whats the difference between C# and c++" all the time. I could talk about the differences all day or I could just say "Well X is y and A is b" and it would take like 10 seconds but wouldn't be complete and doesnt demonstrate my knowledge at all.

Should I start with what an electron is and how transistors work then continue into how we leverage those to create a "binary" protocol which can be used to blah blah blah computers yada yada operating system blah blah blah typing et cetera et cetera

I guess what I'm asking is how much is enough? I don't really care about their time as I tend to be very annoyed by this type of question, but I'd rather not waste mine.

Answer 1

Don't worry too much about being concise or giving a well-organized answer.

Obviously the perfect answer would be a neat, structured assessment of the main differences between the two languages. But coming up with this answer on the fly is extremely hard.

As an interviewer, I don't have a problem with answers that wander--as long as you actually know what you're talking about. If you don't know, don't try to fake it. But if you have lots of knowledge, but have trouble structuring it, a wandering answer doesn't necessarily hurt you.

Hardly anyone can think on their feet fast enough to come up with a great answer to that question, nor is it a question you can really prepare for. The bottom line is that few candidates will give great, focused answers to questions like this. The important thing is that you demonstrate what you know, not that you get your thoughts perfectly organized. You are being tested on software development knowledge, not your ability to come up with a catchy sound bite.

A few pointers, though, to help you answer broad questions better:

• Don't rush. It's ok to take a few seconds to think. Resist the urge to just start talking.
• Ask for clarification. If a question is really broad, it may not be clear what they really want. A follow-up question can help you understand the question (while also giving you a bit of time to think). I might ask, "The difference in what sense: language design philosophy? What they are suitable for? How one has to approach development?..."
• Acknowledge the limitations of your answer. I might start off "There are many differences, and it would be hard to summarize them all in a few minutes. But one difference I find particularly significant is...also, another thing is...". It's better to make it clear up front that you don't claim this is a systematic answer to the question.

Answer 2

With questions like that I draw with broad strokes, and then clarify if they ask me to. I try and break everything down to fundamentals. It gives a good solid base to explain from if they ask. A lot of the time they won't ask unless it's a technical interview, they're just trying to filter and get a general impression of you.

Terse and concise has many merits, I'd much rather hear a clear 10 second explanation than one that wanders all over the place, so like everything else, show your strengths, downplay your weaknesses.