I was once interviewing someone for the position of a junior Java/JEE  programmer. About midway in the interview, I asked him a question related to Serialization and Externalization in Java. To my surprise he rambled of an answer which had absolutely no relation to the question. It wasn't just a wrong answer, it showed very clearly that he hadn't even understood the question. The way most interviewers feel about developers and their knowledge is that it's OK to not know something but ideally a developer should be aware of what they don't know. What that means is you cannot ramble an answer when you don't understand the question. Not only does it show lack of professionalism but it also raises a huge red flag in the interviewers mind, because working off poorly understood facts is the source of a large number of (avoidable) bugs in software development.Sometimes a candidate is hesitant to admit that they could not understand a question. He might attempt to answer it anyways in the hope that it will magically turn out to be the right one (although the probability of that ever happening is pretty tiny). Unfortunately such a strategy usually backfires. To be honest there's nothing wrong in admitting that you did not understand the question and requesting the interviewer to rephrase it or give more details. IMO no interviewer will object to it or hold it against a candidate.As a professional software developer you will face such situations very often where you are told something you may not readily understand. And not only in interviews. It can happen in client calls, discussions with colleague's, team leads, etc. The right thing to do in all these situations is to first stop and clarify the question to make sure that everyone's on the same page.However, at the same time I can understand that interviews are slightly different. Client calls and discussions with colleagues are far less threatening while in an interview you are on the hot seat and understandably nervous. However the balance of power is not as inverted as you might think. Remember that interviewers are not out to get you, even if some of them appear very overbearing. Most interviewers actually want to see you succeed. After all they are interviewing people because they need developers and the sooner they find a good one the better it is for them. Keeping this in mind there are specific ways in which you can handle a situation where you have not understood an interview question properly. I'll outline the basic steps and reasoning here, so you can use it as is, or adapt the strategy for your specific situation.My first suggestion is: don't panic. Like I said earlier, in most cases the interviewer is a reasonable person who wants to understand your skills and is not out to get you. Assuming that you are not totally clueless about what the interviewer meant, there are a couple of ways to handle such situations depending on where exactly you are stuck (if you are totally clueless it is best to pass the question and move on).The first thing to do is rephrase the question in your own words. Since it's impossible to correctly rephrase something we haven't understood, this simple exercise will immediately help you determine which parts of the question you understood and what parts you did not. Rephrasing the question makes the problem more manageable by specifically calling out those parts which are not clear. There are several reasons why this may happen: assumptions, vagueness, complex terminology, and lack of proper contextual knowledge. I'll discuss each of them below.The most common cause for not being on the same page in any communication is assumptions. There are aways a set of implicit assumptions when we say something. Communication proceeds well only both parties understand these assumptions accurately. It's possible that the interviewer had made certain assumptions which were not clear to you; hence the confusion. Very often, when you rephrase a question, the interviewer will become aware of any assumptions they may have made and will respond by clarifying the question and adding details, putting both of you on the same page.However, assumptions are not the only cause of confusion. Interviewers, and very often senior ones, prefer to use very specific terminology. They may use words like idempotent, orthogonal, invariant, etc, or they may speak of specific design patterns. They may also use domain specific terminology which you are unaware of. Before I make any suggestions, I am going to take a step back and suggest that every developer must know basic terminology related to their field of work. Not knowing, shows that you don't care enough about your craft, which is never a good thing (here's a great website to improve your programming word power). Coming back to the interview, if you are unfamiliar with the terminology an interviewer is using, be honest and ask it's meaning. Do not try to assume what it might mean because your assumption may not be correct and it will put you in an even tighter spot.  Most interviewers when asked the right way will be more than happy to oblige you with an answer and may also provide some examples to help you understand better. A good way to understand the word properly before proceeding to answer the question is to recollect a context from your own work where that particular word can be used. You can even say something to that effect to show that you understand. Not only will it help you answer the question, it will also give you a context for remembering that word.Sometimes, although not often, an interviewer might just be vague. Probably not on purpose but because they are caught up in something else or perhaps they asked the question out of impulse. As earlier, rephrasing the question usually helps,  but if it doesn't then you can explicitly ask for more details.After all efforts, you may still not understand the question. In such cases it's best to pass the question. Spending more time on concepts you understand well is always better than shooting in the dark about something you are totally clueless about. However, you should always look it up later to add to your knowledge. You can also ask the interviewer for resources where you can learn more about it. Her disappointment about you not knowing the answer will be somewhat reduced by your curiosity and willingness to learn.