Re: Re: Re^2: How to measure Perl skills?

You've reminded me of another useful skill:

Working with incomplete specifications.

I found that most requests were not meant literally, were ambiguous at the outset, or were given in some technical jargon [other than programming]. The ability to refine and negotiate the problem statement will finish projects (sooner), and be more satisfying for everyone.

So consider writing up your toy interview problems incompletely, with some inconsistencies and red herrings, just like in real life.

-QM
--
Quantum Mechanics: The dreams stuff is made of

Comment on Re: Re: Re^2: How to measure Perl skills?

Replies are listed 'Best First'.
Re: Re: Re: Re^2: How to measure Perl skills? by optimist (Beadle) on Mar 27, 2004 at 01:13 UTC
This is a really nice idea. Because actually, I think the skill you actually want to test for with this is not so much working with incomplete specifications, as much as recognizing them. I've known programmers who would get a project, think they understood what was required, and only after coding for a month realize there was some unspecified but very crucial detail, and how it actually needed to be worked out ended up invalidating a large chunk of what they'd already done. I guess the best way to get real world ambiguity would be to ask marketing to write up the test problems :-)	[reply]
Re^6: How to measure Perl skills? by QM (Parson) on Mar 28, 2004 at 02:24 UTC
To paraphrase: ...skill in recognizing incomplete specifications. Yes, ++...that's what I wanted to say (now that I've seen you say it). I guess the best way to get real world ambiguity would be to ask marketing to write up the test problems :-) Umm, you do want to actually hire someone, don't you? Or do you take demonic pleasure in seeing them run screaming from the building? ;-) BTW, see Dilbert of 21/Mar/2004. -QM -- Quantum Mechanics: The dreams stuff is made of	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks