I interviewed at a big company here in the Bay Area earlier this week, and despite what everyone says about their interviews, I came away thinking that I wasn't very challenged by it. I ended up teaching one of the interviewers about UML and chirality, and had a few good laughs over lunch with another fellow. Most of the other interviewers seemed eager to get back to what they were doing.

One thing bothers me: I received what I thought was a very nice offer from a little startup that's doing some super-cool stuff, and when I mentioned the number to one of the interviewers, he said something like "and then when you finished laughing..." which makes me think my idea of what a reasonable W-2 salary is might be incorrect. The last time I received a W-2 was when I worked for my high school cafeteria, so I have no idea what I'm supposed to be paid for a "real job", other than to subtract 25% from my 1099 rate and multiply it by 2000 (roughly the number of full-time work hours in a year and a handy number to know).

One constant in all these interviews is that quite a bit of what I learned for the CTF competitions at DEF CON etc seem to be considered black magic guru type things by regular programmers. For whatever reason, questions about many of those subjects make good interview questions and I hear them a lot.

I'm not going to quote any actual interview questions, but some examples might be:

1. How are destructors for static global objects implemented in C++?
   
2. What is the value of an automatic-class variable declared in C?
   

The answers are:

1. Usually there's a .dtor (destructor) section emitted by the compiler's infrastructure junk, and it contains a list of function pointers to the destructors themselves. Since they take no arguments and return nothing, the shutdown code just calls each routine in order. This technique is used to execute arbitrary code in situations where you can only overwrite a single pointer-sized chunk of memory, and have the ability to dump a payload non-destructively in the process's memory space.
   
2. This is a doubly tricky question. The answer to someone who thinks they know what they're doing is that the value is random since it's a stack variable. The correct answer is that it is either zero because the routine is using space from zeroed pages at the top of the stack, or they will be values from routines that have already used space from that part of the stack. This fact can be taken advantage of in all kinds of ways for stack-based overflows. The values are absolutely not random, and if you can nail down a call graph (and there's no use of _alloca()...) you can predict what they will be with startling accuracy.
   

Anyone outside the security community would consider either fact to be deep black magic, unless they've implemented a compiler or something. It just goes to show that learning how to attack can often be the best way to defend.

You know, I think there's a sound bite of me saying something like that on a San Diego news show, but I don't feel like putting a video of me in my stupid convention costume on my blog. The sound bite is something like "sometimes the best way to build a better bank vault is to try to break into one," which is something I pulled out of my butt when the interviewer lady popped the "anything else?" question after the usual ones. If you ever hear that, it's code for "we didn't get a good sound bite when you were babbling earlier, so throw us a bone here."