Answer the question with the question

I was recently at the job interview and the interviewer asked me about things I were knowledgeable, yet I didn't get a job from a very reason the way I answered his questions.

I made a rookie mistake: I just tried to say everything I know about the thing in question. This caused my answer to be chaotic and not very to the point. My interviewer listened to me, so I thought that I made a good impression. I knew things after all!

And few day later the rejection letter came to me. It contained the thorough feedback. I think it's good to have feedback like this, and I'm glad this company wrote it. However, to my surprise, I was rejected from the very reason I hoped to get through. It was communicated to me that I had problems with the clear explanation of technical matters. And they feared that I wouldn't manage to work in environment where there's a need of constant explaining things to many people, especially ones with smaller technical knowledge.

What did I do wrong?

I just didn't asked questions. Let me explain. When the interviewer asked me about the broad technical subject, I just started talking. Wrong. How could I possibly know what the interviewer wanted to know? Well. It's true that interviewers often ask vague questions. Like "Tell me something about X". I would guess that many of them just don't have any clue themselves. They usually don't know what they are asking. Though it is like it is. You as a candidate are also an active side of discussion. And you can retort "Okay, what do you want to know"?

Well, these specific questions were about:

• SOLID principles
• asynchronicity in JavaScript

It's hard to say something clever about 5 principles if I don't have a much time at least 20 minutes for answer. But I would assume that the interviewer expected some short answer. So if I had this question again, I could ask e.g.:

• should I talk about each of 5 principles or specific one?
• do you mean overall concept and reason for SOLID principles, or exact definitions of them?

When I had asynchronicity question again, I could go with:

• There are multiple ways to handle asynchronicity in JS, should I talk about all of them?
• From conceptual perspective? Or from programmer perspective? Or from perspective of JavaScript engine?

Notice that such questions not only allow for clarification of other people expectations, but also can be helpful to position yourself as an expert on the field. You know so much that you need to ask about what slice of your knowledge the other person is interested in. So it's useful to employ them, especially when the question seems to easy.