Ask the candidate questions on where to find things relevant to his role at your installation.
This is important because even if he knows the details for the last release he worked on, they may be different for the releases you're running. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Brian Westerman <[email protected]> Sent: Wednesday, May 28, 2025 1:40 AM To: [email protected] <[email protected]> Subject: Re: Interview questions External Message: Use Caution technical questions a re difficult to come up with because there are no two sites that are the same. There are some general things though that could be asked, like how they would handle specific problems, this is especially good if you have some that you may have handled in the past. You pretty much have to go by following their methodology to see if it fits what you did or if it's so far off track that you know they would not be able to do the job. Even having supported hundreds of sites there are almost no problems that are exactly the same, however they are VERY similar and the approach to fixing or debugging is just as important as knowing the solution off the top of your head. Actually, it's probably more important because shooting from the hip tends to be wrong a lot, and that type has a hard time shifting focus. You could ask general systems programming type stuff, i.e. how they handle SMP/e, how often they feel maintenance should be applied, how they would migrate maintenance between the LPARs and/or plexes. What is their approach to problem analysis and resolution. How would they handle the O-Dark-Thirty calls that we all get. What vendor software have they worked with in the past that your site has, and how they deal with vendor software issues. It's also very important that they can work with the existing people at the site. Some systems programmers are very secretive and don't like to work with others, but are otherwise great at their job. If a "team" is important to the site, then someone like that would not work out. How do they handle frustration with management decisions that impact the data center negatively? Some people don't interact well with management, but are great systems programmers. Are they able to teach others? Can they even work well with others? All of that is way more important than any specific technical question that you might come up with. One of the best CICS systems programmers I ever met was nixed on a job because he didn't know the SYS1.PARMLIB members, even though they wanted him for CICS expertise, and the chances of him making a parmlib change were close to zero. Several months later, the site had some major CICS issues and several of the people on site were terminated over the outage. He probably would have resolved the issue in a few minutes, and in fact when they approached him later to offer him another "chance", he told them the solution (which was correct) and then turned down the offer of another interview. Sorry to run on about this, but when I read your post, I started to wonder how I would handle something like this. I have interviewed lots of times, but never really had to interview someone for my type of position. I think it would be fun to try, but difficult to actually have to do it. Good luck. Let me know how it went. Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
