You are viewing gregbo

Previous Entry | Next Entry

Cisco phone screen

classic cylon
I had a phone screen today from the manager of a forwarding plane group at Cisco. The interview started a half hour late, but fortunately, the recruiter (anticipating that it would not start on time), contacted me ten minutes before the scheduled time, asking me to contact him if I didn't hear from the interviewer after a few minutes. 15 minutes after I contacted him, the interviewer called me.

I wasn't very happy with how well I did, for reasons I've given before. Realistically, I don't know how well I will do in a subsequent round of interviews (if that happens), because the group develops code for ASICs, which I have never done, although the interviewer didn't think it would be a problem. It is similar to developing device drivers, something I have done, but not recently, and not on the latest high-performance router hardware.

Anyway, here goes ...

"Tell me about yourself."

I gave a short description of my interests in computer networking and some relevant projects I'd worked on (route servers, provisioning, congestion avoidance).

"What type of work do you want to do?"

I said I wanted to do IETF protocol work. He said his group worked mostly with ASICs and packet forwarding (e.g. IPv4 and IPv6).

"Why did you leave your last job?"

I said I had been working a lot of overtime and wanted to take some time off.

"I see you were also not working for a while between the time you worked at Nominum and Equinix. Why did you leave Nominum?"

I said I was laid off.

He then asked me two C questions he said were "simple". The first was to explain the difference between a struct and a union. I gave an answer that wasn't the best answer (after reviewing the topic in K&R after the interview was over). The second question was to give the size of a struct with an integer, a char, and an integer, in that order. I made a stupid mistake, assuming 64-bit integers, but giving an answer as if I had assumed 32-bit integers. (I didn't realize this until I wrote to the recruiter letting him know that the interview had taken place.) But even if I hadn't made that mistake, I might still have given an incorrect answer. Some experimenting with sizeof and various structs revealed that the sizes that the C compiler I was using (gcc 3.4.6 FreeBSD) aren't necessarily predictable. In the future, if I am ever presented with this type of question, I will give the sum of the base sizes of each struct element as an answer, and indicate that for padding, the actual amount of storage may be rounded up to a multiple of the word size.

In general, I am just getting burned on things that the interviewers think are easy, but I have (historically) not had to demonstrate on-the-job knowledge of. In most cases, I can either look up the information, or if it's a bug I've introduced, I can find and fix it through my own unit testing, before checking in the code. Otherwise, historically, the bugs have been sufficiently tricky that no one else on the team was able to fix them quickly, so my overall job performance (relative to others on the team) was considered at least satisfactory. Basically, I don't expect much to change – my performance on interviews will more or less mirror how I would perform on the job. All I can do is hope that someone interviews me who doesn't care if I get some "easy" answers wrong, because they are confident that I will get the job done anyway, or I get the answers right, because these are things I just happen to remember at the time.

Comments

( 3 comments — Leave a comment )
agrimony
Oct. 3rd, 2012 02:12 am (UTC)
I have seriously never understood the concept of interviewing people with questions on things that would routinely be looked up during the actual course of a job or expecting people to recall cold things that would usually be done on a computer (or at a lab bench, etc). Visual and contextual clues matter a lot in many lines of work.
gregbo
Oct. 3rd, 2012 06:46 am (UTC)
FYI, here's a thread from NANOG where some network engineers and ops people debate whether certain interview questions are appropriate for HR people to ask. What I find interesting (but not surprising) is not only that people in the thread disagree among themselves whether these questions should be asked by HR staff – some of them could not answer the questions during interviews the others posed (although they could answer these questions by just looking up the information). In this challenging economy, where employers don't want to take chances on people who might be poor hires (because they don't answer "easy" questions correctly, and there isn't always time to find out more about the candidate), I'm sure lots of people are turned away despite having the skills to get jobs done.

Also, in my case, having been unemployed for three very long stretches (each time well over a year) doesn't look good. There is too much "if you can't get a job, something's wrong with you" sentiment going around, at least in the computer industry.

Edited at 2012-10-03 06:47 am (UTC)
gregbo
Oct. 6th, 2012 05:02 pm (UTC)
FWIW, I took a look at the C99 standard to see if there is an algorithm or procedure that one can use to determine how large a struct is, given its members. Other than the size of a char (1 byte), there is neither – it's "implementation dependent".
( 3 comments — Leave a comment )