Re: WANTED: Interview questions about Informix

Greetings, 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 chris@green.att.com ...!att!green!chris 404.750.5246 ---------------------------------------------------------------------------- >From David Stockel (dccrjc9@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 (lei@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 (cbruce@wvus.org) I always ask them if they've used rowid, and how. Most people generally glaze over on that one... ---------------------------------------------------------------------------- >From Jonathan Leffler (johnl@obelix.informix.com) 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:-} ---------------------------------------------------------------------------- >From John R. Carter, Sr. (jcarter@nas.nasa.gov) To: johnl@obelix.informix.com Cc: chardin@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 (wengland@stephsf.COM) It's a tough c