in reply to Evil Interview Questions

I hate these type of technical questions... I find they are just dumb!

NO!

There is more important skills than knowing the subtle differences between coding implementations( this is especially true when you have an interpreter to check your work).

What makes a good programmer? How about,

To me these are harder to evaluate but drastically more important. It is amazing the number of problems you can avoid with a good approach. A deep knowledge of a languages quirks and behaviors will not take you very far.

I have had horrible interviews with people that decide that knowing this intimate behavior is considered a sign of a good programmer.

These people also end up writing 600 line while() loops. that no one can understand. So I have little respect for individuals who rely upon these sort of evaluations.

Replies are listed 'Best First'.
Re^2: Evil Interview Questions
by dpuu (Chaplain) on Feb 10, 2008 at 03:43 UTC
    Personally, I like to hire the type of person who finds these types of quiz to be fun. It doesn't matter if they know the answer, it's the attitude that matters. A person who loves programming sufficiently to care about these irrelevancies is likely to be a good programmer. The sort of person who views such questions as being about right and wrong answers is probably not an "-Ofun" type of person. The best way to determine a person's attitude towards this type of quiz is to ask a couple of questions. The ideal candidate will probably have one or two of their own to throw back at me. At that point the interview becomes fun, because I know I'm going to recommend to hire.
    --Dave
    Opinions my own; statements of fact may be in error.

      I rarely found these types of question fun, your right the attitude matters, but the people who use these questions are not looking for a good programmer, they are looking for a technical programmer which is not the same thing. It is easier to identify a persons technical attributes than there qualities as a good programmer. Take this example object;

      package Foo::Bar; sub new { my $class = shift; my %args = @_; my $self = {}; bless $self, $class; $self->{_name} = $args{name} if $args{name}; return $self; } sub name { my $self = shift; return $self->{_name}; }

      This is the implementation of the object.

      my $bar = Foo::Bar->new( name => 'Bob Lambert' ); print "Name of my object " . $bar->name . "\n"; # method call print "Name from my hash " . $bar->{_name} . "\n"; # hash key

      Can you see the problem? Technically they are both correct, but one of these basically creates havoc that cannot be overcome by intimate knowledge of the language.

      The print statements display the same value because they access the same data. The call to access the data directly via the hash reference forces it to be a static implementation. It creates maintenance headaches and you cannot update your object without breaking code.

      Focusing on technical trivia is not a replacement for development/design process.

      Update: I did sloppy work on my object code (pointed out by shmem and I fixed it to reflect the problems he pointed out)

        Can you see the problem?
        Well, some... 1 not so, and 5 serious problems:
        package Foo::Bar; # (1) strict, warnings? sub new { my %args = shift; # (2) first argument is class name. # (3) shift? really? even if @_, then # odd number of elements in hash? my $self; # (4) uninitialized scalar... bless $self; # ... can't be blessed (not a reference) # (5) not using 2-arg-bless? inheritance? if ($args{name}) { $self->{_name} } # (6) $self->{_name} /what/ ? return $self; } sub name { my $self = shift; return $self->{_name}; }

        Granted, your object implementation is just a quickly-whipped-up example. Don't let the heat of the discussion lend you to write bad code!

        But anyways -

        Technically they are both correct, but one of these basically creates havoc that cannot be overcome by intimate knowledge of the language.

        Oh, it can be overcome - if you use that knowledge to implement the object in a good way in the first place:

        package Foo::Bar; use Alter ego => {}; use strict; use warnings; sub new { my $class = shift; @_ % 2 and die "odd number of elements in \@_, aborted"; my %args = @_; my $self = \do { my $obj }; bless $self, $class; ego($self)->{_name} = $args{name} if $args{name}; return $self; } sub name { my $self = shift; defined( ego $self) or die "not a valid object"; return ego($self)->{_name} } package main; my $bar = Foo::Bar->new( name => 'Bob Lambert' ); print "Name of my object " . $bar->name . "\n"; # method call print "Name from my hash " . $bar->{_name} . "\n"; # hash key __END__ Name of my object Bob Lambert Not a HASH reference at - line 23.

        No room for mistakes - the $bar object is just an empty scalar reference. It is better to not create the pits than avoiding the pitfalls. Or as a friend of mine uses to say

        mejor la seguridad que la policia.

        better is security than the police

        ;-)

        update:

        The validity of hash key lookup for object attributes depends entirely on the purpose and declared interface of the object - its contract. Hash lookups are much faster than method calls, and there might be a speed concern.

        But back to the discussion - these sort of interview questions make sense, to test the depth of detail knowledge. If they are the only ones, the answers will reveal only a small part of the person interviewed. It certainly is short-sighted to only rely upon, or over-estimate, the technical quiz.

        --shmem

        _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                      /\_¯/(q    /
        ----------------------------  \__(m.====·.(_("always off the crowd"))."·
        ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}