Fielding Interview Questions

How do you field interview questions when they fall outside of that things you know confidently? It's unnerving to get asked a question that you don't know the answer to, especially when you're trying to prove yourself in a new field. It's easy to think that you need to know everything.

The field of software development is SO HUGE. Even the subfield of web development is still enormous. No one person knows even a tiny fraction of everything. Dan Abramov, the creator of Redux, wrote a great blog post a few years back listing all the things he doesn't know. As he points out, you can start anywhere in this giant field and fill in knowledge gaps as you go. I would be willing to bet that if you are a recent bootcamp grad, you know at least a few of the things on this list of things he doesn't know. On top of that, if you're interviewing for a junior position, you're probably going to be evaluated more on your ability to learn new things and work as part of the team, rather than on the encyclopedic knowledge that you currently have (or don't have).

When you're interviewing, envision three concentric rings into which any question could fall. The innermost ring contains the things you are certain that you know. If you get asked a question that you know the answer to, answer it confidently and without hesitation. Don't put a question mark at the end of the sentence and don't ask the interviewer if you're correct. It's worth practicing this because it's easy to waffle and hesitate in the moment when you're talking to someone that you perceive as much more knowledgable than you.

In the next ring are the things you know a bit of, but you're not totally confident in. Maybe this is a subject that you've read a little about, but never used in practice. This could even be something that you covered in bootcamp, but never quite fully grasped. In that case, be honest about that. Start off by anchoring your answer with whatever you do know about the thing you've been asked, then move outward and describe where you wouldn't be as confident. Again, be honest but specific about that. Describe the concrete steps you would take to address your lack of knowledge. Which documentation would you read up on? What specific phrases might you Google? Who might you consult for help? Make it clear that you are aware of the edges of your knowledge, and that you're comfortable working at those edges.

The outer ring are the questions that you just flat-out don't know. Again, if you're asked something in this ring, be honest and say that you aren't familiar with that technology or concept. Then try to bring it back into the center of the field by comparing it to the things you do know. For example, if your interviewer asks you something about MongoDB but you've only used PostgreSQL, you might say "We used Postgres in my bootcamp, how does MongoDB differ?" The interviewer will likely tell you that Mongo stores objects as documents with arbitrary keys and values, similar to JavaScript objects. At this you might say "Oh, like the JSON field type in Postgres!". Then you can discuss what you know about working with JSON types in Postgres. Even if you've never worked with JSON types in Postgres, I bet you can think up some intelligent questions to ask about what it's like to work with MongoDB that demonstrate your ability to think critically. Now you're having an intelligent conversation with your interviewer, instead of just saying "I don't know".

A huge part of your job, especially early in your career, is learning. If you can demonstrate in your interview that you know where the edges of your knowledge lie and that you can expand them when you need to, then it becomes much less of a liability to not know the answer to any one specific question.

Next Up:
The Lump of Clay Problem

Previously:
An example of talking through your code