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.