Developer Applicant Suitability

Well if you want efficiency, you might as well hardcode the output as it's a constant

Elfman wrote: »

For cnt = 0 To 100
printme = ""
printme &= IIf(i Mod 3 = 0, "FIZZ", "")
printme &= IIf(i Mod 5 = 0, "BUZZ", "")
Console.WriteLine(printme & " - " & cnt)
Next

I like this implementation but if people can't create a single for loop with 2/3 if else statements surely that's a problem.

Elfman wrote: »

For cnt = 0 To 100
printme = ""
printme &= IIf(i Mod 3 = 0, "FIZZ", "")
printme &= IIf(i Mod 5 = 0, "BUZZ", "")
Console.WriteLine(printme & " - " & cnt)
Next

You're not supposed to print the number if "Fizz" or "buzz" or "fizzbuzz" is being printed...

And in Perl (I like these tests - any more!?)

my @numbers = (1..100);
        foreach my $i (@numbers)
          {
            my $res3 = $i/3;
            my $res5 = $i/5;
                if($res3 =~ /^\d+$/ && $res5 =~ /^\d+$/) {print "FizzBuzz for $i\n"}
                    elsif($res3 =~ /^\d+$/)
                     {print "Fizz for $i\n";}
                    elsif($res5 =~/^\d+$/)
                    {print "Buzz for $i\n"}
                    else {print "$i\n"}
}

Sparks wrote: »

Just to be really annoying, can I give y'all the second part of the FizzBuzz test (the one that really counts at any company that does any sort of real product)?

Here it is : Document your solution.

You'd be horrified at how many grads can't do this, but honestly, every time someone on here asks "what programming language should I study to boost my career", the very first one that always jumps to mind is English. Because if you don't document it, you'll probably come across it in a Coding Horrors thread or WTF post someday...

Out of curiosity, how would you document the solution? It's such as simple task, the most I would document is the why not the how. And for FizzBuzz, there is no why except for because you were asked too.

Why would you want to document the modulus operator, when the language reference already does?

On a similar line to the FizzBuzz test, but also showing a bit of an ability to think outside the box, I saw an interview question online yesterday that went something along the lines of.

Write a short function in the language of your choice. When given one integer, it must return the square of that number. You may NOT use the multiplication operator or any math functions that your language may provide.

There are a couple of ways to do this.

My point is that, in addition to its vagueness, I don't really like the question.


The point of FizzBizz is to be the most casual filter possible: ask something that anyone who can code *has* to be able to do.


This question is going to be off the beaten track for a lot of general developers. Like, when would they ever not have a multiply operator?


Do they want the candidate to make a binary multiplier using bitwise operations in C? That's kind of error prone, and a PITA thing to do in an interview. It demonstrates a detailed knowledge of bitwise operations, if that's a particularly desirable quality; great question for someone working with embedded systems, but I'm not sure you need that in a general developer these days.


I can think of a load of other stupid ways to solve the problem, too, using the division operator; building lookup tables; defining a language so trivial the only numbers in it are 0 and 1; etc.

Maybe there's some solution I've overlooked that they are looking for; if so, my point stands; I'm not a fan of 'ah-ha' questions.

The quick and dirty approach that I would have taken to the question myself would have been:

[PHP]
function squareMe($x) {
return $x / (1/$x);
}
[/PHP]

It's a stupid gimmick question. You can't use multiplication but you can use everything else? Division is just multiplication by the inverse so it's stupid. Compiler would turn divide into inverse multiply anyway -.-

Most likely they expect the candidate to use bitwise operations or something.

I interviewed for a position in London last summer, HR drone placed a sheet fully of the usual stupid questions in front of me and told me I had an hour to complete the test. Questions were stuff like "write heapsort" and so on. I last studied that stuff in the 90s.... No I cannot remember heapsort!! Yeah you gotta make a "heapify" function lalala. Anyway, I just got up and said "Thank you for your time", and left. This is not how you interview a developer with 10+ years of experience -.-

Contrast to next interview (for financial consultancy). Phone interview first, guys described the specific problem they wanted to hire someone to solve. I flew over for face-to-face interview, brought laptop with demo of a rough solution to what they wanted. Wallop -> instantly employed. No HR drones in sight.

Yeah but it's very vague. They mean functions like pow(x, 2) I suppose. + - etc are operators not functions.

srsly78 wrote: »

Contrast to next interview (for financial consultancy). Phone interview first, guys described the specific problem they wanted to hire someone to solve. I flew over for face-to-face interview, brought laptop with demo of a rough solution to what they wanted. Wallop -> instantly employed. No HR drones in sight.

Super. Something I always recommend to people after reading this book years ago: do the job in the interview. Won't work for everyone, but if you've enough experience and confidence to steer the interview to that, it will pay off hugely.

That doesn't reverse an array, it prints an array in reverse.

C:

int * rev(int * arr, int len)
{
   int * res = malloc(sizeof(int)*len);
   int * temp = res;
   while(len--)
      *(temp++) = arr[len];

   return res;
}

Haskell:

rev = foldl (flip (:)) []

Well, it's done easily enough in place:

void rev2(int * arr, int len)
{
   len--;
   int i;
   for(i = 0; len > i ; len--, i++)
   {
      swap(&arr[len], &arr[i]);
   }
}

swap() could be:

void swap(int * x, int * y)
{
   int temp = *x;
   *x = *y;
   *y = temp;
}

or maybe...

void swap(int * x, int * y)
{
   asm volatile ("xchgl %0, %1;\n"
                        :"=r"(*x), "=r"(*y)
                        :"0"(*x), "1"(*y));
}

etc.

Yeah but it's very vague. They mean functions like pow(x, 2) I suppose. + - etc are operators not functions.

Aha, but now you have a problem. Given that you are writing it out and handing it to the interviewer and not discussing it, you have to trust the interviewer to know the difference.