4 ms·
In general, any made up problem (i.e., with no real utility) is just a puzzle and I would prefer to walk out unless I do need the/a job. What a pity when inter
by alok-g 2y ago
In general, any made up problem (i.e., with no real utility) is just a puzzle and I would prefer to walk out unless I do need the/a job.
What a pity when interviewers can't even think of a real world problem for an interview. Most interviewers are like that.
No wonder, the industry has the candidates solve various coding problems, and once hired, all the candidates end up dealing with is company politics or other slowdowns. Not once in my career, a debate or an issue has happened because of the type of problems brought in interviews.
- bluGill 2y agoThe point of fizzbuzz is to prove you can program. There are a few ways to solve the problem but like real world all are not elegant and so you have to show how you handle such problems. Yet you can do the whole thing in less than an hour while real worle problems are expected to take a week or more. there is no point in all the additions the article had the first example is enough to show you are not lieing about your ability and that is what matters.
- alok-g 2y agoI agree about vanilla FizzBuzz. It's like a 'hello, world' of coding. My comment is about the several other rules brought in. I still do not see the rules added as a reflection of a real world problem. When I interview, I only give real world problems that can be solved within an interview setting. (PS: I won't disclose the interview problems here on open Internet.)
- macNchz 2y agoThere’s a spectrum of reasonableness with technical interview questions—the process described in this post is unreasonable, but I think plain old fizzbuzz is about as reasonable as it gets. It’s actually pretty “real world” if the candidate will be writing code in their job. It’s not a trick question nor does it require memorization or study to prepare. You’re not being given 20 minutes to solve something that requires knowledge of an algorithm that researchers worked on for decades that you’ve either practiced or will stumble through deriving from first principles—you’re writing a very simplistic function.
- sasmithjr 2y agoThe only thing that might be tricky about FizzBuzz is if the person doesn't know about the modulo operator. I can't remember the last time I used it in production code; I use it far more thinking about FizzBuzz than I do anywhere else.
- kijin 2y agoIf I didn't have the modulo operator, I would just check whether division resulted in a round number. I wouldn't rate someone who understands this basic principle lower than someone who just happens to know about the modulo operator. Bonus points if you use Python and demonstrate that you know the difference between the / operator and the // operator. That's much more useful in day-to-day work.
- teo_zero 2y agoIt's worth noting that the original FizzBuzz problem is not "given a number n, print..." but rather "for the first 100 natural numbers, print...". In this formulation, you don't need the modulo operator: you just initialize two counters at 3 and 5, respectively, decrement them each time, and react when either or both reach 0.
- alok-g 2y agoI agree about vanilla FizzBuzz. It's like a 'hello, world' of coding. My comment is about the several other rules brought in.
- xtracto 2y agoYou mean you had never had to traverse a 2D number array in spiral order to fix the 500 error in the site?
- quietbritishjim 2y agoThe person who invented FizzBuzz [1] did so because he was interviewing senior developers and a consistently high proportion could give really convincing explanations about their programming skills but, when it came down to it, could not program. And that doesn't just mean they were a bit rusty because they had been focusing on the big picture or managing people etc. Instead, they literally couldn't write a for loop but had jobs because they were good at interviews. That's why FizzBuzz is not done Google-style tree inversion exercise but basically just "please write a for loop". I wouldn't want to work a company that doesn't filter those idiots out. A full blown exercise with real code would be fine but a toy exercise would also totally do. [1] Imran Ghory. He wrote a blog post about it but it now seems to be down, but I know it was him and the reason why he did it because I was working with him at Bloomberg when he came up with it.
- whstl 2y agoI always give an option to either use some online REPL or local environment for FizzBuzz-like tests. It's always good to see how they deal with tools. But the number of candidates that can't run a script locally or on a website and ask if they can put inside their Rails project responding to some query is astounding. For Typescript positions I get better results.
- mark-r 2y agoI'm curious, when was the FizzBuzz problem invented? And how did it get publicized to the wider world? If you can come up with a URL the Internet Archive will probably have a copy.
- eieio 2y agoI was really curious reading this. Many years ago I read this blog post (from 2007!) by Jeff Atwood[1] that mentioned FizzBuzz, and I guess I had mentally filed away that Jeff Atwood invented FizzBuzz! But that is not true. Jeff's blog mentions Imran. Jeff's blog is still up, but Imran's isn't! However it is up on the internet archive, and Imran's post is also from 2007[2]. My sense is that Imran wrote a blog in January 2007 mentioning FizzBuzz and that Jeff's post in February 2007 is what made FizzBuzz the meme that it is today. This is probably very obvious to some readers of HN, but Jeff's blog (Coding Horror) has been around for a very long time and was one of the 'big' tech blogs back in that era of blogging (Jeff went on to, among other things, cofound Stack Overflow with Joel Spolsky a year after writing about FizzBuzz). Thanks for asking this - if someone asked me yesterday "who invented FizzBuzz?" I would have pretty confidently said "Jeff Atwood!" and I would have been totally wrong. For completenesses sake, the other really influential interview question blog I remember from this era is Steve Yegge's "five essential phone screen questions," which is even earlier (2005!)[3] I think interviewing discourse on message boards is tricky; folks have strong opinions, and if someone says "this is an essential question" and the question is hard for you, it's hard not to take that personally. In a past life I thought a lot about interviewing (here is a resource on interviewing I helped create for Jane Street back when I worked there[4]). I have never asked a FizzBuzz-style question, but I do think that "explicitly telling the candidate what you want and give them lots of help to get there" is really important. [1] https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/ [2] https://web.archive.org/web/20080405225407/http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/ https://web.archive.org/web/20080405225407/http://imranontec... [3] https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho... [4] https://www.youtube.com/watch?v=V8DGdPkBBxg https://www.youtube.com/watch?v=V8DGdPkBBxg
- xeromal 2y agoI had a set of interviews at a relatively large tech company and I was pretty pleased with the process. 1 tech interview which was progressively implementing a banking system. Final question involved threading 1 tech interview which involved building a banking system but it was more systems and database design. 1 business logic interview which was breaking down how credit card numbers worked and then asking me to do a code review 1 was just a personal fit interview. It took a lot of time but it all felt realistic and useful in the context of hiring someone.
- mock-possum 2y agoThat strikes me as odd - I see engineering as primarily a matter of puzzle-solving. Why should solving a puzzle not be a fair test of your abilities?
- alok-g 2y agoI see problem-solving as closer to engineering than puzzle-solving. The two may be overlapping but not quite.