4 ms·

> I'll go a step further and say that if you're the kind of person that takes FizzBuzz as a personal insult, then you should be able to write it out in 60 secon

by donw 10y ago

> I'll go a step further and say that if you're the kind of person that takes FizzBuzz as a personal insult, then you should be able to write it out in 60 seconds max, and move on with the interview. I see your step, and raise you. :) Asking a developer to spend five minutes to write a trivial problem is not an insult. Somebody that takes this as such is probably not going to be the type of person I, or my team, will want to work with, and we can end the interview process there. I can totally understand balking at a one-day "homework problem" given out as part of the interview. Not because this is an insult, but because it gives nothing to the candidate. An on-site or remote "test drive" where they spend a day working with the team is fine in my book, because that experience is valuable to the candidate in answering the question of "will I be happy and productive here?" A company that demands a full- or half-day of time in exchange for nothing, not even information, probably does not value its employees much. My personal policy is that the interview process can consume no more than one day of a candidate's time in total, plus an hour for a phone screen, and that at the end of the interview, both parties can make an informed decision as to whether or not they want to continue. But five minutes to complete a trivial programming test? Writing this post took about that amount of time.

falcolas 10y ago
Personally, I think FizzBuzz is stupid as hell, but I understand its role as an initial filter. My real frustration with FizzBuzz rises from getting this "test" at the in-person interview. Multiple times. Do it in a live coding session as part of the phone screening, and make those results available to all interviewers. Reserve the limited time that is available for in-person interviews for real questions, not filters. Or think of a better filter question than FizzBuzz. One great example for someone who claims to be a Python programmer - fix this: def foo(x, bar=[]): bar.append(x) return bar That lets me know that you as the interviewer also know more than FizzBuzz.
- dTal 10y ago
  Well, I guess I just failed your interview. As that's perfectly valid Python that does exactly what I expect, what's "wrong" with it?
  - falcolas 10y ago
    Run `foo('a')` a few times in a row - you'll start seeing that "bar" keep state unexpectedly. It's a fairly classic Python gotcha - the mutable object is retained across calls when the default is used. >>> def foo(a, bar=[]): ... bar.append(a) ... return bar ... >>> foo('a') ['a'] >>> foo('a') ['a', 'a'] >>> foo('a') ['a', 'a', 'a'] >>> foo('a') ['a', 'a', 'a', 'a'] EDIT: Having the program output as part of the problem would probably help. :D
    - dTal 10y ago
      What. The. Ass. Okay, minus another couple points to me for not testing each case more than once, and yes, if you're going to present syntactically valid code and ask people to "fix" it you should probably state what it's supposed to do, but aside from all that... the hell? Okay, having Googled the logic behind this behaviour, I still think it's stupid. My next question is - is being aware of little language gotchas like this really so important? It really bugs me that about all I'm good for in the employment market is making computers do stuff, but I'll never pass an "esoteric language behaviour test" in anything - my tastes are too diverse and I've never gone "all-in" on anything. But I don't think it gets in the way too much - you keep your changes modular and test frequently, and if it doesn't work right you figure out why. Which corners of the language you tend to bump into depends very much on your coding style (for instance I try hard not to mutate things which is possibly why I've not hit this before), so even with a brand new language you should be able to get going pretty quickly. Surely I'm not useless?
      - falcolas 10y ago
        > What. The. Ass. Yeah. Python. A fun little wart. > is being aware of little language gotchas like this really so important Somewhat ironically, our conversation here highlights why it is important. If you initially tested these three lines of code to your satisfaction and didn't find the bug, how could you assume that your unit tests would catch the bug? > Surely I'm not useless? I would hardly think you're useless, but it does show a lack of experience with the Python language. On the other hand, your most recent response also shows a capacity for looking up and identifying the language WTF and how to fix it, skills which are important in lieu of experience.

by donw 10y ago

falcolas 10y ago

Personally, I think FizzBuzz is stupid as hell, but I understand its role as an initial filter. My real frustration with FizzBuzz rises from getting this "test" at the in-person interview. Multiple times. Do it in a live coding session as part of the phone screening, and make those results available to all interviewers. Reserve the limited time that is available for in-person interviews for real questions, not filters. Or think of a better filter question than FizzBuzz. One great example for someone who claims to be a Python programmer - fix this: def foo(x, bar=[]): bar.append(x) return bar That lets me know that you as the interviewer also know more than FizzBuzz.

dTal 10y ago
Well, I guess I just failed your interview. As that's perfectly valid Python that does exactly what I expect, what's "wrong" with it?
- falcolas 10y ago
  Run `foo('a')` a few times in a row - you'll start seeing that "bar" keep state unexpectedly. It's a fairly classic Python gotcha - the mutable object is retained across calls when the default is used. >>> def foo(a, bar=[]): ... bar.append(a) ... return bar ... >>> foo('a') ['a'] >>> foo('a') ['a', 'a'] >>> foo('a') ['a', 'a', 'a'] >>> foo('a') ['a', 'a', 'a', 'a'] EDIT: Having the program output as part of the problem would probably help. :D
  - dTal 10y ago
    What. The. Ass. Okay, minus another couple points to me for not testing each case more than once, and yes, if you're going to present syntactically valid code and ask people to "fix" it you should probably state what it's supposed to do, but aside from all that... the hell? Okay, having Googled the logic behind this behaviour, I still think it's stupid. My next question is - is being aware of little language gotchas like this really so important? It really bugs me that about all I'm good for in the employment market is making computers do stuff, but I'll never pass an "esoteric language behaviour test" in anything - my tastes are too diverse and I've never gone "all-in" on anything. But I don't think it gets in the way too much - you keep your changes modular and test frequently, and if it doesn't work right you figure out why. Which corners of the language you tend to bump into depends very much on your coding style (for instance I try hard not to mutate things which is possibly why I've not hit this before), so even with a brand new language you should be able to get going pretty quickly. Surely I'm not useless?
    - falcolas 10y ago
      > What. The. Ass. Yeah. Python. A fun little wart. > is being aware of little language gotchas like this really so important Somewhat ironically, our conversation here highlights why it is important. If you initially tested these three lines of code to your satisfaction and didn't find the bug, how could you assume that your unit tests would catch the bug? > Surely I'm not useless? I would hardly think you're useless, but it does show a lack of experience with the Python language. On the other hand, your most recent response also shows a capacity for looking up and identifying the language WTF and how to fix it, skills which are important in lieu of experience.