Once apon a time I did technical interviews for DP/MIS/IS/IT contractors.
Tips:
First never ask a question you can’t answer yourself - a clever candidate can trip you up, then dance around the question before you realize it - “If you can’t wow 'em with knowledge, buffalo them with BS” is the expression.
Do not venture into areas out of your expertise unless you can anticipate and deflect all questions. I used canned Q’s for specific areas in which I did not have expertise, but I knew enough about what mainframes could or could not do that I could detect BS.
Example: a common bit of processing involves posting transactions to a direct-access master file - be it IMS, IDMS, VSAM, DB2 (of which SQL is a subset, btw), PL-SQL, Access, whatever (think: posting debits, credits to a bank account). There is a point at which it is more efficient to sort the transactions by the primary key and run a sequential update (2-file match) - if more than roughly, 10% of the master file/database records will be updated, it is more efficient to do sequential posting; below that direct-access is more efficient. This has been known (at least for mainframes) since about 1970. I once got a guy (1986) with great personality, and all the signs were “we’re going to hire this guy, give him your blessing”. I asked him which would be more efficient if 20% of the records were to be updated. He hesitated (up Intel then, his responses had been immediate), and then blurted "I’d test it!". From there, I asked some Q’s about things equivalent in terms of system design - he disintegrated right there before me. When asked my opinion, I responded “I have never seen it piled so high before”. No offer was forthcoming.
Points - ask graduated questions, and have a couple which nobody could answer - when you get to a plateau, explore horizontally - see if the previous answers were solid or were ‘winging it’ and coming up with the correct answers.
Always be ready to dig deeper - if something flunks the ‘sniff test’, you can explore, if it passes the ‘sniff test’, escalate to the next level.
Most important - know enough to evaluate the answers - do NOT rely on simply a bunch of questions for which you have the “correct” answer - life does not fit in a binary model, and asking questions blindly helps neither you nor the candidate,
I’ve posted this in another thread, but I just love it. I do not, nor have I ever known, IDMS (do your own search - it’s pretty much dead now), but we got an interesting resume from someone who claimed IDMS experience, When asked questions on the lowest level, he had no idea what I was talking about (my canned lists were prepared by knowledgeable geeks on the team, and consisted of 20 questions, divided into 4 levels), and eventually confessed that his expertise consisted of possession of a technical manual from “_________” company - the company had changed its name a few years (and release levels) earlier, but he didn’t even know that. Even I knew that much.
As to the internet (or anything else) - as always, start with giving them free range in which to define themselves - NEVER say “We need someone with advanced internet skills - is that you?”. Ask “So (name), how well do you know the internet?” - if the candidate is forthright enough to say, “I’ve used a bit, but I’m not an expert”, you are going to want to take a different tack (sailing term) than you would if the response was “I know all about it - what do you want to know?” - the former is worth questioning, the latter should hear “I’m sorry, you would probably not be happy with the work - we don’t really need someone with that level of expertise; best of luck in your search”.
Then start with the increasing levels of questioning, At some point you will have a good idea of just where they rank on the skills assessment.
Technical Q’s can be answered in several, equally valid ways - if all you can do is a word-for-word match of A to Q, you’re not ready to do this kand of interview.
For the record: the only Q I’ve been asked and could not answer: “What is the maximum length of a JCL parameters?” A: X(128) (COBOL), 128 bytes for the non-COBOL’ers out there. I then stumped him with “What is/was UPSI?” (you have to go back to the 60’s to have even the foggiest (or work for a certain (unnamed) shop in the mid 1990’s).