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

## Re: Gauging interview tests difficulty...

2007-06-29 09:02:36 PM
delphi19
"Eric Grange" <XXXX@XXXXX.COM>writes
##### Quote
We've been making some interviews lately and gave them a few
coding/algorithmic tests, whose difficulty I'd like to gauge, and this
newsgroup being full of Delphi old timers... ;)
Eric:
First I don't know you so don't get upset.
Having recently started working on a project with someone who is a good
programmer and even better a good thinker. And having looked for a while to
find someone like that to work with. And having been given tests similiar to
what you have posted, I must offer you my true opinion.
I'm giving 100 points to the person who gives you a formal and lengthy
reprimand for *wasting* company time and money!!!
Please find better things to do with investor capital!!!
Rich

## Re: Gauging interview tests difficulty...

"Rich" <XXXX@XXXXX.COM>writes
##### Quote
Please find better things to do with investor capital!!!
I don't know you either, so... what would you suggest to Eric to help hire
the right person for the job? :)
Alan.

## Re: Gauging interview tests difficulty...

My first reaction would be, oh great, another one of *those* jobs where you
get to reverse psycho-analyze the previous coder because he/she was too lazy
to use the tricky "//" construct..
If you're going to make the poor lads squint at such, just use the method
for finding an interesting dog or cat at the pound:
See if they chase a red laser beam around on the floor..
:0)

## Re: Gauging interview tests difficulty...

##### Quote
Well I think question 1 is just a bit obscure and tells you nothing
anyway (so the random integer can be negative, if its really an integer
it's also infinite, so the function will never finish).
Well I don't agree that it tells you nothing actually, f.i. integer
cannot be infinite because we're face with the integer type, and that's
also why RandomInteger can be negative: because the integer type can be,
and it is not named RandomUnsignedInteger or RandomCardinal etc.
##### Quote
Do some inheritance/object questions.
We have those in other parts of the test.
##### Quote
Grab some bad code from WTF and ask them to rewrite it.
Snippet 1 could be from WTF :)
Eric

## Re: Gauging interview tests difficulty...

I have been programming many years, basically self taught. I am very good
at it as well even though I was never taught sorting, did some on projects
but never knew their names. In all the jobs I have had I have never been
tested, nor have I ever tested people I have hired.
I am not saying that it does not serve a purpose and I know that it has
become quite common but the idea of someone asking me to take a test just
would not set well with me.
I think asking a candidate to show you some of the apps they have written
and explain the technologies used in them would do just a well as a coding
test.
Russ
"Eric Grange" <XXXX@XXXXX.COM>writes
##### Quote
We've been making some interviews lately and gave them a few
coding/algorithmic tests, whose difficulty I'd like to gauge, and this
newsgroup being full of Delphi old timers... ;)

Without further ado, here is an excerpt of the test: you are given 3 code
snippets, for which you have to determine the purpose (actual and/or
intended) and comment during the interview (not a written test). You can
find them at:

82.229.207.75/test/tests.htm

Once you've been there and reacted to these snippets, you can have a look
at the scoring chart there

82.229.207.75/test/scoring.htm

and rate yourself ^_^

How hard do you find that part of the test?

Do you find the test really hard or is there such a knowledge divide
amongst developers? All our candidates claimed to have at least one year
of programming experience (that being Delphi programming or not did not
seem to have much of an impact on the scores, but mostly on the time it
took the candidates to understand the code and react).
Yet in the end, scores seem to be an all or nothing situation on these
snippets: either they got lots of points, or they got very few.

Eric

## Re: Gauging interview tests difficulty...

##### Quote
IMO, a better test to see if a developer can read code is to ask them to
actually debug code with defined input/output.
That's a bit less practical, as they're not in front of a computer.
When debugging, you add an extra layer, which is knowing the IDE and
language well enough. We have some people that we hired that knew next
to nothing of Pascal or the Delphi IDE.
Not sure how this could be made "fair" ?
Eric

## Re: Gauging interview tests difficulty...

##### Quote
I don't know you either, so... what would you suggest to Eric to help
hire the right person for the job? :)
Well, there is always "resume basket": you put a basket in the middle of
the room and throw candidate's resumes at it.
The ones that fall in get selected for the next round, repeat up to the
point when there is only one left :)
Eric

## Re: Gauging interview tests difficulty...

Russ writes:
##### Quote
In all the jobs I have had I have never been
tested, nor have I ever tested people I have hired.
It's funny, because I actually welcome some measure of this in an
interview. It let's me know more about the people I am interviewing
with, what they value, how they perceive the craft, etc. After all,
when I interview I want to make sure I am going to be working with people
I respect and share similar programming aesthetics.
I'm not keen on the kind of test Eric is advocating here, simply because
I think it is too focused on things modern developers don't have to deal
with. It demonstrates different values than mine, so I would have to weigh
that in context of the rest of the offer.
When I interview candidates, the goal is to find some kind of test that
shows they can understand, write and discuss code at a low level of
detail but do it in a realistic way.
I'd ask them to implement something, like FizzBuzz or something more
complicated, then present them with 3 other ways of solving the problem,
then discuss their implementation and the others in terms of their
strengths/weaknesses, etc.
This way I can see if they care about things like elegance,
maintainability, working with others, clarity vs. cuteness, etc. Not to
mention if they are humble enough to recognize an implementation that
might be better than their own. :)
##### Quote
I think asking a candidate to show you some of the apps they have written
and explain the technologies used in them would do just a well as a coding
test.
I think this is more important, but they address different things.
IMO a test is a baseline competency measure. If you don't have this
baseline the likelihood that you will end up with a fast talking
"Architecture Astronaut" is higher than having someone who can grind out
code. I would take the latter any day of the week.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM

