A good interviewer will start at a high level and drill down into what you're experienced with, rather than pick an obscure topic and assume you've done your ho

A good interviewer will start at a high level and drill down into what you're experienced with, rather than pick an obscure topic and assume you've done your homework. For example, they might ask for a hard problem you've recently solved in your last company. If you say something related to code splitting, you can expect he'll drill down more specifically into webpack, dependency cycles, etc. If you say something related to frameworks, you'll get questions asking you to back up the choices you've made. Was it mainly developer productivity or performance you optimized? If you say performance, how did you measure? What metrics are you logging? ... You should prepare by just reviewing hard problems you've done and brushing up on aspects of it you might've forgotten or remind yourself what was difficult about it. This applies to the coding portion of your interview as well. If you write "===", you should be able to answer what that's for. If you use ".bind(this)", you should know why you had to bind it. For this portion, you can prepare by looking at code you've written and trying to pick out those parts which you never bothered to figure out but always "just did" (e.g. for many people, the === is just something they do because they see it everywhere).