On Tue, Oct 07, 2008 at 05:33:43PM -0400, G. Matthew Rice wrote:
> LMAO. To both of you. Len, I think that Etienne was being facetious here.
I suspect so, but at the same time I think it is a very valid point.
> There's definitely a balance here but I still don't agree with a pure 'no
> option testing' ideology.
I don't really consider certifications worth anything. Probably takes
it too far in the other extreme. I would consider a hands on test the
most useful, but even there it's a simulated set of problems. When it
comes down to it you have to deal with real problems, without predefined
solutions in many cases, and occationally without solutions (which isn't
good), working together with other people. Do any tests do that?
perhaps I am much to cynical about certifications, but so far the ones I
have seen have been rather far from reality.
> Otherwise, the job interviews I give would degrade to "here is 'man man' and
> that's all you get...now build me a web server farm". And just wait to see
> how long he takes.
If you are looking to hire someone that knows how to build web server
farm's, that really doesn't sound that bad.
> Knowing options that are used all the time is a way to show experience. If
> you have to continually look up the 'c' option for tar or the -l option to
> ls, you just haven't been around the block enough times.
But sometimes there are more than one option and you use one while
someone else uses another? Especially cases of long options versus
short option names on many commands. For some of them I have no idea
what the long option is, I just know the short one I always use.
> That said, don't blow this out of perspective. These types of questions are
> getting rarer as we improve the tests overall.
Which is good. Of course to some extent the policy of not discussing
questions makes it hard to elliminate that kind of problem question. I
realize entirely why discussing questions isn't feasible, but that
doesn't detract from the problem it also question.
> BTW, the first question on a Perl test that we used to give prospective
> senior level Perl OO developers (not CGI hackers) was:
>
> # 1. What does this statement do?
>
> bless { _h => 'Hi' }, 'Hi';
>
> It was difficult to find someone that could answer that sensibly (or at all).
I sure can't, but I don't do perl OO. I do perl, but not that.
> I would argue that this question is akin a ls -lr question. The -r comes
> from the { ... } part which does obfuscate (but not really).
I can see some people never having a need for -r when using ls. I do
use ls -lrt way too often to not know what it does, along with the ls
-lrS of course.
--
Len Sorensen
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
