Board index » delphi » Re: Gauging interview tests difficulty...

2007-06-30 10:09:33 PM
delphi258
On Fri, 29 Jun 2007 10:29:09 +0200, Eric Grange
<XXXX@XXXXX.COM>writes:
day at work, but in test 1, wouldn't the correct answer be that it
(appears) to generate a random number less than a? I mean, I don't see
how the range starts at zero.
Other than that... I didn't top it off, but not that far from. Then
again I have been coding more than 1 year ;)
Comparing it to other's I know who have been coding for a year or a
couple... If they're good coders they should get by pretty well,
assuming they understood the task properly. For instance, I didn't
pick up that I was supposed to comment on the ??? in Test2, I thought
it was a "generic" type thing.
Cheers
- Asbjørn
 

organize new (or old) code well if you don't have basic knowledge of standard
algorithms and datastructures. If not their names, at least enough to
communicate about them in more than borborygms or long paraphrases :)
IME it makes all the difference between a developper that'll write his code
once, and that code will require little bugfixing, optimization or refactoring,
and a developper that'll get things done (maybe) after going through many
structural and algorithmic hoops (often without noticing them), producing code
that will have near endless potential for bugfixing, optimization and refactoring.
To give an analogy, it would be like the difference between a master locksmith
and a barbarian with an axe: both can open doors, and sometimes the barbarian
will even get the door opened faster, however the end result will be quite
different :)
Eric
 

"Brian Moelk" <XXXX@XXXXX.COM>writes
To Eric: I have used (for years) a different approach. If it is a junior
position for which I am hiring where the onus is on internal management to
train the new developer up, IOW to develop the developer, I use the
interview to guage the applicants basic fitness for the job scenario. I try
to assess how well the apllicant has learned how to learn... I then use a
probationary period to guage the new hire's ability to come to grips with
the tasks assigned to him/her. Some basic programming test *might* be
useful, in these cases, but I doubt it. If the tests are basic enough, then
an intelligent applicant can be quickly taught what they need to get the job
done the way you want it done. E.g. what if you are hiring a Java guy (took
a few courses in college from which he has just graduated) for a junior
Delphi position?
If said applicant has learned how to learn then I should be able to assess
that by revealing unique details about my own (corporate) problem domain in
order to see how well the applicant processes new information and then
applies that information in some significant and useful fashion within the
interviews. IOW, give the applicant a problem to solve based on information
you have provided in the interview. Since you've provided the cognitive
input, you should be able to guage the *practical* output. Don't give the
applicant some geeked out "algorithm" that you can solve and they can't. It
doesn't prove much.
For more senior positions, I don't hire anyone without a substantial resume.
As such, I will grill an applicant on the accomplishments itemized in his
resume. (I have found more than one fake with this simple process). Where
possible I will ask to see actual code written by the applicant on previous
projects (there is usually some "pet project" that said applicant has poured
his/her own time into for which they have the authority to show some of
their code. Moreover they should be proud to do so). This is more valuable
to me, than some coding test throw at the applicant; and allows you to
analyze a true sample of their work while asking them in-depth questions
about everything from coding style and design, to choice of algorithms.
Address your hiring criteria in a straight-forward manner. Don't throw some
geeked out algorithm at him/her, and tell him/her to speak intelligently
about it, without first telling the applicant exactly what your agenda is
and giving them as much context as possible to give you an intelligent and
thoughtful response. For instance, in other parts of this thread you
mention "implementation quality" is a very important issue for you. In that
case, base a whole segment of your interview soley on this theme. Address
it directly, e.g. "Implementation Quality is a vital concern of our's for
this programming position. Can you talk about this issue in reference to
you own resume and can you show me examples from your previous projects
where you feel the implementation quality is good in your opinion."
IMO, for senior positions, you should be analyzing what the applicant has
done in the past in order to assess what they can do for you in the future.
So allow the applicant to speak from his/her strengths and alow yourself to
assess those strengths in their own terms and on their own merits without
biasing the assessment with a trumped-up "test" entirely orientated to your
own frame-of-mind and personal circumstance. The problem with this is that
you have most likely constucted a test that *you* would pass mainly because
you are entirely "dialled in" to the context of the test...
Beware of arbitrary tests to divine by indirection what can be more easily
assessed by openness ("here's what we care about, please talk about it"),
directness ("Can you show me example in your past career that address our
primary concerns for this position"), and your own talent to explain your
problem domain in a way that allows the applicant to respond with insightful
"solutions" during the interview ("In the billing dept. we have a
problematic web application that slows down at 4:00 PM every day, we've
traced the activity at this time down to these five things: ...").
Hiring isn't easy, and results can only be driven by the available pool of
talent... As such, it does you know good culling an already limited
reservoir of resources by filters that don't really enhance your chances of
success.
But the truth is: At a given point in time in which your are hiring - a
given talent pool may contain all "losers" in which case you will fail (by
degree, all losers are not created equal). A given talent pool may contain
all "winners" in which case you will succeed (by degree). A given talent pool
may have all losers and one winner, in which case your own talent to pick
the winner will become a significant factor in your own success.
Good luck.
-d
guid: E14DF133-9F8D-437A-BB26-BFB8BE4865DF
 

"ckd" <XXXX@XXXXX.COM>writes
<g>
To be serious, this might not be a bad test at all. One might be able to
flesh out a hiring strategy around it, depending on the job.
-d
 

"Brad White" <XXXX@XXXXX.COM>writes
-d
 

Hi Tony,
tony writes:
are strict laws governing what you may put into a hiring contract. Putting
something illegal in there will usually void that clause and replace it
with the general regulation in the law. There is though usually some trial
time (3 to 6 months) during which a contract can be annulled on a daily
basis.
MfG
twm
 

Hi Eric,
Eric Grange writes:
one letter variables. ;-) K should have been called "MinIdx" or "IdxOfMin".
Actually there isn't any sorting function in the whole Delphi RTL/VCL that
I am aware of. They are always part of a container object and cannot be
used outside. I call that bad design.
MfG
twm
 

A couple of observations:
A good programmer probably hasn't written anything this obfuscated
(hopefully), so his/her ability to make heads or tails out of it may not say
much. I spent two years modifying systems written much like this and
cleaning them up and making them more readable. Not sure I'd have done
so well having to try to do it on the spot during an interview.
Second, I have found no relationship between how technical people interview
and potential for success on the job. There are lots of people who are going
to be overly nervous during the job process. You may be overlooking some
really great people with a test like this.
"Eric Grange" <XXXX@XXXXX.COM>writes

Makes me think of another with a similar complexity that could make a
fair option too: population count, which adds the need for a result
datastructure.
it's also named in the help), so as far as Delphi developpers go, if
they ever dabbled in the source, they'll have encountered it.
It was kept as it seems to still be one of the most widespread (and
misused), and you can recognize a sort even you don't understand
everything (that isn't so much the case with a full blown mergesort or
radix f.i.).
Eric
 

found) and haven't dabbled much in GLScene lately.
applicants say they could become comfortable with it (whether or not
they are), very very few people are ready to antagonize their
interviewer over it.
When you show some code witout saying what it is or where it comes from,
it gives them the opportunity to speak their mind (or not, which is
telling in itself). That the first snippet could be from the DailyWTF is
intended as a hint that the code being shown to them can be heavily
criticized.
Eric
 

stomach.
Eric
 

TStrings itself or being overridable, and TObjectList's comparison
function involves pointers rather than objects, etc.
However, the biggest trouble with the RTL/VCL sorts, being
QuickSort-based, are risky/unusable if you have many elements that could
be in a near-sorted order.
Eric
 

Dennis Landi brought next idea :
Thanks,
Brad.