Ask Questions

Try to expound on "I don't know"s. If you don't have a textbook answer, try to explain what you do know, or mention a related topic that you know about.

Bad Example

Interviewer: "What is a closure, and when would you use one?"

You: "I think it has to do with functional programming, but I don't know"

Good Example

Interviewer: "What is a closure, and when would you use one?"

You: "I learned about closures when I took a course on functional programming, but I don't remember every detail... I do remember using them in my link aggregator project. Did it have something to do with functions and state?"

In the second example you accomplish a few things:

1. You communicate that you at least have partial knowledge, which is better than none.
2. You keep the conversation moving, which is better than an awkward dead end.
3. You ask a question, which often will actually get you the hint you need to go on and give a good answer.

In the real world, the best developers ask a lot of clarifying questions to their product managers, designers, and engineering leaders. It ensures they don't waste everyone's time building the wrong things. Here's a good example:

Interviewer: "Let's say you're designing a CRUD API to manage users and their photos. How would you design the endpoints?"

You: (after a ~5 second pause) "Hmm... are users allowed to share photos?"

Interviewer: "Good question... let's assume that users can share photos, but there is still a primary owner of each photo."

You: "Okay, well then I would probably have a /users endpoint to get information about specific users, and I would have a /users/:id/photos endpoint to get all the photos associated with each user. Would that work for our usecase?"