CANAL Interview Process
When I was a manager at the network research lab (CANAL: Central’s Advanced Network Architecture Laboratory), I had the opportunity to be creative and perform interviews in order to hire new students for the lab. This process that we created stole a few ideas from other schools and mostly was just a lot of fun for us. I felt like it’d be nice to share the process and the idea behind each test to help any future applicants (although, they no longer use this process).
First, any student with workstudy on campus was encouraged to apply, Computer Science or IT (Networking) was preferred. Students would schedule a time to come in and take the following exam, they could take any amount of time they wanted and could not use the Internet:
The first section of the exam is supposed to be clear:
- Can the student read and follow directions? I think one version of it said “write answers on a separate piece of paper” but I think literally no one could handle following that.
- Does the student have an ego? Are they willing to BS answers or can they swallow their pride and say “I don’t know” when they don’t know something.
I won’t go over all of the questions because I think they’re rather self-explanatory, but I’ll point out some that are unique.
- The first question is supposed to be deduction, the other publicly routable address is actually one owned by the university. Obviously, the “why” is more important than the actual answers.
- The other unique one was number 11, stolen from an engineering quiz.
Once they finish, I’d mark the time and then send them on their way. I’d follow up with an email and ask if they’re interested in the second half of the interview process (everyone who said they were willing, got to the second round).
First, I’d give them a tour of our office (wave to the team!), network, and server closets. I’d pull out a server in the rack, open it up and point out all of the major hardware components of the server. I’d allow them to ask any questions they wanted, etc. Then afterward, I’d take them to one of our student hardware labs and ask them to point out the major components in one of the desktops. I realize putting students on the spot like this must have been horribly nerve wrecking, but being shown and applying knowledge from 10 minutes ago to these other systems, regardless of their background was something I felt I could use.
Next, we’d find a small classroom (basically a conference room with a row of computers at the wall) and one of the grad students would join me and we’d ask the following questions:
Finally, Stage 2 continued:
We’d invite anyone from the team who was free to join us in a game of Fluxx. If the student was wearing a tie, we’d tell them they could loosen it and be comfortable. If you’re unfamiliar, the game starts out with a Draw 1, Play 1 ruleset and no goal to win. As you play cards, the rules of the game change, goals can be set and it’s possible to win very quickly but you have to be able to pay attention. Afterward, we’d ask if they’d like to play again and we’d play however long they wanted. This gave us an opportunity for the team to be around them and see how well they can handle winning or losing, etc and it helped us gauge their personality better.
Anyway, we’d say our goodbyes and I’d followup again in email on whether or not they got the job.
Looking back, this was probably a horrible waste of time, but I really enjoyed the interview process. I felt I had a pretty good understanding of whether or not I would be excited to work with the student. I also felt it wasn’t necessary to have previous knowledge, but we were able to identify how teachable and interested the student truly was.