I admit, I've never interviewed a technician before. I have to interview a guy applying for a mfg line support position as an electronics "troubleshooter". mostly this position will deal with system level and perhaps some board level troubleshooting of medical devices on the mfg floor, prior to escalating it to to an engineering technician or engineer.

the guy has listed on his resume the following bullet under Education:

-- <school name> Technical College (2006/07) - Electronics Technician Program.

i looked at his school, it could either be a one year program or a two year program. the way this bullet is written, doesn't make me think he necessarily completed it.

so, part of this multi-person interview process is that actual troubleshooters in this position from the line will interview him separately, so i don't feel like i need to ask him specific troubleshooting questions, as im sure they will.

but i cant really ask him questions that i would normally ask an engineer or even an engineering technician.

can i ask him KCL or KVL? is that out of range for this level of technician? because i don't know what's more simple than that, besides Ohm's Law.

anyone else have any experience interviewing semi-skilled tech positions?

2/23/2009 10:59:16 AM

Does he have any work experience?

Ask him about that and see where it goes.

[Edited on February 23, 2009 at 11:01 AM. Reason : 

2/23/2009 11:01:25 AM

how many pairs in CAT5

2/23/2009 11:05:07 AM

^^ he has work experience, but his last job ended (for whatever reason) over a year ago. hes been working his own business since then, which doesnt have anything to do with electronics.

^ this position has nothing to do with networking, but i suppose thats something that's taught in any technician program. me asking that would probably seem like im purposely trying to trip/catch him.

2/23/2009 11:15:31 AM

Give him a scenario where he has to explain to you how to fix something simple, with you being a helpless female or something, and then you'll get insight into how he approaches and thinks through a generic problem.

We do this all the time when interviewing college grads for TAC. Being a networking guru already is less important than having a general grasp on a structured troubleshooting/problem solving methodology.

2/23/2009 11:31:36 AM

I agree with bobby, textbook questions aren't useful.

Put him in the position where he would need to do his job...troubleshoot.
Give him some word problems, if he would be using tools you can provide the answers instead.
If he handles that alright -give him some boards to work on

2/23/2009 11:37:00 AM

My thoughts are this....
While Certs usually mean knowledge, some of the best troubleshooters I ever saw did not have them.

Talk to some of the IT people you already have. Get some real world things that they see.
Get some daily examples and then get some really hard examples.

Then ask this guy how he would troubleshoot them.

2/23/2009 11:42:45 AM

our corporate hiring process does not allow us to take interviewees into troubleshooting areas for hands-on testing, and we cant bring equipment into the interview areas. two separate buildings, actually.

but i think you're all right about the nature of the interview: it should be a more organic discussion with descriptions of process, rather than pen-and-paper problems.






[Edited on February 23, 2009 at 11:46 AM. Reason : PS... this is not for an IT tech. ]

2/23/2009 11:45:18 AM

Even if you can't bring "line" equipment to the interview location, I have to wonder if you couldn't rig up a test like the IS department would use at my last job.

The guy would "create" some very simple but non-obvious technical problems - sabotaging a power cord, for instance. (I think he disconnected one of the prongs, then re-sealed the cable). This doesn't require any kind of sophisticated equipment - nearly anything will do, and it's a very good test of how your potential troubleshooter approaches the problem.

2/23/2009 12:17:29 PM

Also..I was not suggesting taking him into the troubleshooting areas.
I was simply suggesting that he be given a problem...verbally...then ask how he will approach it.
You could simply take a recent issue one of your IT people had.....be ready to answer with any testing results that he may need to move forward.....and see where he goes.

I have to admit that I really like Steve's idea also.

2/23/2009 12:30:46 PM