Whenever I interview a student to work in the labs, I show them the flowchart I have taped to my door. I tell them that's what I'm really looking for in a student worker. They generally laugh or pretend to find it amusing to curry my favor.

The other day, one such student asked for a job and I explained that I'm not hiring now, but if she wanted to prepare herself to be better qualified to work for me, she should do several things:

1. Learn a couple new computer programs
2. Create a website on the CC servers
3. Cultivate a proactive attitude
4. Learn how to troubleshoot

The ideal student worker will be helpful and take initiative. When people enter the lab, they'll make eye contact, perhaps even ask "Do you need help with anything?" and when the person says yes, they'll be able to help them, either by knowing how to do what the person needs to do or by looking it up or exploring their options. If something goes wrong in the lab on their shift, they'll look for ways to solve the problem and report the problem, in addition to what they've tried to do to fix the problem.

My problem is coming up with a set of questions or scenarios to test people for these characteristics and developing training to get people to do these things.

Kinetic Software Kx implementation

I've attended several of the remote setup meetings for the Kx implementation, which will make scheduling and billing a bit easier, from what our campus room reservation people say. The early sessions were held in an off office on campus and the implementation manager from Kx used Adobe Connect Now to show us the screens and gather information. We (the five to eight people involved) would gather around a 17" screen and try to see what was going on. It was less successful. 

We switched to a conference room with an extremely large HD TV and conference call phone and that was a much better experience. Then we used a room with a speaker phone and projector; the speaker phone's microphone was out, so we switched to Google Chat Voice, which worked pretty well for the two hours, though neither end used a headset, so we could hear ourselves. 

Connect Now worked, though the lag was a bit much, as our implementation manager was using remote desktop into a system here. Also, there were resolution problems, as the projector's resolution was too low to allow true full screen of the remote desktop session.

We could have used Skype for both, as the integrator has Skype on her machine, but we didn't know that until she had shared her screen.

Lessons learned:

It's best to have a conference phone for a conference call.

It's best to have technology folks on both ends discuss usable technologies and set up early.