4 ms·

I do not use fizzbuzz but variations that are simple like it. I do not like fizzbuzz for 2 reasons. It relies on a math trick. Modulus math is something ever

I do not use fizzbuzz but variations that are simple like it. I do not like fizzbuzz for 2 reasons. It relies on a math trick. Modulus math is something everyone can grasp but it is not something everyone knows about. Plus it is easily looked up and gamed. I try to pick something that has a few if conditions and a loop, which is what most people do. Bonus if it can be a 'refactor' style problem for the small walkthrough afterwards. But it is not necessary for that. If I were to make one up right now I would say something like 'given a string reverse the first half and move the second half to the front of the string and return the result'. There are enough little gotchas there to see if they have a feel for what can go wrong and loops and ifs. It also has an advantage that it is not easily looked up on the internet and pre-studied as fizzbuzz has been codegolfed on some discussions. The downside is it would probably burn a lot of time. So you need to budget your time with them accordingly. If I can talk someone into it I try the test out on them beforehand to see how long it would take. I want it to be quick. I just want someone who is competent and can explain what they did and has some relatable experience and can explain what they did there.

tsukikage 6y ago
One of my goto fizzbuzz-like variations is windowed mean - how would you implement a class with a method accepting and returning a number, such that the number returned is the mean of the last 100 numbers the method was called with. Some people ask more clarifying questions than others, but in any case a few minutes gets spent on this, we have a laugh and move on with our lives. Of the failing candidates, around one in three or so spend nearly the entire interview on this or fail to answer entirely because they can't get the maths right. Is that a "math trick"? It doesn't feel too different to fizzbuzz. It's not complex. It relies on high school maths, and except for very junior positions, for a job where you are expected to solve much more complex problems every day without handholding, even if you can't remember how averages work so I have to hand you the math, not being able to reason through the problem from first principles seems like a pretty big red flag for your problem solving skills to me. What do people think?
- sumtechguy 6y ago
  That kind of math is fine. The mod operator is not one that everyone uses but add/sub/mul/div is something most people use all the time. It is why I avoid mod in that situation. Once I show someone the 'mod' trick they instantly get it (if they have any sort of math background) but I want to avoid as much as possible anything tricky in a interview. I want them relaxed and not tense. As that is a different kind of test. Throwing in a trivia trick can hurt the interview. I have run across many programmers that are decent at it and have never used it. Also for your problem it would depend on the level you are interviewing for and how much time you want to allocate for it. As it is also a balance of filter and getting to know them which is mostly time management on your part. Remember you probably are going to be working with them. So a bit of chit chat goes a long way too. You can also use 'fizzbuzz' as a question 'do you know the trick of fizzbuzz'. If I show them the mod trick and they get it right away they show aptitude to learn. If they already know it then see if they can explain it. etc etc... Get them to talk. Also talk back to them like a peer as they very well could be! They should be interviewing you too. I just try to avoid tricky bits in interviews and expecting tricky results from them. It would be like asking the to write a swap two values function and expecting the triple xor solution. Tricky is for something you have been working on for 3 weeks and need a better solution, plus two spike stories. It is not for interviews. :) Just ask yourself would you be massively annoyed if someone asked you this in an interview with no context as to why and expected a particular answer. If the answer is you would be annoyed then do not do it. If you feel it is OK and you would expect it then go for it. Just remember your time management.
  - tsukikage 6y ago
    I mean, "is x divisible by y?" is only one aspect of fizzbuzz, and something that can be solved in many ways - you don't have to use the mod trick. You could write a function that uses a loop and subtraction to do that bit, if it comes down to it. If I just want to see you can code I'll take it and move on, and if I'm at a point in the interview where I am looking for something else then that's a conversation starter. But if you are applying for a programming position and claim a decade of programming experience - and literally can't come up with any path towards a solution - I smell a rat.

tsukikage 6y ago

One of my goto fizzbuzz-like variations is windowed mean - how would you implement a class with a method accepting and returning a number, such that the number returned is the mean of the last 100 numbers the method was called with. Some people ask more clarifying questions than others, but in any case a few minutes gets spent on this, we have a laugh and move on with our lives. Of the failing candidates, around one in three or so spend nearly the entire interview on this or fail to answer entirely because they can't get the maths right. Is that a "math trick"? It doesn't feel too different to fizzbuzz. It's not complex. It relies on high school maths, and except for very junior positions, for a job where you are expected to solve much more complex problems every day without handholding, even if you can't remember how averages work so I have to hand you the math, not being able to reason through the problem from first principles seems like a pretty big red flag for your problem solving skills to me. What do people think?

sumtechguy 6y ago
That kind of math is fine. The mod operator is not one that everyone uses but add/sub/mul/div is something most people use all the time. It is why I avoid mod in that situation. Once I show someone the 'mod' trick they instantly get it (if they have any sort of math background) but I want to avoid as much as possible anything tricky in a interview. I want them relaxed and not tense. As that is a different kind of test. Throwing in a trivia trick can hurt the interview. I have run across many programmers that are decent at it and have never used it. Also for your problem it would depend on the level you are interviewing for and how much time you want to allocate for it. As it is also a balance of filter and getting to know them which is mostly time management on your part. Remember you probably are going to be working with them. So a bit of chit chat goes a long way too. You can also use 'fizzbuzz' as a question 'do you know the trick of fizzbuzz'. If I show them the mod trick and they get it right away they show aptitude to learn. If they already know it then see if they can explain it. etc etc... Get them to talk. Also talk back to them like a peer as they very well could be! They should be interviewing you too. I just try to avoid tricky bits in interviews and expecting tricky results from them. It would be like asking the to write a swap two values function and expecting the triple xor solution. Tricky is for something you have been working on for 3 weeks and need a better solution, plus two spike stories. It is not for interviews. :) Just ask yourself would you be massively annoyed if someone asked you this in an interview with no context as to why and expected a particular answer. If the answer is you would be annoyed then do not do it. If you feel it is OK and you would expect it then go for it. Just remember your time management.
- tsukikage 6y ago
  I mean, "is x divisible by y?" is only one aspect of fizzbuzz, and something that can be solved in many ways - you don't have to use the mod trick. You could write a function that uses a loop and subtraction to do that bit, if it comes down to it. If I just want to see you can code I'll take it and move on, and if I'm at a point in the interview where I am looking for something else then that's a conversation starter. But if you are applying for a programming position and claim a decade of programming experience - and literally can't come up with any path towards a solution - I smell a rat.