## Re: Gauging interview tests difficulty...

Eric Grange writes:
##### Quote
That's a bit less practical, as they're not in front of a computer.
No laptops around?
##### Quote
When debugging, you add an extra layer, which is knowing the IDE and
language well enough. We have some people that we hired that knew next
to nothing of Pascal or the Delphi IDE.
Not sure how this could be made "fair" ?
You could let them choose their language/environment. Most IDE's can be
Javascript and Firebug. :)
This means more work for you in preparing the tests in various
languages/environments, however I bet you can cover most candidates with
JavaScript, C++/C# and Delphi (if that is what you're using). Not to
mention their resume should indicate if you need to prepare something else.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM

## Re: Gauging interview tests difficulty...

"Russ" <XXXX@XXXXX.COM>writes
##### Quote
I think asking a candidate to show you some of the apps they have written
and explain the technologies used in them would do just a well as a coding
test.
That's also what I'd ask indeed. I recall one of my very first
interviews for a programming job where I was given a 1-hour test: not
impressed at all! I felt like I was back at school! At another interview, I
was given the opportunity to show what I had done, which I did successfully.
To subject the candidate to a test would just tell me whether s/he is good
on paper, but what about in practice? that is why I'd value much more the
latter, even though theory is good (but it can always be looked up, if
needed).
Alan.

## Re: Gauging interview tests difficulty...

##### Quote
I think asking a candidate to show you some of the apps they have written
and explain the technologies used in them would do just a well as a coding
test.
We did that too, but found that you can get fooled by people that
"explain better than they code", so to say.
Unless they coded their application in complete isolation, it is hard to
know how much they actually contributed to an application, or how much
of an application they actually understood.
Sometimes it is possible (like when they have personal projects or
hobbies, or are well-known/prominent members or a team, etc.), but it's
not like you have access to the source code or version control logs of
the application at their former/current employee.
Eric

## Re: Gauging interview tests difficulty...

Eric Grange writes:
##### Quote
Well, there is always "resume basket": you put a basket in the middle
of the room and throw candidate's resumes at it. The ones that fall
in get selected for the next round, repeat up to the point when there
is only one left :)
That method is good if you don't want to hire unlucky people. :)
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
server: support.borland.com/entry.jspa

## Re: Gauging interview tests difficulty...

I live and have worked for the past 12 years in an "at will state". If they
fool me I'd just fire them. Don't mean to sound cold hearted but by
fool I mean a deliberate attempt, otherwise I did not do my job and I would
give them a chance to do the job.
I looked at the test and did not see anything difficult in it, I did not
write anything down but I only scored around a 6. Hardly indicative of my
abilities and skills. So in this case I might of missed out on a job that I
could have excelled at, and you might have missed out on a developer that
brings years and years of experience from many different industries.
I know hiring is difficult. It has been a mixed bag for me as well but the
majority of the time I have gotten quality people.
Russ
"Eric Grange" <XXXX@XXXXX.COM>writes
##### Quote
>I think asking a candidate to show you some of the apps they have written
>and explain the technologies used in them would do just a well as a
>coding test.

We did that too, but found that you can get fooled by people that "explain
better than they code", so to say.

Unless they coded their application in complete isolation, it is hard to
know how much they actually contributed to an application, or how much of
an application they actually understood.
Sometimes it is possible (like when they have personal projects or hobbies,
or are well-known/prominent members or a team, etc.), but it is not like
you have access to the source code or version control logs of the
application at their former/current employee.

Eric

## Re: Gauging interview tests difficulty...

Oh, easy and quick:
CS1: Will not compile since 'RandomInteger' is not defined. Even if it is
defined outside the extract I'd not waste my time if I could not get at
all the code. (Such a response should score highly since, if it could be
seen that the function returns a hugely greater range than 'a', a hugely
great CPU plughole would be created).
CS2, CS3: can not be bothered with {*word*99} that would not pass the simplest code
review because of the single-letter 'C primer' variable names. If directed
to look at such code by my boss, I'd start by editing in meaningful
names and comments until the sort becomes obvious, and then ask why an
Rgds,
Martin

## Re: Gauging interview tests difficulty...

Around '95 a friend of mine wrote a game called Robot Wars that used
some sort of timesharing code. Robots could turn, move, shoot,
radar, or check damage status. Throw them into the game and they'd
battle.
I always thought this would be fun for hiring purposes. Explain the
simple premise of the game and have the prospects give you their robot
in an hour, a day, or whatever. Let the 'bots fight it out and the
designer of the winner gets the job.