Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re^2: Evil Interview Questions

by dpuu (Chaplain)
on Feb 10, 2008 at 03:43 UTC ( #667225=note: print w/replies, xml ) Need Help??

in reply to Re: Evil Interview Questions
in thread Evil Interview Questions

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.
Opinions my own; statements of fact may be in error.

Replies are listed 'Best First'.
Re^3: Evil Interview Questions
by Herkum (Parson) on Feb 10, 2008 at 20:38 UTC

    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



      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.


      _($_=" "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}

        BUSTED! You are right, I did not really go do good work for the object code (the problem of when you get into a hurry).

        However, I will stick to my guns with, design/process > technical knowledge.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://667225]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (2)
As of 2023-09-26 22:09 GMT
Find Nodes?
    Voting Booth?

    No recent polls found