4 ms·
Have them write FizzBuzz (or something similar) give them 15 minutes to do it (more than enough time). Leave the room so they don't feel pressured. Offer them t
by 16s 16y ago
Have them write FizzBuzz (or something similar) give them 15 minutes to do it (more than enough time). Leave the room so they don't feel pressured. Offer them the OS and compiler of their choice. Ask them to write it in two or three languages, but only one is OK if they run out of time.
If they write something that compiles, give them a point. If it is well commented, give them another point. If the results are correct, give them another point. More than one language would get another point as would finishing early, etc.
It's pretty easy to weed-out people who cannot program by doing this and it doesn't take that long.
- patrickyeon 16y agoI sympathize with interviewers who would rather be there while the potential hire writes. Have them talk through what they're doing, why they're making choices, where they're worried about, etc so that you can get a feeling for how the person thinks. On another matter, I wouldn't be surprised if nobody worth their salt commented FizzBuzz; there's just not a level of complexity that you can better describe in English than in code.
- ericd 16y agoYeah, I'd think it was a bit silly if someone spent time commenting Fizzbuzz...
- hasenj 16y agoThe OP does mention that.
- tjarratt 16y agoWhat exactly would "well commented" mean for fizz buzz? One of my pet peeves are devs that comment insane things that should be obvious from reading the code. eg: #save the model and pass along a callback model.save(callback) If you were writing code that was as simple as fizz buzz, would you really write any comments at all?
- danielharan 16y agoExactly. That kind of comment is worse than useless. I'd rather see tests than comments.
- 16s 16y agoJust my opinion, but here are my comments to FizzBuzz. https://github.com/16s/FizzBuzz/blob/master/FizzBuzz.cpp https://github.com/16s/FizzBuzz/blob/master/FizzBuzz.cpp
- BSousa 16y agoA few notes on this: 1) and keyword for c++ ? It has been a while since I used C++ but it used to be &&. Did it change (I'm actually asking, not being sarcastic). 2) on the 'else if' parts, you only need to do one evaluation (the == part) since the first if tests for both % 3 and % 5 so no need to do != on % 3 or % 5 as you know it will never be true. 3) honestly, I think the comments make it worst. If a programmer doesn't know by just looking at the code what it does, no amount of comments will help him.
- Confusion 16y agoI don't think those comments are very helpful. I think a function-level comment would be much clearer. # Outputs 'Fizz' when +arg+ is divisible by 3, 'Buzz' when # it is divisible by 5 and 'FizzBuzz' when it is divisible # by both 3 and 5.
- 16s 16y agoThat's a matter of opinion. I always do this. Now there is no question what each conditional is intended to do. So if I make a mistake, you can clearly see from the conditional comment what I meant to do.