An internal recruiter approached me about this role. She had an old resume, and I gave her a refresh. She was pleasant to talk to.

I then proceeded to have a phone screen with the group's SW manager. He informed me it was a position that focused on resolving performance issues and that they needed a generalist. I wasn't too confident of my chances because I knew they were going to be hard-core about it. We talked about multi-threading issues, like how I'd know my program was in a deadlock situation.

I didn't think I was going to get a callback, but lo and behold, I did! So I went in the following Monday to the Mothership.

I was initially double-teamed by two engineers. It was pretty much a train wreck after they were done with me. They asked me things that did not leverage my current knowledge. For example:

• How would I implement 'ls'? My immediate answer: I don't know enough about file systems to answer that question adequately.
• How do programs load and run? I might have touched upon that subject briefly in college. Another 'I don't know' answer from me.
• Is it possible to write a user-level pthreads library? I took a stab at this one, but they picked apart every answer I gave, like vultures. So I ended up crying uncle on that too.

The rest of the interview went much better, but I knew my goose was cooked by then.

I did get the expected no-thank-you note from the recruiter. I did, however, write back and relayed to her my awful interviewing experience: that the first two guys either ignored or didn't read my resume and therefore were ill-suited to interview me.

She was really cool and seemed to take my opinion seriously. We have stayed in touch.

Although, I subsequently took another company's job offer. It was a no-brainer, actually.

How would I implement the 'ls' command in Unix?

How does the runtime program loader work?

Is it possible to write a user-level threading library, ala pthreads?

Writing a run-length encoder to do a basic compression scheme on an ASCII character data file.