Software, technology, sysadmin war stories, and more. Feed
Sunday, January 27, 2013

How an interview could burn two hours of my time

I've been pondering some of the comments which appeared in different venues about my "well-calibrated interviewer" post. One of them seemed to suggest that I spent way too much time on them, given that I estimated about two hours per candidate. That resulted in about four hours a week of time, given that they usually sent me two candidates per week.

I should explain where that time went. First, there's the actual phone screen or onsite interview. Those are scheduled for 45 minutes. I would use somewhere between 35 and 40 of those minutes actually talking to the person, getting a feel for where they were coming from, and then, yes, asking questions. I'd tend to ask more questions of the better ones to see exactly how far they could go on some topics.

At the end of that time, I'd "reverse the polarity" and turn it over to the candidate. They had that chance to ask questions of me about working at that company, day to day life, or whatever. If they ever had a question about the place, they could ask it and I'd try my best to answer. Obviously I wasn't about to tell them the answers to pointless questions which were still protected info ("duh, how many servers are there really?"), but few people asked that kind of stuff. More people asked about living in Silly Valley or what a typical day at work might be like.

I answered those questions as honestly as possible. The "typical day" ones were fun, since I'd usually give them a recap of either the current day so far or one in the past week or so. They'd get a feel for what life was really like, including the warts and bumpy spots that you don't find in the recruiting materials. Some people liked this, and some did not. I like to think I helped them make an honest decision, but I could only do that if they asked the right questions.

So, anyway, that's 45 minutes right there. If it was a phone screen, I'd usually get set up for them a good 5 or 10 minutes before that. That meant getting my "real work" to a good stopping point and telling people on IM or IRC or in my office that I'd be unavailable for a phone screen, so please don't bug me -- status messages are great for this. I'd take a chance to run to the bathroom and/or grab a glass of water so I'd be ready during the call.

Then, at the precise time, I'd give them a call. This didn't always work right away. There were phone problems, or other crazy things which forced me to try alternate numbers or redial a couple of times. It didn't always start right away, in other words.

In the case of an onsite interview, I'd have to actually get to whatever room the recruiters had grabbed for them. This was usually not in the same building where I worked. It frequently extended beyond the main 40-41-42-43 complex, too. I went on some interesting walks for interviews. I think the longest I ever had to go was the equivalent of roughly two blocks from my office to the site.

I'd get there a couple of minutes early and would quietly hang out until the previous interviewer was done and was ready to turn things over. Sometimes, there'd be an accumulated time delay due to some issue earlier in the day, and their 45 minutes wouldn't quite be up yet. This would add more time to the schedule, since we'd end up starting late, and probably would finish late too, unless I could use the "reverse polarity" time at the end to fix things up. That would only work if the next interviewer showed up on time and the candidate didn't have any questions of me.

Figure travel time to walk somewhere, plus time waiting for the previous interview to finish. This goes into the time budget, too.

Once the actual interview was done, I had to get back to my office and start the assessment. I'd usually just put on my headphones to block out the world and start typing it into the computer as quickly as possible. I had to unload all of my notes that I had taken, and I usually wound up taking a fairly good transcript of what had been happening. I'd have the questions I asked along with their numbers from the list (yes, there was a list), and all of the responses from the candidate.

I'd usually manage to capture the nature of their response. If I said "how do you remove a directory named -rf", some people would jump up and answer it right away. Others would ponder it a bit, and others still would immediately punt and give up. This was useful information. It was also useful information when compared to how they answered other questions, since everyone has their own standard for how they reply to things.

If someone's quick and good at most questions but lags on one or two, you can start to guess what they've done a lot and what is relatively unknown to them. The people who would be reading my assessments in the hiring committee didn't have access to the candidates themselves, so I tried to capture all of this at the bottom of my writeups for their reference. I hope they didn't read through most of it, since it was rather lengthy in most cases, but it was there for them in case they needed it.

After getting all of the transcript keyed in, then I'd have to go back and break out the list of questions I asked in its own section. This way, the next interviewer would be able to see which questions to avoid because they had already been asked. This section was visible to another interviewer during the process, incidentally, whereas the rest of my findings were not.

I also had to come up with my assessments on their programming ability, problem-solving ability, culture-fit, overall feelings, and a bunch of things I can't remember any more. There was also the dreaded numeric rating where you gave them something between a 0.0 and a 4.0, and I interpreted it like this:

0.0 means "I could not make an assessment for some reason, like not being able to reach them by phone."

1.0 means "If you hire this person, I will quit."

4.0 means "If you don't hire this person, I will quit."

Everything else was somewhere in between, and they hated the "meh" kind of scores which were centered around 2.5. As a result, everyone had to find scores somewhere in the 1.x or 3.x ranges, and the specific placement in those ranges was compared to your earlier assessments of other people.

So, if you gave this person a 3.5 but last week gave someone else a 3.1, this person is significantly better than the one last week. A different interviewer might have given this person a 3.2 compared to a 3.6 on someone else. That means they thought it was a relatively weaker candidate.

Once I had come up with all of this and keyed it in, modulo browser crashes, web site anomalies, and other things going on, I'd submit it. I'd usually get this done within the hour after returning to my office. As a result, I had an excellent "turnaround time" on my candidate feedback. I suspect the recruiters realized this and used me a lot even before the "well-calibrated" program began. They knew if they sent me a phone screen for Thursday at 2:00, they'd probably have the feedback back in by Thursday at 4:00 at the latest.

Considering that other people would take multiple hours or even days (yes, really) to write up their assessments, having me turn things around in basically the time required to type it in must have been a refreshing change.

Add it all up, and give a conservative amount of slop to cover those little anomalies which always cause a schedule to slip a little. I think you can get 2 hours from that without too much trouble, and there's still more.

I didn't even mention the time spent messing around in my calendar to make sure nothing else got scheduled immediately after the interview so that I'd have time to key in all of that stuff. I didn't talk about the process of booking a "phone room" so that I didn't have to bother my office-mates with *gasp* talking on the phone. All of those took time, too.

The point of my "two hour" estimate is that was a reasonable guess at how much time I spent not doing my usual work: writing code, digging into production problems, dealing with bug reports or feature requests, helping users, refactoring things, and all of that.

I wasn't exaggerating. I was just being honest.

If someone else can do an interview in far less time (as some on HN said), then I can only wonder what they call an interview. If it's not all of the things I had to do in my prior existence at that company, then it's not a fair comparison.