WANTED: Interview questions about Informix
christopher.hardin
Every now and again, I have to interview programmers to fill a
contractor position. The problem I have is what do I ask these people?
They say they have N years experience with Informix; how can I prove it?.
If you had to hire someone, what kind of questions would you ask?
I think the questions would have to range from ESQL/C to 4GL. Most of these
interviews are done over the phone, so the questions can't be too involved:
(Write a UNIX kernel using cat(1) Be brief but complete (grin)).
Thanks for your help.
--
Chris Hardin ch...@green.att.com ...!att!green!chris 404.750.5246
Jonathan Leffler
>Message-Id: <1992Apr20.1...@cbnewsk.cb.att.com>
>Subject: WANTED: Interview questions about Informix
>Date: 20 Apr 92 19:28:45 GMT
>X-Informix-List-Id: <news.1040>
>
>Greetings,
>
> Every now and again, I have to interview programmers to fill a
>contractor position. The problem I have is what do I ask these people?
>They say they have N years experience with Informix; how can I prove it?.
>
> If you had to hire someone, what kind of questions would you ask?
>I think the questions would have to range from ESQL/C to 4GL. Most of these
>interviews are done over the phone, so the questions can't be too involved:
I4GL:
A. Which versions of I4GL have you used? (1.00, 1.10, 1.10.03, 4.00, 4.10)
B. Which database engines have you used? (SE, Turbo, OnLine)
C. How do you organise the source code for a project?
Object files? Forms? Messages? Log files?
D. What are the problems with the Program-Compile facility?
How do you circumvent them?
E. How do you arrange that the function keys used by a project can be
changed with the minimum of fuss.
F. What are the problems with INPUT ARRAY?
G. What are the problems with CONSTRUCT?
H. How do you handle security in an application?
I. What's your favourite undocumented feature.
J. What's your least favourite documented feature.
K. What's your least favourite undocumented feature.
L. What's your favourite documented feature.
M. How do you handle transactions? With INPUT ARRAY?
ESQL/C:
A. As for I4GL. (Add versions 2, 3 and 5.00 to list; delete 1.10.03)
B. As for I4GL.
C. As for I4GL.
D. How do you handle SELECT statements typed by the user at run time?
(Answer A: well, you take the code from the manual and fix it.)
(Answer B: well, you use SQLDA structures. And the code in the
manual isn't all that much help because:
-- it doesn't illustrate DATETIME, INTERVAL, BLOBS, VARCHAR, etc.
-- it isn't fully generalised.
-- etc.
)
(Answer C: I don't)
E. Which undocumented functions do you know about?
I,J,K,L: As for I4GL.
And so it goes on.
You also need to check on the engines, and probably database design.
On second thoughts, if you've done the design, you don't want a
know-it-all who tells you how you should have done it:-}
Yours,
Jonathan Leffler (jo...@obelix.informix.com)
Jerry Pope
>Greetings,
>
> Every now and again, I have to interview programmers to fill a
>contractor position. The problem I have is what do I ask these people?
>They say they have N years experience with Informix; how can I prove it?.
>
> If you had to hire someone, what kind of questions would you ask?
>I think the questions would have to range from ESQL/C to 4GL. Most of these
>interviews are done over the phone, so the questions can't be too involved:
>(Write a UNIX kernel using cat(1) Be brief but complete (grin)).
1. What's the advantage of using PUT over INSERT? Under what circumstances can
you see the affect? What's the disadvantage?
2. What's a cursor?
3. In a given table, if you had a variety of sorting needs based on three
different columns in various combinations (colA, colA+colB, colA+colB+colC,
colB, colB+colC, colC), how many indexes would you create? Why?
If the dude was in front of you --
4. Write a short code segment (in a metalanguage if you'd like) that, given some
typed in select statement by the user, executes the query and displays the
result.
There's a whole bunch of questions you could ask and I could list, but I tire
easily. Ask loaded questions that will tell you a LOT from each response.
---
--
Jerry
ch...@green.att.com
Earlier this week I asked the Net for Informix questions to ask a
potential employee. Several people asked for a copy, so below is a summary
of the responses. Thanks to all who took the time to respond.
---
Chris Hardin ch...@green.att.com ...!att!green!chris 404.750.5246
----------------------------------------------------------------------------
>From David Stockel (dcc...@bpats.bell-atl.com)
I do this kind of thing all the time. My consulting firm requires that
all of our potential hires be screened by someone already on staff who
is knowledgeable in their alleged area of expertize. I end up doing a
lot of the technical interviews in Informix for the Philadelphia area.
I originally prepared a list if questions covering UNIX, C, Informix, and
Database design. Over time, I have added questions covering things that
interviewies have brought up. I don't have my list handy, but here are
a couple of things from memory:
UNIX Describe vi commands.
Compare and contrast fgrep and grep.
Describe awk, make, sccs.
Database What is in the systables?
What is null for?
Talk about creating tables, indexes.
Familiar with Rules of normalization?
When should they be ignored?
SQL quiz touching on joins, OUTER joins, and sub-selects.
Informix What do you like/hate about it?
What products? ESQL, 4GL, SQL, ISAM?
Compare and contrast INPUT and INPUT ARRAY?
What problems have you run into with INPUT ARRAY?
Describe specific features of a application you have dev.
The distressing part is that I can only tell from these questions what
the person knows about at the time of the interview. This could be a
very clever person who will pick up all they need to know in the first
week. How do you test for that kind of ability?
----------------------------------------------------------------------------
>From Charles Lei (l...@mediatech.com)
Chris,
I usually ask the prospective programmer to go over the projects
they've worked on and usually you can tell if they're BSing you or not.
I have also given these candidates a quick test after their initial
interview to test their knowledge.
For an Informix person, maybe you can test to see if they
can really do a select by writing a quick report...
----------------------------------------------------------------------------
>From Corinne "CB" Bruce (cbr...@wvus.org)
I always ask them if they've used rowid, and how. Most people generally
glaze over on that one...
----------------------------------------------------------------------------
>From Jonathan Leffler (jo...@obelix.informix.com)
----------------------------------------------------------------------------
>From John R. Carter, Sr. (jca...@nas.nasa.gov)
To: jo...@obelix.informix.com
Cc: cha...@cbnewsk.cb.att.com
I'm not too surprised that you responded to this one, and I'm glad you
did. But I'm disappointed, though. You have a good list of questions,
but to someone who knows little or nothing about the subject these
questions are too high-tech. With each question should be a synopsis of
what kind of answer would give what kind of feel for the respondent's
technical expertise. You're brief examples in the ISQL part attempt
this, but would have served better to be more inclusive. Here's the
hard part: you gave a good service for free and I'm sure it's going to
be used well, yet it only answers part of the request - which is why I
didn't get involved (no time to get that involved, yet look what I'm
doing here! I guess I have a greater affinity responding to you than I
do to someone else.)
Another view about interview questions is that many people have never
taken the time to analyze or evaluate how they do things. To be asked
point blank about such matters puts them out in left field having to
think about it for the first time and - who knows - they may be experts
without even knowing it. So I like to ask questions that get people to
talking about their experiences, not what they know. I'll find out what
they know by how they went about it. This means I have to know. In this
regard, the questions you presented help the uninformed interviewer
to filter the educated from the experienced. Remember, the best
educator is probably the least likely person you would ask to perform
the actual task. The intuitive processes of the experienced seal
often exceed the skills of the trained juggler. (My quote, if you please.)
Shucks, just knowing these questions I should be able to blow anyone's
mind that I know a lot about Informix - you've given me enough
buzz-words to kick any conversation into high gear. With just a little
research on this I think I can even convince you I'm smart.
I think you're on the right track with these questions, though. I would
definitely add some questions that bring out horror stories and failed
attempts. Even questions like, "How do you go about getting answers to
your difficult problems?" will show up the closet programmer. Heck, I
never used internet before coming to NASA. The other half of my world
is now complete.
Just so you don't think what you've done is trivial, I've saved all your
questions. (Somehow I don't think that's a comfort to you.) I value your
good experience and intelligence highly, just based on our recent brief
interchange. (Maybe that will serve better.)
-----------------------------------------------------------------------------
>From Bill England (weng...@stephsf.COM)
It's a tough call. It's more important to me that the persons
I'm looking for be intelegent, have good working habits, and
have referances that speak positively about the projects/software
they have recently worked on. ( Opinions about the people
are sometimes irrelevent. )
As for experiance or Tech questions to ask:
1) What problems do recursive/referential database structures
have with regards to SQL.
2) What is a "Scroll Cursor"?
3) What data types does Informix 4gl support?
4) A question they should not know the answer to. Just to
check on how they handle the stress. ;-) The answer should
be "I don't know but, I know where to look it up."
I would keep all questions pretty simple and short.
Good Luck!