There’s a great test for programmers called FizzBuzz. It’s an extremely easy task - print some numbers (maybe 1 to 100), but replace them with Fizz if they’re divisible by 3, by Buzz if they’re divisible by 5, or by FizzBuzz if they’re both.
Many reasonable people consider it way too easy - if you can write this, it doesn’t mean that you can write complex programs, or that you know the applicable languages, or that you know anything about the business domain.
But interviewers know that it’s a great test because a lot of so-called programmers still fail it.
We did a fizzbuzz interview with a candidate. He passed but I had a weird feeling about it so we asked him to do another one with 7 and 21 and he couldn’t do it even with his old code right there
Damn, dude managed to literally memorize code without having any idea of what was going on. Meanwhile, I’d spend most of my time trying to figure whether it’s div or mod that i’m supposed to use to check for the remainder of a division, I always forget which is which
It’s slightly different because all numbers divisible by 21 are also divisible by 7, so you would get all Fizz and FizzBuzz but no Buzz. So the question is, should you even be checking for Buzz, or should you make your code more efficient by eliminating those lines?
It’s good for a young dev IMO because that problem has many solutions and shows the programming style of the dev as well. But I agree that having a problem that is related to the actual work is better.
There’s a great test for programmers called FizzBuzz. It’s an extremely easy task - print some numbers (maybe 1 to 100), but replace them with Fizz if they’re divisible by 3, by Buzz if they’re divisible by 5, or by FizzBuzz if they’re both.
Many reasonable people consider it way too easy - if you can write this, it doesn’t mean that you can write complex programs, or that you know the applicable languages, or that you know anything about the business domain.
But interviewers know that it’s a great test because a lot of so-called programmers still fail it.
We did a fizzbuzz interview with a candidate. He passed but I had a weird feeling about it so we asked him to do another one with 7 and 21 and he couldn’t do it even with his old code right there
Damn, dude managed to literally memorize code without having any idea of what was going on. Meanwhile, I’d spend most of my time trying to figure whether it’s div or mod that i’m supposed to use to check for the remainder of a division, I always forget which is which
It’s slightly different because all numbers divisible by 21 are also divisible by 7, so you would get all Fizz and FizzBuzz but no Buzz. So the question is, should you even be checking for Buzz, or should you make your code more efficient by eliminating those lines?
I think they meant 3/7/21 instead of the standard 3/5/15.
Omg!
Oh I could see how that would trap someone. It would trap me but I’m not a programmer. 😆
It’s not that great really. It’s not bad, but when you’re interviewing people just find a similar problem in your domain.
It’s good for a young dev IMO because that problem has many solutions and shows the programming style of the dev as well. But I agree that having a problem that is related to the actual work is better.
It is great because it allows you to eliminate bad candidates very quickly. It can’t be the only test, but it’s very useful as the first one.
I very much prefer every product of multiplication of 9 up to 3000 in a descending order.
Ypu get to see a lot more than the fizzbuzz. And still very easy task. Then you can ask about processing and memory optimizations.