Earlier quoted context omitted.
I've never understood the heavy emphasis on in-interview coding or brain teasers. To the extent that I've participated in the hiring process (both as an IC and a manager), 80% of the interview is assessing culture/personality/ethic fit; that is, the basic "do I want to work with this person" question. The technical competence check is all retrospective, hearing them talk about prior projects and what the design and i…
> I've never understood the heavy emphasis on in-interview coding or brain teasers. Here's why https://blog.codinghorror.com/why-cant-programmers-program/
- Tell us about the approach you took with the take-home coding challenge. Why did you break up the functionality in the way that you did (modules/classes/functions)? What kinds of constraints or requirements would cause you to make a different call here?
- Tell us a debugging war story. What was the bug, how did you discover it and come to eventually understand the root cause? Any challenges with reproduction? What steps were taken to prevent it from happening again?
- Pick a feature of XXX programming language and explain how it contrasts with approaches taken in other languages. What do you like about it? It is more productive, efficient, safer, more explicit? What are the tradeoffs and how do you balance these? What kinds of projects would have you prioritizing using a language/ecosystem with this capability?
Someone incapable of writing a fizzbuzz program is not going to be able to bluff their way through an interview like this. Obviously you need to be committed to listening and exploring the space with the other person as opposed to flexing and looking for the "right" answer, but that's just part of the discipline of being a good interviewer and not a jackass.