×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Robert Munday wrote:
The manager on my new project has asked me to derive a list of RPG technical questions for a programmer interview she is conducting later today. The company is coming off of two old platforms (COBOL and Lansa) and their intent is to do all development in RPGIV, /Free and embedded SQL. They have been burned previously by a programmer or two who represented mucho experience only to find that they did not know sh** from Shinola.
If you have questions to submit which are thoughtful and moderately involved, please send them to me offline at RWMunday@xxxxxxxxxxxxxx
Robert:
I like some of the ideas so far in this thread. I particularly liked
the 'missing LR' idea.
The last time I was part of an interviewer panel, I brought a
listing of a very short source member that had a bug that would
cause a severe compiler error. There were maybe 25 lines of code in
a fairly do-nothing-of-importance program module. Somewhere early in
the interview, I sat the page over near the interviewee, saying
nothing about it.
Later, I asked simply "Why won't that compile?"
In this case, I don't recall what the bug was -- mismatched PR/PI
names, missing quotes around a literal, whatever -- it's not nearly
as important as how the question is handled by the interviewee.
As it turned out, after a couple minutes of study once the question
was asked, the correct answer was given (and other interviewers on
the panel did _not_ spot it;) but I was still interested more in the
process and reactions than the technically correct answer.
No useful answers would be given to help the 'debugging'. Direct
answers to necessary questions are fine -- E.g., "Does this file
exist for the compile job?" "Yes [if it does exist]." But "Should I
look at the C-specs?" wouldn't be answered except perhaps "If that's
where the bug is, sure."
First indication I had was that the interviewee took a little time
to take the initiative to pick it up and look at it before being
asked to. Next, the time taken and distraction from the interview
process was noted. Any ongoing looks later as time passed were
noted. In short, as much info as could be gained about the whole
person was noted before even mentioning what the purpose.
The correct answer was actually gravy.
A huge range of otherwise unspoken questions were answered in a
short time. Did the person even recognize RPG? Was ILE RPG familiar?
Were procedures familiar? Were the questions that were asked about
the source member relevant to the task? Etc.
The activity validated answers that were given in much of the rest
of the interview.
Tom Liotta
midrange.com
