Software Engineer?

I recently went on an interview for a Software Engineering position. The outcome of the interview was [in the opinion of some of the interviewers], I am not a software engineer. Interesting since I've spent the last 30 years writing and debugging code. Lots of code. Current code. Solid stable production code. V1.0 code. V10.0 code. Even within this context that I am now typing [a new Drupal 7 deployment, configuration, customization in 48 hours... love Drupal/LAMP] I'm puzzled. So I have to ask the question; What is a Software Engineer?

I am obviously confused. I don't know why a manhole cover is round. I can't remember the algorithm for a linked list reverse sort. I can't name every java Collection class or which are thread-safe. I can't name all the containers in the c++ standard template library. Can't whip up a three table inner join off the top of my head. Can't keep perl vs. java vs. python regular expressions straight. I just don't bother keeping my head full of things I can look up. Never have. [Or, better yet, can cut/copy/paste.]

Larry Wall has a great quote about never writing a Perl script/module from scratch since odds are someone else has already written it. The same is true for about 99% of the problems that will need solutions in any given development project. They may not be perfect solutions, but, they are working solutions. A starting point. [That's what iteration is all about. Right?] If I develop one of those solutions from scratch and use it again and again and again, does that make me a Software Engineer? If I memorize one or more of those solutions am I a Software Engineer? If I work for years on one OS, with one language, with one framework, in one vertical market, one product, ... [and, have it all down rote] am I a Software Engineer? What if I'm MCSE, MCITP, CCNA, SCJD, CCNA certified? What if I've been a million dollar winner on Jeopardy?

A Professional Software Engineer solves real world problems real fast. Ramp up time between diverse projects is his problem. That time is never zero and can not be quantified in a 1, 2, 8 hour interview. But, as experience grows, a Professional Software Engineer should be able to come up to speed on a new technology [or, previously used and somewhat forgotten technologies] in short order. Solving the business problem is the issue, not the underlying technology to do so. Know what validates the ability to solve those big technical problems real fast? History! Know what validates the history? References! Know what validates the references? Common Sense! It's been a long time since I've had a common sense interview.