Where my computer programmers/coders at?

Also does this question actually ever get asked and if so don't coders know it might be coming and are prepared to give a perceived best answer?

Never seen it before, never even heard of the game FizzBuzz. But yes, this is similar to what had been thrown at me when I started this madness ~7 years ago.

For the sake of diversity, here is a version in SQF. Took about a minute. It's in SQF, because I was just doing some modding for Arma 3. Didn't bother testing it, too lazy to start up Steam and Arma again.

I read about this on stackoverflow.com and used it to prep for SQL interviews. Of course they didn't ask it, they were too busy asking dumb questions like "describe an instance where you needed to convince a manager they were wrong and what was the result".

I got distracted by all the blinking lights. Where is he... the Death Star control room? Frankly, I'm mildly jealous that my work place does not look as awesome as that.

As to the test itself, it's way too basic. I would expect any beginning programmer to be able to write that with only a few hours training. You could make it slightly more challenging by adding some arbitrary restrictions like "don't use a for loop" (i.e. use recursion) but those are pointless academic wankery.

I actually wrote tests and hired a coder earlier this year. This test wouldn't have got you an interview, never mind a job.

You want to impress me? Start out by writing a test that verifies the output. I don't care if it works, I want to know you can PROVE it works. While you're at it, if I see a console.log or a printf or a cout or any kind of output in your algorithm (unless it's just there for debugging)... instant fail. Learn to separate presentation from logic.

Finally, if you REALLY want to impress me, make it scale. 100 numbers? Meaningless. 1 million? 194ms on my machine.
Write me a version that can do several billion and take advantage of whatever threads/cores are available,

Truthfully I don't know how to code, so I doubt I'll be asked this question...but...

=IF(AND(ROW()/3<>INT(ROW()/3),ROW()/5<>INT(ROW()/5)),ROW(),IF(ROW()/3=INT(ROW()/3),"Fizz","")&IF(ROW()/5=INT(ROW()/5),"Buzz",""))

I told you I didn't indent. Oh my. All one one line. Such elegance. I know you wouldn't hire me @ChaosEngine , but only because my 1337 Excel skills would render you totally obsolete. If you are prepared to listen I will teach you my ways.

I am mildly horrified, and you're absolutely right I wouldn't hire you as a coder.

I am, however, in awe of your excel hackery.

I don't really hold with the programming problem interview test thing. It's like interviewing for a writer and having them take a spelling test. At best, it will weed out people who really shouldn't have made it that far in the interview process to begin with. I think you get more by just having a friendly conversation about programming topics. Since you'd only have a test like this for an entry level position anyways, it should really just be taken as granted that they don't have much if any real-world programming skill and what's actually important is how quickly and effectively they will develop those skills when in a position to do so (along with all the usual personality "fit" stuff).

It's such a simple problem there is no "best" answer. But it would be very effective at weeding out people who know nothing about coding.

It's really not a question about optimization as writing things out to the console will probably be your biggest bottleneck (literally 10,000 times slower than the rest of the loop).

You'd be surprised at how many candidates that otherwise seem fine that reveal, when confronted with such a test, that they just. Cannot. Code.
*engineering

Adding video to channels (Engineering) - requested by Zawash.

Paused it and made a simple one in C# https://dotnetfiddle.net/3KMm3i

Tests like these are fine, as long as you don't put people on the spot in an interview - that's retarded, because no one works like that in real life. If you have like 20 minutes on a computer to do it, sure, but say writing it in hand or anything like that is a bit of a waste of time, and will eliminate people who would otherwise be much better than the "exam performers".

I was having some fun with this, trying to make the worst solution I could. This was definitely my ugliest that (I think) works (Python 3):

def fb3(m=100):
for oh in range(1, m + 1):
b = bin(oh % 0xf)[2:].zfill(4)
if b.count('1') % 2:
d, e, a, r = 5 * 0x605F05D * (3 ** 4) << 4, 0x30, 4, 0xf

else:
oh, d, e, a, r = 0, 0x1338098, 0x62, 5, 0x1f
if '00' in b or '11' in b:
oh = 0x514

if b[:2] == b[2:]:
oh = (oh * 0x2710 if oh else 0) + 0x960

yield ''.join(chr((d >> (a * int(c)) & r) + e) for c in str(oh))

[print(o) for o in fb3()]


Sift seems to be squashing the space even in code tags...

I'm in the strange position of just having finished a CS degree, with no professional experience as a programmer. Any advice on interviews or how to prepare for real work?

Also someone in the YouTube comments got it down to 1 line of JS, clever bastard :


for(i=0;i<1e2;console.log((++i%3?"":"Fizz")+(i%5?"":"Buzz")||i));


Ha! I often ask FizzBuzz in interviews if I have a hint that someone's blowing smoke. Often, they'll whiteboard a solution which is a giveaway that they've rehearsed this one (going straight to mod 15 instead of mucking around with 3 and 5 first), but that's no big deal. Where people usually utterly fail is when I ask them how they'd test it.

The vast majority of people end up saying that they'd run it and examine the output or something stupid; relatively few go straight to a unit test, and of those that do, even fewer immediately see that they have to refactor the simple solution to separate application from logic from presentation.

Ungh - coding in DotNetFiddle on a mobile phone is nigh-on impossible. Skipped the constructor injecting the dictionary. https://dotnetfiddle.net/Ij8vY5

Comment hidden because you are ignoring dag.(show it anyway)

I used to play this game with my english students in Japan, but we called it Bizz Buzz. You can do it with a bunch of people - and the extra rule is that Bizz or Buzz makes it change the direction of travel. It's actually a lot of fun.

Simple tests like this are meant to reveal how comfortable an applicant is at interpreting a problem and quickly translating it to code. It's analogous to how math tests in school required you to translate word problems to algebra. If someone struggles at this stage, they probably won't be a good coding hire. Or instead they might show some foresight into likely problems, gotchas, scalability, or testing.

I've been whiteboarded in a few interviews, and I've been hired based on a phone call. I don't know what the best method is, but I really hate the idea of "instant-fail" questions with a narrow "correct" answer. It's better to ask a few relatively easy, open-ended questions and see how comfortable the applicant is.

First piece of advice. "Clever" code is usually bad code. If I saw that line of code in a code review, I would have to have words with the programmer.

More seriously, it depends where you are. There area lot of jobs right now. If by no professional experience you mean no internship experience, that can make things harder but isn't a huge obstacle at all (the experience itself doesn't often count for much, it's really more of a "why didn't you get an internship?" sort of thing). A good way to start in that case is to look for contract-to-hire positions, possibly through a recruiting/placement agency (look for ones that specialize in engineers). They generally know what they are doing, and will work hard to find a good place for you and they are genuinely on your side. We like to use these where I work because you can hire someone on a three month or whatever contract, and if it doesn't work out, it's a relatively painless separation for everyone (ie, you weren't "fired" you just finished the term of your contract). It's easier to get your foot in the door through a CTH, and then you just have to diligently and prove yourself.

As for preparing for real work (the actual coding part), that's harder. Since you really don't know what you'll be doing, it's not easy to prepare for it. You really have to learn software engineering on the job, and companies hiring entry level talent know that. That said, if you have a particular field in mind, looking for *good* open source projects along the lines of what you want to do and studying the source is good idea. Exposure to real-world, non-academic code is very useful. Getting involved and maybe becoming a contributor is a great idea (and looks good on a resume and gives you something to talk about in an interview). Working on personal hobby projects is a good thing too (though not as good as working on larger projects with other people), which again, gives you something to talk about in an interview. Keep your hand in. Have something to talk about at your interviews.

There are some good books. "The Pragmatic Programmer" by Hunt/Thomas is an excellent general-purpose programming practices book (more about mindset and approach and good patterns than technical details), and I can't recommend it enough. There are some others, but they escape me at the moment. Google is probably your friend here. If you can find a second hand set of Knuth for a reasonable price, buy it up. It's not even remotely worth actually reading, but it looks good on a shelf.

Good luck and don't sweat it. You have a degree that makes you very employable. You'll find something that you like without a doubt. If you're lucky it will be your first job, if not, no big deal--move on to the next thing.

The only remotely effective interview I remember was when I was seeeking a student, part-time job. The boss asked a few questions, then told me "you'lll be workng with Michael, here he is, fix something", and we commenced to debug some problem he was having. Sadly, last time I got a job without actually knowing someone ahead of time.

Makes me wonder, what is a typical interview question for a school principal, or a plumber, or a Walmart greeeter ....

Oh shit, you're right. The "else if" should just be an "if". I'm a failure to my people.

/codes wrists.