> > ask (...) “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know. > Not that believable, but okay. To me, it so

> > ask (...) “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know. > Not that believable, but okay. To me, it sounds very believable. I have been asked about defining what closures are multiple times. I switched a couple of times between backend, frontend and mobile, and I had to learn bunch of interview questions that never came up in real life. In different communities, there are different concepts that they love to ask, even if in the end at your day job, you rarely use them. The JavaScript interviews are always about quirks very specific to JavaScript that the interviewer learned last week. They then act like without that knowledge you can't possibly contribute to their Angular dashboard. JavaScript people always go through some examples of the "you don't know js" book, and they ask about the quirks of the language. My opinion is that the code they ask about would be rejected at most companies PR review process, because they are tricky, unclear, surprising. The "You Don't Know JS" book is a great book, and you shouldn't use 95% of the code in there if you want to scale your team without very-hard-to-find bugs. Java and Android people love their design patterns and clean architecture questions, and they would be floored if you told them that you don't need 13 layers of classes just to call your backend and build a plain old Java object from a JSON. People also love asking questions they themselves could barely answer. Yesterday, the team lead of my team had to accidentally clarify the event loop in a technical meeting, he was squirming, his clarification was terrible, yet we expect juniors to nail the question, and if they don't explain it exactly like we would, we act like the candidate is a "script kiddie".