Part of a interviewer’s responsibilities is to test how many different things you know (“breadth” of knowledge) and then how deeply you know those things (“depth” of knowledge). In almost all cases, I strongly suggest that entry-level and intermediate developers focus as much as you can on depth of knowledge. As you gain a few years of experience, you’ll learn more things, increasing your breadth of knowledge naturally at the workplace and through side projects, but don’t sacrifice depth of knowledge for breadth too early in your career, because “Swiss Army Knife” engineering roles where you have to be kind of mediocre at a lot of things are extremely rare jobs to find. Many companies want to be assured that you’re an expert in something as you grow in your career.
To understand your breadth of knowledge, I’m going to ask a lot of diverse questions up front by asking higher-level questions about technologies you’ve used. As you tell me about the kinds of jobs you’ve had, projects you’ve worked on, open source projects you’ve contributed to, I may come up with more “breadth” questions to ask.
Depth of knowledge is where interviews are the most nerve-wracking. “What if I forget something? What if don’t know the answer?” Those are certainly valid questions to have in your head. It’s my job to keep asking questions until I detect “enough” areas where you are unable to answer. “Enough” is subjective, and every interview is different. I’m not asking questions to make you feel silly, I’m just doing it to get a clear view of what you know and what you don’t know.
Not knowing an answer is bad, yes. Not knowing because you’ve forgotten is just as bad as never having learned it. The best you can do is explain why you don’t know it, and move on. If you don’t know the answer off hand, instead of saying “I don’t know”, try finding something similar that you DO know.