CANAL Interview Process

25 January 2018 in Careers

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).

Stage 1:

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:

exam2009v2

The first section of the exam is supposed to be clear:

  1. 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.
  2. 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).

Stage 2:

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:

1) Would you like to go over the exam now?
    — If they wanted to know the answers to the questions, or had any of their own, we were willing to walk through it then. If they had no interest in knowing the answers, that’d be a little telling, too.
2) Do you work anywhere else on campus?
    — This was a no-go, couldn’t hire students that were already employed on campus, some workstudy rule.
3) Did you look up any of the answers afterward?
    — This was to gauge their curiosity, see what they found (or didn’t).
4) Describe a system, see if they can describe it back to you.
    — We often skipped this and focused on #5
5) If they are familiar with traceroute, discuss TTL and see if they can figure out how it works.
    — Here we’d show them the output of traceroute, we’d talk about Time To Live and explain decrements for each hop. Given that, we’d ask them to theorize how traceroute might work. This was a lot of fun, listening to their thought process and watching things click.
6) Give us an example of a project you worked on independently?
    — People who can work in groups are great, unfortunately it was hard to find people who work on their own.
7) What accomplishment are you most proud of?
    — I enjoy listening to people get excited about their accomplishments. 
8) What projects have you done in the past that may be relevant for networking or programming?
    — It WAS a network research lab.

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.

Leave a comment

You can use basic HTML tags, including <code> and <pre>.