Pre-employment problem solving ability tests

[RevDisk]

seq 100|perl -ne'$_%5?$_%3?print:say"Fizz":$_%3?say"Buzz":say"FizzBuzz"'

Best I could do on lunch. You have to use perl 5.10 to get the 'say' to work; it works the same with 'print"foo\n"' it's just longer.

perl-5.10.1-131.el6_4.x86_64 already installed and latest version
[root@fwireport01 reports]# seq 100|perl -ne'$_%5?$_%3?print:say"Fizz":$_%3?say"Buzz":say"FizzBuzz"'
String found where operator expected at -e line 1, near "say"Fizz""
String found where operator expected at -e line 1, near "say"Buzz""
String found where operator expected at -e line 1, near "say"FizzBuzz""
syntax error at -e line 1, near "say"Fizz""
Execution of -e aborted due to compilation errors.


seq 100|perl -ne'if ($_%3==0){print( "Fizz")};if ($_%5==0){print( "Buzz")};if(($_%3 ne 0)and($_%5 ne 0)){print($_)};print("\n");'

zahc is still cooler than me. 

[cosine]

Personal stats for using Perl:
+10 geek cred
-100 for cryptic code

 

[Tallpine]

Personal stats for using Perl:
+10 geek cred
-100 for cryptic code

 

It's more important that somebody can figure it out two or five or ten years later after you've moved on to greener pastures.

[zahc]

perl-5.10.1-131.el6_4.x86_64 already installed and latest version
[root@fwireport01 reports]# seq 100|perl -ne'$_%5?$_%3?print:say"Fizz":$_%3?say"Buzz":say"FizzBuzz"'
String found where operator expected at -e line 1, near "say"Fizz""
String found where operator expected at -e line 1, near "say"Buzz""
String found where operator expected at -e line 1, near "say"FizzBuzz""
syntax error at -e line 1, near "say"Fizz""
Execution of -e aborted due to compilation errors.

Having 5.10 installed is irrelevant; perl will not compile 5.10 features like 'say' unless you tweak your perl to be quiet. You can also prepend 'use v5.10;'. I have no idea why this is; I think the perl developers deliberately make it easy to get new bug fixes and hard to use new incompatible features.

[Jim147]

I always found the best way to test new hires was to bug stuff with common problems and see how they went about solving them.

Fixing it wasn't as important as how. Some injunears really like to over think and over spend to fix a simple problem.

jim

[Tallpine]

I always found the best way to test new hires was to bug stuff with common problems and see how they went about solving them.

Fixing it wasn't as important as how. Some injunears really like to over think and over spend to fix a simple problem.

jim

The first rule of fixing code bugs is to NOT introduce ten new ones 

[RevDisk]

The first rule of fixing code bugs is to NOT introduce ten new ones 

Unless you are paid to remove bugs.

And the first rule of Indian coding is "if it compiles, ship it". Applies to bugs as well.

[Tallpine]

Unless you are paid to remove bugs.

And the first rule of Indian coding is "if it compiles, ship it". Applies to bugs as well.

Yeah 

I used to like this business, back when I wrote code myself.  Trying to ride herd on a bunch of morons is frustrating.

[cordex]

And the first rule of Indian coding is "if it compiles, ship it". Applies to bugs as well.

They check to see if it compiles these days?

[Marnoot]

They check to see if it compiles these days?

We enforce it on our Indian contractors via gated check-in on the build and source-control servers. It won't let them check in their code if it doesn't compile. Unfortunately, as discussed, sometimes compiling is about all the code does that's good.