I've recently started a new job at a company that uses perl
as its main programming language (yay! Being around people
that share my professional interests is such a nice change
of pace.) And, as part of this job, I find myself having
to interview people.
So, I'm wondering if anyone has any good advice? What kinds
of questions work well? Are those annoying logic questions
worthwhile? Does anyone have any really good questions to
separate the strong candidates from those just faking it,
particularly relating to perl? (I'm also interested in
weeding out mysql dba candidates, but that's probably less
interesting to the perlmonks as a whole.) And really bad
questions?
I've definitely seen the downside of hiring someone that
wasn't up to the position (from both sides, actually), and
a lot of people are very good at faking their way through
interviews. And, perhaps just as importantly, some really
good people are terrible at interviews, and I want to try
and find those, too.
(Yes, you can infer that I work for a company hiring Perl
programmers. We're in (or rather, moving in a few weeks to)
Berkeley, CA.
Feel free to send me email if you want more info.)
-- Kirby |
Re: Perl Interviews
by myocom (Deacon) on Feb 13, 2001 at 06:10 UTC
|
| [reply] |
Re: Perl Interviews
by arhuman (Vicar) on Feb 13, 2001 at 19:07 UTC
|
I have to interview people too, but on the contrary of what you do :I'm not trying to find if people are good;
Instead I'm rather trying to find if it will be useful/pleasant to work with those people.
I mean a great programmer, being asocial can ruin an entire team work.
A Newbie can become a great coder (at an interesting price...)
An so on...
So I've choosen some traits which are important to me, and that's what I'm trying to find during the interview :
1) REAL desire to learn or better a passion for computer/coding.
Does the guy code by pleasure (does he code at home?) what is the last thing he has learnt and why ?(show me if the guy is ecclectic ? Curious...)
This desire to learn or coputer's passion is the best garanty that the guy will be constantly improving for me.
2) Human qualities.
Hey ! some people (me?) will have to work with him
Can I trust him ? Does he accept his weaknesses (Those who have no weaknesses in interview tend to report their failure on others(and never learn from their mistakes) according to my experience...) ? Is he smiling ?(don't know for you, but I prefer to work with happy people...) How does it stands pressure ? Is he feared by heavy work load (My boss seems to have no limit on this !)
Some traits aren't necessay but are although a plus for me :
Ability to propose solution, loving challenges...
I tend not to rely to much on experience...
As you see technical skills/diploma aren't my first interest (although I require BASIC skill in the technical fields needed...)
And of course, this is by no mean : THE WAY to interview people, but only my humble opininion
(technically biased as
I'm not HR).
(Just note that I've never been deceived until now)
| [reply] |
Re: Perl Interviews
by TheoPetersen (Priest) on Feb 13, 2001 at 20:12 UTC
|
Before I can help you, I have to interview you :)
Are you interviewing for immediate help (people who will hit the ground running,
as it were), or are you working to build a good team in the long run?
It would be nice to do both, I'm sure, but the interview styles are different.
When looking for immediate help, you should ask technical questions focused
on your problem: do you know how to work with sockets in Perl? Have you
scripted with CGI.pm?
To build a good team long-term, interpersonal issues are as important as
technical skills. First and foremost, everyone has to get along with you
(assuming your interviewing position indicates some degree of team leadership too)
so you should be checking for the kind of things that you like in co-workers,
and also for things that drive you crazy in people you have to put up with.
You can try asking about what the interviewees like to do off work,
but of course they have every right to turn down personal questions.
Do ask about their experiences in programming teams previously, and try
to get them to air their gripes and talk about what they enjoyed.
If you aren't hiring to fill an immediate niche position, the main thing to establish is learning ability
and enthusiasm. Does the interviewee wince at your choice of language or tools?
Why? Do they display an interest in languages, and in the subject matter?
You just changed jobs; why? What interested you in the project and company?
That should provide some good questions for others considering the same move.
As for figuring out who is faking it, there isn't a simple answer. Barring a really bad blunder, you have
to go with your feelings. If someone gives you a bad vibe, then ask yourself, do I want to work with
this person? If you have any misgivings, don't hire them. It's far better to go short handed
for awhile than to hire someone you have doubts about.
People who are bad interviewees are even more difficult. Ask them to expand on answers.
Ask them easy questions first to get them in the habit of answering. If necessary, start
with what they had for lunch :) If someone seems promising but is hard to figure,
ask them for another interview, at a different time of day; maybe even a different location.
If you have doubts about a person who seems promising, try another tactic. Ask them to discuss
a program they've written in detail (bearing in mind that non-disclosures prevent you from seeing the code
most of us write for a living). Good programmers love to talk about their best hacks.
A little used technique is to ask them to bring a co-worker or friend to an interview.
Engage the other person to help draw out the interviewee. You may even find yourself two employees at once. | [reply] |
Re: Perl Interviews
by KM (Priest) on Feb 13, 2001 at 20:32 UTC
|
Along with the good advice others have mentioned, let me add one thing.
I find it useful (and actually enjoyed interviews where this was done with me)
to bring a practical problem to the interviewee. For example,
'If you had to solve problem X, how would you do it?'. Then, give them
a piece of paper to allow them to write (maybe a short flow chart, or
pseudo-code). Then you can interact with them as you see their though
process. This was done at an interview with me, and I had a good time
interacting with the fellow interviewing. Not only could he see how I think
in real-time, but I was also able to follow his thought/design process.
It allows you to ask other follow-up questions like 'Why are you using module
Z and not module A?', and 'But what if X occurs?', etc...
Cheers,
KM | [reply] |
Re: Perl Interviews
by seeker (Curate) on Feb 13, 2001 at 17:36 UTC
|
You might ask if the person has ever been here
or even knows about perlmonks or any other site
devoted to Perl. Not that a negative answer would
disqualify a person, but a positive answer would
be an indication of interest in improving one's
knowledge of and abilities in Perl. | [reply] |
Re: Perl Interviews
by sierrathedog04 (Hermit) on Feb 16, 2001 at 21:35 UTC
|
When I used to interview candidates for a SQL-related position, I would always ask the following:If A has three rows and B has three rows then how many rows will the query 'Select * from A, B' return?
Most applicants got it wrong. The most common answer was six, but some people would say three. (The correct answer is nine.)
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
