> it, I'd have to look up what the name means first or what it actually requires. Nobody says, "implement fizzbuzz." If they did want a fizzbuzz program, they

> it, I'd have to look up what the name means first or what it actually requires. Nobody says, "implement fizzbuzz." If they did want a fizzbuzz program, they will explain "write something that counts consecutively til 100 and prints fizz if the number is a multiple of three, and buzz if it is a multiple of five." More importantly, few places ask for literally the fizzbuzz function; it stands as an example of "something trivial with loops and conditionals." It is not measuring competencies, it is weeding out those who would def not be able to code from coming onsite and wasting everyone's time. If the interview question is missing context you don't have, let the interviewer know. It is either a bad question or intentionally missing info to encourage you to ask clarifying questions. As for the style of question, people realized that fizzbuzz was too easy and so leetcode problems were born. In reality, companies should instead strive to make Work Sample questions, those that are very similar to the work that will be done. To do this, I recommend taking a recent problem the team solved and minimize the scope and required institutional knowledge down to something that can be coded up by an existing teammate in N minutes and give the candidate 3N minute to solve it (15 min/45min works well enough). My last two questions from this method included debugging a buggy nightly-ran script and some malformed sql data that "customers noticed something was wrong" and the other was focused more on implementing a cache in a way to allow easier testing and metrics.