Perfect tool to weed out the fools who have not memorized the best fizzbuzz code before interview
Eh, it’s the minimum challenging thing you can use to test “can you program?”. If you think they’ve just memorised it get them to add a “bang” every seventh iteration. They’ll either do it instantly or look at you like a landed fish.
Have them output a bang as every seventh character, and have them think aloud
When I present this problem, I wait until they’ve got it solved and are finishing the code and say “oh wait, product has a new requirement for 7=bang” and they refactor.
In one interview, the (very competent) candidate just blew up at me and started yelling! Yeah, that’s a “no”.
Hired!
When of course the correct answer is "Well they need to make a new card, send it through estimation, and we'll get to it within 6 to 8 weeks."
Append a bang to every seventh Fizz or Buzz. Then append two bangs to every seventh FizzBuzz.
Correct if wrong but???
if( i % 21 == 0) Output.append(“bang”) if( i % 25 == 0) Output.append(“bang”)
??
I like to ask them to write the unit tests for it.
I typically did a variation of this in my phone screening. Can't create a for loop in 5 mins or less, no way I'm spending 2h of highly paid engineers to try to interview you. NEXT.
When I interviewed for my current job, I had gotten a head's up from someone else who had interviewed there to be prepared for implementing Fibonacci. I could easily do that on the fly, but I did practice writing it once just so I wouldn't stumble at all during the interview.
I flew through it and the guy who is now my boss said, "Um. That didn't take anywhere as long as we allotted for it. And it's better than my answer key. Let's come up with something else."
Another one of the interviewers chimed in, "Can you go ahead and implement that game of Monopoly?"
I said, "I don't know that we've got that much time, but I'll give it a shot." I started working on it and thinking out load as I did it. Class for properties, Enum for game pieces, constant integer for starting cash, you'll need a roll generator, make sure you account for doubles, etc.
The let me go for about fifteen minutes before they stopped me and said they had seen enough and were satisfied I knew what I was doing hadn't just memorized Fibonacci.
I'd rather weed out people who have memorised it. I don't think I'm being elitist when I say that, if you can't write Fizzbuzz on the spot the first time you hear about it (with allowances for interview stress), you can't program. It's literally just a test of basic constructs
Even if you don't know %
, you can just use counter variables that you reset to zero when you hit the number (which of course is just modular arithmetic, but you don't need to know that to solve it)
All you need is this:
if (i == 1)
return "1";
if (i == 2)
return "2";
if (i == 3)
return "Fizz";
if (i == 4)
return "4";
if (i == 5)
return "Buzz";
...
Then every time they say "well what if N is some higher number?", just keep adding clauses until they forcibly remove you from the building
didnt someone do this... unironically?
The one I remember wrote a code generator to output it.
I absolutely had this as a submission from a potential candidate.
[Edit] Actually reflecting back, I think it was even more basic than that. I think they just did a series of prints with no loops or variables whatsoever. It was just:
System.out.println("1");
System.out.println("2");
System.out.println("Fizz");
...
//repeat all the way to 100
I truly hope so
Exactly. And people can have wrong ideas about what the "best" fizzbuzz solution is.
To me, the best solution is easy to read, well structured, relevant comments and good, sensible unit testing. These are all things the right developer can do with any code, there's really no need to memorise it at all, it's not complex.
Some fancy python 1-liner answer they got off of Google would increase my likelihood of a rejection. Not clear what it does, clearly just copied it without thinking about readability and future changes to the code.
I would start asking about business requirements.
Is it likely that it'll always remain "Fizz", "Buzz" and "FizzBuzz" or is there a chance that the customer will suddenly require "Fizz", "Buzz" and "BleepBloop"? If so, it might make sense to treat that as a special case rather than just an emergent behavior from the fact that 15 is divisible by both 3 and 5.
Taking those extra two minutes to think ahead is worth much more than a too clever by half Python one-liner.
A pet peeve of mine is the common criticism of FizzBuzz which goes something like, "this is just a gotcha question to see if they know the modulus operator or not!"
Nope. When I give someone FizzBuzz I make it clear that I don't care how they do it. It doesn't need to be pretty, nor performant, nor terse, nor readable. It just needs to give the correct output. If that means doing the modular arithmetic manually as you describe, then they pass as long as it's correct.
It really is incredible how many people are filtered out by FizzBuzz and similar basic problems.
Exactly. The problem is 25-50% of the industry is too stupid or incompetent to do this problem, but they are on programming forums and have a habit of getting defensive.
People are downvoting you but you’re right. This isn’t some complicated dynamic programming problem or a novel graph solution that is very very hard to do in 30 minutes cold, if you didn’t specifically study those problems. This is fizz buzz, it’s a fucking for loop and a couple of if statements. This is something you should be able to write file before the end of cs1 and uses middle school math. This is the absolute bare minimum of someone saying “yes I can program”.
[deleted]
Y'all are agreeing
This is my reaction to raw FizzBuzz too. But did you read the actual article? The author does indeed properly consider a lot of other factors. For example, the whole exercise they use has a TDD setup. Someone memorizing the code would completely fail at most of it.
Next challenge: TDD "hello world".
Not sure if you are being sarcastic, but that's kind of the point. Weed out fakers who don't know how to program. These people aren't googling common programing problems and memorizing solutions. They wouldn't be able to do that without some basic programming knowledge. And if you don't interview people you may not realize people come in claiming years of experience and can't do even basic stuff like this.
For reference, these are the numbers between 1 and 100.
I mean I woulda failed this except for that hint. Seriously, who can remember what comes after sixty eleven?
What a hot take!
This is an interesting take. I'm near-certain we touched on fizzbuzz as an example at college in the 90s. I've a hard time believing it's from 2007.
I feel like it was a programming exercise in CS 101 in 2000, but I might just be conflating the similarity to foobar, which is a common placeholder in CS assignments.
Or maybe 2007 is when folks first started using this CS problem as an interview question over brainteasers. It's a little counter initiative to use a simpler problem like this vs trying to challenge the candidates.
FizzBuzz is a safe-for-work version of the Foobar problem, yes.
The Foobar problem has been around since at least the 90s, probably earlier.
Basically just a brand name for "do you know how to use the modulo operator?"
Pretty much. Apart from modulo it's a good wrap-up of "having you been paying attention this week". You've got a counter, you're incrementing, with a loop and two or three jump-conditionals - it's the perfect exercise to wrap-up week 1.
[deleted]
2007 references when Imran Ghoury wrote a blog post on the topic which popularized the use in job interviews. In his post he says it's s kids game so no one is under any illusion that fizzbuzz was itself invented in 2007.
I was surprised to learn it's from 2007 as well. I went over to Wikipedia, which describes it as a teaching tool for children learning division (which also happens to be a coding challenge, referencing the same 2007 blog post as OP's article). Wikipedia, surprisingly, doesn't have a "History" section for either the coding challenge or teaching tool.
Looking at Google Trends, it seems like Fizzbuzz first enters the scene in January 2007, the same month that the referenced blog post was published. However, the farthest back I was able to go was 2004, so that's not exactly conclusive.
one of the references is from 2002
Oh you're right! I missed that one.
You don't just print FizzBuzz on 15 you know
The article does specifically say 2007, even though it avoids saying 15.
It most certainly predates 2007. I remember playing fizzbuzz in person in the early 90s. You go around in a circle, the first person counts "one", the second person counts "two", the next says "fizz", etc. Whoever messes up loses.
I think the popularity of using it as a coding interview question is what came around in 2007.
A lot of judging a persons skills on a small task. I am not a fan of such coding questions when interviewing. Rather let them tell you about their projects and challenges. Not only is that making them feel more comfortable but it's also a chance to get insights in their presentation skills. Often times some discussions about tools or decisions emerge from that, also good insight if the candidate will tend to speak up or being silent when he has critics.
Rather let them tell you about their projects and challenges
This is not an A or B situation. You absolutelly check both or end up with shitheads who an talk the talk, but just move from company to company when people figure out they can't code for shit. And the industry is full of these people.
When interviewing senior engineers (or juniors who have some experience on their resume), I tend to ask about projects, tech stacks, problems they've had and how they solved them, etc. I've found that better than the coding riddles for exactly the same reasons you mentioned.
I recently had an interviewer who asked me to perform some of these basic appraisals like fizzbuzz, add these two numbers in JS, etc. I mean, it's fine, and I could do those things, but I withdrew from the interview process afterwards because I was looking forward to a technical discussion about my work and experience. At this point in my career I can tell from the direction of the interview whether they're gonna get stuck on process and "if you can't fizzbuzz you can't work here" rather than assessing how I solve problems, how I work on a team, my approach to testing and data integrity, etc etc.
And then you hire person that can't write shit.
I am pretty sure a guy who have worked on projects can write code much better than those who have memorized hundreds of leet code questions.
You don't know what he was done on this projects. You don't see code that he wrote, you don't know technical contributions, you don't see any proofs that he produced something himself. You only hear from this person what he allegedly achieved. There are plenty of people that can talk, but can't do shit themself.
That's the part where you as an interviewer need to adapt and ask questions to get those answers. Nothing is stopping you from asking technical questions about their projects. You just can no longer just go thrugh an interview step by step, you actually need to interact with the candidate and you also can no longer hide your lacks of knowledge by having googled some complex questions or tasks before the interview.
Coding Interviews Imho always go south once a candidate is not doing what you expect him to do.
I mean with Git you can see project contributions and when they happened. That can tell a really full story and would be a pain in the ass to fake.
It's the perfect filter. I've come across many resumes (and conducted several interviews) that have had years and years of experience and they could blather on about architecture and aws this and gcp that, but actually being able to think logically is a whole other beast. Our industry is being overrun with people who have zero algorithmic or foundational knowledge.
By all means, ask those sorts of questions. Ask them in the second interview after you've weeded out the people with no practical coding skill.
Rather let them tell you about their projects and challenges. Not only is that making them feel more comfortable but it's also a chance to get insights in their presentation skills.
This is an excellent idea. You should do this.
Often times some discussions about tools or decisions emerge from that, also good insight if the candidate will tend to speak up or being silent when he has critics.
This is what makes it a valuable addition!
That said, do you think there might be some small measure of value in finding out if a junior programmer can do a basic loop and if? Do you think it might help reduce the risk of hiring someone who can discuss tools and projects and challenges cogently and clearly, but has no practical hands-on skills?
I usually ask some questions specifically regarding the language (and if they bite I dig deeper), e.g. What does defer do in golang or how to return an array in c++ or how to execute a php file locally which are things you come across when using those languages. If they are more advanced my questions also get more advanced.
Until you come across people who lie. I’ve had plenty of people that go on and on about projects they’ve worked on. But don’t know a single specific that they supposedly did. There’s a reason tech industry goes with algorithms and coding, while enterprise companies can barely write themselves out of a paper bag,
I prefer to setup a dummy repo in the standards of the company that's themed with what we do and to give candidates an hour to fix a many bugs as possible. For seniors I also like to give them some requirements to add a small feature. When constructing these tests, make sure you have some easy to get bugs as well as some more obscure ones. For graduates it's nice to bring them into the office and tell them to feel free to ask you for help if they get stuck (this can show you what grads tend to get stuck spinning their wheel and also don't know how to ask for help). Quite interestingly, I've noticed that the more junior developers tend to out-perform senior developers on the bugfixing task. Senior types have in my experience been more inclined to find the obvious bugs, fix them, and not actually test the reported scenario.
FizzBuzz is trying to ask “do you understand the basics of programming”, but I’ve seen people tripped up by it because they’ve never run into mod before, or they get nervous coding live
What we used to do is ask interviewees to show us a short sample of any code that they had written, that they’re proud of. We would ask questions about the code, and it became obvious pretty quickly whether they had written it themselves.
The worst someone ever failed that part of the interview was when we were hiring for a C++ developer and someone sent us a pdf containing a photo of a printout of a website that was sitting on a wooden table. We tried to clarify with them - yup, that’s what they meant to send. They had “helped with the design” of the website
Sounds like they called their mom up to take a picture of a code sample they left back at home
This was before the phone screen - we’d ask for their resume and a code sample. There was not any time pressure
Oh I like this approach very much. I have a couple of pet projects that I could easily talk up and run through. Much better than panicking over live fizzbuzz which I'll remember perfectly once I hang up from the interview.
Not just programming, but basic instructions. I had a candidate struggle to even understand the problem, and then their recruiter told us that we were too hard on them.
Lol, this reminds me of something that happened in high school around mid 2000s. We had a Web Engineering class with one part of an assignment (or maybe it was a bonus question) to create an HTML table within a table. Remember, this is really early in web where Google still had their old logo, tables were still being used, everyone still hated Javascript, and Flash was popular.
Anyways, you'd normally just go about nesting the inner table within the main body's table. This other student, Craig, had instead: put a picture of a table, on top of a table, inside the main table (so not nested). The teacher thought it was hilarious and gave him full points for it anyways.
FizzBuzz is trying to ask “do you understand the basics of programming”, but I’ve seen people tripped up by it because they’ve never run into mod before, or they get nervous coding live
Seriously I never understood the appeal of FizzBuzz. The exercise is literally just "do you know modulus?"
My friend likes to use the Fibonacci sequence test.
Ask them to write a Fibonacci.
They write recursive. “What are downsides of recursive?” StackOverflow “Can you do iterative”?
“How to improve it?” Add memoisation/caching
“Say you a webservice that computes Fibonacci using the function you wrote, how can you improve it even more?” Pre calculate a bunch of values and use them as a cache
If someone derives the closed form solution to the Fibonacci sequence, would that be enough?
I used that too when interviewing. Perfect example to initially gauge someone’s general grasp on programming and to then start talking about adjacent topics.
The most puzzling thing is: you still get candidates that don't know about FizzBuzz.
Not knowing isn't a problem for juniors, not being able to adequately solve it would be the problem.
I'll leave the definition of "adequately" as an exercise for the reader.
It's pretty simple though. You don't need to know it to be able to solve it. All you need is common sense and decent basic programming skills.
Every single one for me, then again I interviewed mostly juniors.
Never heard of fizzbuzz until a couple of years ago. It took me a good 30 seconds to figure it's not some trap question but literally something to filter basic programmers from nothing.
There's also Project Euler problem 1, a variation on Fizzbuzz. I like it because it separates someone who can use loops and solve in O(n) from someone who knows maths and can solve in O(1).
Ok I'm stumped. The best I can think of is running through multiples of 3 < 1000, doing the same with 5s and doing it again with 15s so I can remove the overlaps. That's not O(1) though since 2000 would take twice the time.
The trick is calculating the number of multiples by simply dividing 1000 by 3 or 5 or 15. Once you know the number of multiples, you can use the old "sum of 1 to n" trick (constant time).
You were faster. Here's also a C program:
```
int triangle(int n) { return (n * (n + 1)) / 2; }
int sumMultiplesLessThan(int n, int m) { int amount = (m - 1) / n; return n * triangle(amount); }
int problem1(int m) { int (*s)(int, int) = &sumMultiplesLessThan; return s(3, m) + s(5, m) - s(15, m); }
int main() { printf("%d\n", problem1(1000)); } ```
The number of multiples of 3 is floor(1000/3). Each is of the form 3n. So their sum is just the 3*sum(n=1 to k)[n] where k = floor(1000/3), which is 3*k*(k+1)/2. Repeat for 5 and 15.
I think the trick is to use the integer sum sequence formula and multiply it with their corresponding multiplier 3 and 5 then sum it. It'd be O(1) then
Until you get to the longest integer calculations that can be done in constant time on the processor, of course...
I like that one! Just thinking about the math for a little but makes it really easy. I particularly like that there’s a twist to the math approach.
So you know that they know math, but still have no idea whether or not they can write the simplest program.
A program without loops is still a program.
Are you interviewing someone who will only work in O(1)?
The point of interview code questions is to weed out those who can't program basic algorithms and there is no reason to want a little side door for those who can't code but happen to know n(n+1)/2
if you don't know that trick or can't derive it yourself you do not actually know how to code
That's the dumbest thing I've ever heard, straight up not true, completely off-base, irrelevant, and at the same time manages to seem like a fragile ego kind of issue
you don't think coding requires middle school math abilities?
It's weird to see a post celebrating the power of FizzBuzz. I thought FizzBuzz was everyone's go-to example of a shitty tool for interviewing, since it revolves around a trite "gotcha" of whether or not the candidate knows of the modulus operator.
This post is like someone excitedly explaining to me that they're decades behind in terms of engineering interview quality. They might as well pat themselves on the back for asking candidates why manhole covers are round.
I thought FizzBuzz was everyone's go-to example of a shitty tool for interviewing
You thought... very wrong. FizzBuzz is something that anyone with any amount of coding experience should be able to get very, very easily. It exists simply to filter out people who apply as devs despite having no coding experience or knowledge whatsoever.
Knowing of the modulus operator is not a "gotcha", and even if you don't know about that fundamental mathematical operation you can still easily complete the task without it.
How do you "easily" solve it without modulus, other than a whole slew of logical checks?
Here are three different ways of doing it in JavaScript with simple mathematical operations.
const usingRounding = ({ num, target }) => num/target === Math.round(num/target);
const usingSubtraction = ({ num, target }) => {
while ( num >= 0 ) {
num -= target;
}
return num === 0;
};
const usingAddition = ({ num, target }) => {
let sum = 0;
while ( sum <= num ) {
sum += target;
}
return sum === num;
};
const usingRounding = ({ num, target }) => num/target === Math.round(num/target);
It gets the same result, but I feel it makes more sense to use floor here since we are looking for a remainder.
We're not looking for a remainder. We're looking to see if rounding a number changes its value. floor
would work just as well here, as would ceil
, but there's no particular reason to prefer them.
Thanks, I blanked on rounding and floor.
Compare the floor division of n with the floor division of n - 1
def base_check(n, base):
return (n // base) - ((n - 1) // base) == 1
def fizzbuzz_without_mod(n):
if base_check(n, 15):
return 'FizzBuzz'
elif base_check(n, 5):
return 'Buzz'
elif base_check(n, 3):
return 'Fizz'
return n
def do_fizzbuzz(n=100):
for i in range(1, n+1):
print(fizzbuzz_without_mod(i))
Thanks, I blanked on rounding and floor.
Do you need to elif 5 and 3? You didn't for the default condition.
def fizzbuzz_without_mod(n):
if base_check(n, 15):
return 'FizzBuzz'
if base_check(n, 5):
return 'Buzz'
if base_check(n, 3):
return 'Fizz'
return n
No, what you have would work too. I wasn't really paying much attention to coding style though, was just showing an alternative to modulus, everything else would be the same as a typical solution
When you’re offering six figures for dev roles you will get many applicants that are not just unqualified (and frequently job hop before all of their poor decisions come back to bite them) but outright fraudulent. I’m talking genuine con artists who try and schmooze their way into a cushy programming job without any qualifications.
These bottom of the barrel five minute teasers aren’t a replacement for a genuine tech interview process but they’re great screeners that filter out those people.
This. As much as I used to hate coding challenges, once I started thinking about it from a company's perspective regarding the number of fraud artists I realized these challenges are a good filtering tool. They do filter out genuine devs too unfortunately, but it's an acceptable risk IMO if a company is getting a lot of job applications.
What genuine dev is filtered out by fizzbuzz though....
it revolves around a trite “gotcha” of whether or not the candidate knows of the modulus operator.
As an interviewer, I'm not even remotely interested in knowing if someone knows modulo. When I present Fizzbuzz, I outright give this part away before we even start. The reason is simple: I want to use Fizzbuzz to start a collaborative process. I want to have an imaginary teamwork session that doesn't depend on any kind of domain specific knowledge, that can be communicated and understood clearly, and lets me get a basic idea of how someone communicates while using basic programming tools and concepts.
It's beautifully compact and well-defined, yet (almost) infinitely optimizable or tweakable into whole new challenges. Notably, this article turns it into a TDD exercise, instead of testing the candidate on useless trivia.
The modulus operator isn't the “gotcha”. If the interviewee doesn't even know that a modulus operator exists, then they shouldn't get the job. Period. That's just basic language awareness. The real “gotcha” is how to handle numbers that are divisible by fifteen. If an interviewee can't figure out that that case should be handled before handling three or five, then how can the interviewer be sure that they can figure out other logic?
Edit: Removed a misplaced word
[deleted]
I've seen and used the modulus operator in production code countless times. In any case, you don't even need the modulus operator to implement Fizz Buzz. You can just make two counters that reset to zero when it would reach three or five.
[deleted]
If an interviewee doesn't stop to wonder if there's a way to check for divisibility and resorts to using a loop to do so, then I don't think that the interview needs to go any longer. It's one thing to not know how a particular language enables efficient divisibility checks (most commonly a modulus operator). It's another to not even consider that there would be one. If I'm the interviewer and the interviewee asks me what the operator or function is to check for divisibility, I will either tell them what it is or I'll tell them to take the pseudocode approach to it. It will make me want to further investigate their knowledge of the language, but if they know that there should be a way to efficiently check for divisibility, then that's sufficient in my eyes.
since it revolves around a trite "gotcha" of whether or not the candidate knows of the modulus operator.
Funny since you can easily solve fizzbuzz without the modulus operator by just implementing your own counter (or remainder function).
FizzBuzz inspired the proliferation Hackerrank/Leetcode interview questions, which have contentious reputation you described. Unmodified FizzBuzz acts as a dependable and efficient screening to continue an interview. A lot of people have missed that point in both directions, the reverse being the kneejerk opinion "FizzBuzz isn't enough to determine whether to hire a developer!".
I thought FizzBuzz was everyone's go-to example of a shitty tool for interviewing, since it revolves around a trite "gotcha"
The fuck are you talking about? Do you even know what fizzbuzz is?
since it revolves around a trite "gotcha" of whether or not the candidate knows of the modulus operator.
It's literally elementary school math, the minimum knowledge requirement is integer division.
FizzBuzz is one of the better tools I've ever seen for testing if a candidate can work through an actual programming problem. It's a toy one, but it requires the candidate to do a loop, some conditionals, and somewhere along the way they discover that they need to buffer their output.
While modulo can be exactly the kind of gotcha gimming that makes a question a really shitty one of exactly the sort you wisely decry, the rest of its traits make it very valuable. You would be sincerely shocked at how many junior candidates fall down when asked to reason their way through a loop and a conditional.
If you have encountered a better way of quickly assessing these same concerns, I think we'd all love to hear it.
You don't need to buffer the output, just put a newline at the end of the loop.
Tbh I would also expect a programmer to know how to write a modulus function if they didn't know about the operator. I would also be concerned if a non-junior didn't know about the operator
You don't even need the modulus operator to do fizbuzz, just use a conditional and a loop counter.
I don't think the post even mentions the modulus operator. It might be a good read for you if you do hiring.
I guess like any tool, FizzBuzz can be used well or abused.
now is it 15 or 30 or 45 or 60 years old.....
respect. they deserve it
If anyone should ever toss this at me in an interview, my response will be "I haven't worked in this field since 1982 without encountering modular arithmetic. Do you have any serious questions for me, or are you wasting my time?"
When I interview someone for a coding position, I ask them to tell me about some problem they're particularly proud of solving, and how they went about it. I have no problem figuring out if they're bullshitting me.
Context. this is asked to juniors, not people with several decades of verifiable experience.
nice
Every now and then you see an "enterprise edition" of Hello World or FizzBuzz or something trivial of the sort. Ones with tons of structure and indirections and every design pattern from every design pattern book the authors could get their hands on.
Had I stumbled on your repository by accident, instead of following the link from the blog, I would have considered it to be one of them.
I just went through a round of interviews and I had multiple different types of basic programming problems that weren’t difficult, but could be solved in multiple different ways. None were hard, but your answer could show how knowledgeable you were with the language and it’s concepts. So slightly more complex than fizzbuzz, but not by much. For example, printing Fibonacci sequence, or basic string manipulation problems.
These interviews were less stressful and it allowed me and the interviewer to have more discussion, whereas the FAANG interviews I did were just stressful short leetcode sessions with some interviewers that were very judgmental, that were clearly looking for a specific difficult solution.
FizzBuzz and reverse a string: the best way to find LOB devs that’s are writing 90% CRUD or reporting queries all fucking day. 🤣🤣🤣🤣🙄🙄🙄🙄
whilst fizbuzz is necessary, it is not enough
I agree with their premise that FizzBuzz is still a useful tool. I disagree with virtually everything else they said. I would never work for a company that thought interfaces, namespaces and object orientation were in any way appropriate to write FizzBuzz.
Who are these companies using fizzbuzz instead of leetcode medium for junior developers
Great tool for weeding out developers who forgot how to use the modulo operator or never use it, well done guys. Perfect example of how shit interviews are conducted.
1) What kind of ‘developer’ forgets how to use a basic operator?
2) There are several ways of solving the problem without using modulo.
It’s for weeding out people who don’t know how to program at all, before wasting valuable interview time on them.
1) What kind of ‘developer’ forgets how to use a basic operator?
Back in the day I had been programming for years for major cooporations (database, api, website stuff, etc) and I honestly forgot it even existed (or even existed in the language I was using) and probably would have failed the test. There's a lot of development that goes on that has nothing to do with non-integers. And if you use anything but plus and minus for money calculations you are in big trouble.
2) There are several ways of solving the problem without using modulo.
Sure, coming up with one of these doesn't put you at any disadvantage doing an interview? https://www.geeksforgeeks.org/program-to-find-remainder-without-using-modulo-or-operator/. And if you did, you'd still lose points from everybody that expects you to use %
To be fair, a reasonable interviewer would just tell you what the modular division operator is, if you tell them you forgot it. No one wants an interview to get hung up on one detail that you've spaced out forgotten. This is something interviewees should be more aware of: if your mind has just blanked on some key piece, just ask! Everyone is better off of your interviewer can just say "oh yeah, that's % in this language", and you can go on to demonstrate the skills they are looking for."
That said, if you have a reasonable interviewer, they probably aren't asking you to solve fizzbuzz.
To be fair, a reasonable interviewer would just tell you what the modular division operator is, if you tell them you forgot it.
So ask for something you didn't know even exists?
STOP. |
---|
It's a terrible interviewing technique perpetuating this "rite of passage" nonsense that I've been fighting against for over 40 years in this industry, predating this "fizzbuzz" trend.
Never ask a "programming quiz" under the guise of "just wanting to see how they think, and detecting analysis paralysis". It's not why you did this. You did this because you felt it was your right to make others squirm.
It's not a development scenario, it can't be: It's the stress of an interview. And all you're doing is making it worse and getting misleading information.
Instead provide mini-snippets printed out and ask them what they think of them. It's the conversation afterward that matters, never the right or wrong answer. I have some that allow me to dig into their interest and knowledge of all kinds of things, so long as they have the fundamental drive I'm looking for.
Not some nickle and dime "fizzbuzz" quiz that will never tell you anything.
EDIT: I see from my downvotes that there are a lot of bad interviewers out there.
... you do have to ask something in an interview, though. Whatever you ask, someone is going to claim that interviews are a stressful situation for them and that's why they couldn't answer well. It will sometimes be true. But if you stop asking anything that you're reasoning applies to, you may as well just not do the interview.
Did you read what I said? I have questions and snippets designed to spur on conversations that actually yield information.
Here's a C/C++ snippet to do just that:
long *a=0;
long *b=0;
a++;
b++; b++;
printf("%d %d %d\n", a, b, b-a);
I tell them calmly, "tell me what you think of this, it's on a plain 64 bit architecture. It's ok if you get it wrong."
Believe it or not, most did get it wrong, but that never matters.
The conversations I get from them (hopefully) explodes into all kinds of useful information. These are the kinds of things that I've received from them:
(etc.)
THAT is useful information. Not "fizzbuzz", and other rite-of-passage crap that makes interviewers feel superior.
Read the article, bro. There are LOTS of "programming quizzes" in interviews that are exactly what you describe, but FizzBuzz traditionally isn't one of them, and definitley not how the article presents it.
Well, I used to ask people to define C data structure to hold a single linked list of integers, and then to write a function that would print such a list backwards. I stole it from somebody who asked it of me. The three answers I know are (1) recursion, (2) the Deutsch-Waite-Schorr algorithm, which is my fave, and which hides the stack in the data structure by swizzling pointers then restoring them, and (3) representing all pointers in the list by edge. An edge here is the XOR of the (numeric value of) the address and its predecessor. The first uses an unbounded call stack. The second changes the list structure during the traversal, so it's not good for concurrent applications. The third is just insanity. I would have been happy with just the first, but I don't think I ever got it. If someone had given the second I would have been ecstatic. If someone had given the third, and realized that it had an advantage but was insane, I would have been transported to realms of light, and done the dance of joy.
After presenting this a few times and getting nothing I went to asking progressively simpler questions, until I ended at all6. This is a C function that takes a pointer to char and a length and tells you if all the characters in the string with the given length are equal to 6. I got some successes with this, but surprisingly few.
The point is, an interview question has to filter out the incompetent if it means anything. But since almost all, maybe all, of the candidates are incompetent, and you have to hire somebody to satisfy management, the questions can't be realistically hard. They just have to seem hard, which is exactly what FizzBuzz does.
Doesn’t sound like you’re a very good interviewer. If the criteria for the job mean they should be able to solve these things then maybe don’t hire someone that can’t.
If the job has nothing to do with your pet questions, maybe stop getting off on your superiority and find a question that does suit the job.
If the criteria for the job mean they should be able to solve these things then maybe don’t hire someone that can’t.
In what world would you want to work with a developer who can't come up with the solution of print a linked list in reverse order?
I mean this person is going to be on your team.
In what kind of company would a software engineer not be required to implement a recursion or a while loop? In what company would a software engineer not be required to apply basic but abstract notions and constructs of software engineering to solve arbitrary problems?
Re reverse printing a linked list, I’d give a recursion because that’s the only one I could come up on the spot … Then I’d probably insist on implementing a double linked list, or maybe implement the push procedure as inserting between the head and the “first” element (and rename it to avoid ambiguity [1])
It’s a bit weird to insist on a set data structure then specify a use case when interviewing people who’s main job it is to invent data structure supporting given use cases. I’ve read something somewhere that sums it up nicely: “smart data structures, dumb algorithms”
That being said I’m totally with you in general, and I can’t believe this kind of takes are so quickly downvoted … I can’t understand how implementing a linked list on top of their head is not a basic requirement for a software engineer.
[1] Or rename the data structure, I’m sure there’s a common name for this kind of lifo thing that’s not really a stack
Well, I used to ask people to define C data structure to hold a single linked list of integers, and then to write a function that would print such a list backwards
Iterate the list, write values to stack, print stack values while you're popping it. O(n) time complexity.
When you have so many skilled people getting rejected not because they aren't perfectly competent but rather because they aren't perfect, do you think this article is relevant or somehow not tone-deaf?
FizzBuzz is extremely simple, and OP talks about how an interviewer can read a candidate through it. They're not calling for more difficult interviews.
it is easy, but people who are defensive about fizzbuzz are those who failed at it lol.
Is this you?
I'm just saying like this article doesn't reflect reality and serves more as a masturbatory exercise for those in power to justify their position.
In the real world you have to do a lot more than fizz buzz with near perfect consistency to get a job.
If you can't throw down a fizzbuzz in a couple of minutes you shouldn't be hired to work as a software Dev, I'm sorry but that's the reality. Do an internship or two before you start applying without knowing the basics of coding.
When you have so many skilled people getting rejected not because they aren't perfectly competent
FizzBuzz can only filter out the utterly incompetent.
If you can't do a for loop you have no business applying for a job in this field.
Your argument is the equivalent of "Why should plumbers be expected to know how to use a wrench?! Do you know how many tools there are?"
There are lots of things that effective candidates won't be able to do. FizzBuzz shouldn't be one of them.
I can't go past any mention of FizzBuzz without linking to this epic implementation that can output the FizzBuzz strings at 55 GB/s, which is notably faster than main memory.
https://codegolf.stackexchange.com/questions/215216/high-throughput-fizz-buzz/236630#236630
And here I thought you were going to link to the highly structured FizzBuzz Java Enterprise edition.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
It's kinda outdated. Needs more Docker.
No, no... not Docker.
Kubernetes.
Deploy a FizzService and BuzzService separately. At least 3 instances in 3 different regions for fail-over purposes. Can't have our FizzBuzz go down if a meteor strike hits 2 Google Datacenters!
If the number of fizzbuzz instances is divisible by 5, print buzz.
How many kubernetes pods did you say you were using? ... FizzBuzz?
CTO:
“Next quarter we are going multi-cloud for more redundancy.
Seems like the website is down because of a DNS issue? Oops I forgot to renew the website domain and my card expired!”
Both
Docker for the containers, Kubernetes for the cluster of containers.
Every time I add it to the docker it complains com.somecompany.impl.hehe not found in java.library.path and I can’t seem to figure out why
I *just* created a FizzBuzz Docker edition, if you'd be interested in making improvements? https://github.com/koffiebaard/FizzBuzzDockerTypescript
Thanks but then I will have to switch to TS and rewrite all the java e2e tests again 😛
You have inspired me, good sir. Set my soul ablaze, burning with passion. I present to you, FizzBuzz using Docker, Docker-compose, Typescript and Bash: https://github.com/koffiebaard/FizzBuzzDockerTypescript
Ah yes, let me just go into FizzBuzzEnterpriseEdition/src/main/java/com/seriouscompany/business/java/fizzbuzz/packagenamingpackage/impl/factories/BuzzStrategyFactory.java
:(
Or the FizzBuzz in Tensorflow edition
Really puts the artificial in artificial intelligence.
OMG, do I laugh or cry?
I need a new job.
This python implementation https://replit.com/@Noyloy/FizzBuzzGenerator?v=1#main.py
Damn, just that page be crashing me cell browser
Mine too
Stop the loading of the page after the first paint. It seems to be loading JavaScript which highlights the linked answer which breaks due to the included code.
Depends on your RAM speed; dual channel DDR4-3600 is just as smidge faster (2 * 3600 * 8 = 57600 MB/s). Which of course doesn't make the achievement less insane.
Notably the OP (who provided the numbers for speed) does specify that he has 3600 MHz RAM.
Or if you have an Apple Silicon chip which has insane memory bandwidth in the hundreds of GB/sec to main memory. Since the bandwidth is shared between the GPU and CPU, it’s mostly for the benefit of GPU on M1 Max and Ultra - on those chips, it’s actually more bandwidth than the CPU can saturate. But people have clocked the CPU at over 100 GB/sec to main memory, I think.
But you'd have to design the program again. The mentioned program is build/written specifically for x86
Does memory speed/bandwidth enter into it, if you can get it to run in cache? (ignoring I/O needs)
Honestly I'm not sure, my hardware knowledge isn't deep enough. I should point out I didn't mean to imply the RAM must necessarily be faster than the program's output.
That suggests it could output at something along the lines of 16 bytes * 5.5 ish GHz = 88 GB/s on a high-end modern CPU, if not limited by the L2.
L2 write speed on the 5950X (that the codegolf OP used) in the AIDA64 benchmark is something like 2 TB/s though, so that sounds odd. L3 is also far faster than 88 GB/s, at about 1 TB/s (some results below, some above).
It's probably L2 latency rather than raw speed.
It's probably not bandwidth but latency limited. L2 access still includes a certain number of cycles of latency and I'd guess the reads are dependent on the writes so they can't be prefetched.
Cache? Hell, you could probably write something where the data never has to leave registers, and then it’s just keeping the main loop inside the instruction cache.
I think the “faster than main memory” comment is just a paraphrasing of what is mentioned in the explanation of the implementation: this program is faster than the
memcpy
command (and as it seems to scale up with faster CPUs, it’s possible that that holds true no matter how fast your RAM is as long as you’ve paired that RAM with an equally modern CPU).There's also this absolutely mind-boggling solution to FizzBuzz by Aphyr, well worth a read :)
https://aphyr.com/posts/353-rewriting-the-technical-interview
I almost... forgot about this one, but the seasons are cyclical, and so too is memory.
There are fucking wizards among us
sus
holy crap... that's something else :D Glad it's commented, was an interesting read!
Comment:
OP's reply:
What an absolute beast
The exercise states that you need to count from 1 to 100. This is an overkill.
You can't even begin to blink in the time it takes.
He said that he used AVX2 Assembly to get to that speed. If he used AVX-512, would result in a even faster result?
My sides