I've always had a terrible memory.

I frequently have to calculate how old I am when asked (versus simply remembering), and I regularly quiz myself on the birthday of loved ones, trying to pound the information deep into my memory banks. People's names only really stick with me after several dozen encounters, and faces aren't much better. An embarrassing number of times I've encountered childhood acquaintances and distant (or even near) family and failed to realize who they were.

It certainly isn't that I intend to be disrespectful - my brain just isn't wired to put information into long term storage on first (or second, or third...) encounter, and it punts (or loses the pointer to) older data. In many cases it's like a filter on the long term archive simply refuses to persist the information, and less practical information simply never gets logged away regardless of my conscious opinion about it. For instance I am a longtime fan of the Family Guy and the Simpsons, but it's very rare that I can verbatim quote a funny scene, outing me as a poseur to the quote spewing human-SNPPs. At most I remember generalities ("That episode about all the people coming to look at the leaves").

This is just the way my DNA (along with environment) made me.

I've been this way since the beginnings of my memories (ironic, no?). In junior high I remember doing very well in tests based upon figuring out the algorithms and techniques on demand (e.g. during a critical test) myself. I did this using heuristics of what I was taught, rather than the more traditional rote application of literal knowledge. Well, to be honest a part of it was laziness, but a lot of it was just the way my brain is wired to learn. I carried this technique on to high school and post-secondary, and then to every industry certification since. It has served me very well.

This fundamental of my thought process carries over to software development as well, which is why I write this here - I am not, and have never been, a walking MSDN Library. Simple terminology for everyday patterns and practices escape me if they aren't the sort of thing that one realistically uses in regular conversations with peers (e.g. outside of the occasional architectural astronaut bravado buzzword talk). When quizzed what software development books I like most, it is rare when I can name more than one title (and the recollection is usually based upon logical correlations of content with likely titles. e.g. "The book about how 9 women can't make a baby in one month...month...The Mythical Man Month!"), yet I've read dozens of software development and process tomes. It's even less likely that I remember the author ("who wrote TMMM? Steve O'Connell? No? Let me just hit Google...").

To draw from a more common example, I often get asked "Have you ever...", based upon my experience in this industry, and I have little to offer on-demand in regards to specifics: I simply do not remember the fringe function calls of projects past, even if I battled it in a dozen different ways. I consult computerized references regularly (MSDN Library, Google, Google Groups, and so on), even for everyday library functions and classes, and maintain archives of old code to remind myself of solutions and techniques I discovered previously (e.g. "I solved something similar in a project 3 years ago..let me check the source"). I even built a from-scratch implementation of AES (the cryptography artist formerly known as Rijndael), and submitted changes to the reference code, yet I remember absolutely nothing about that cryptography codebase now that it isn't pertinent for me.

So given all of this, is the point that I'm like a perpetual newbie, always starting at square one? Absolutely not. Instead of remembering literals and absolutes, I remember heuristics and mental hints - little brain guideposts that allow me to solve difficult problems in very little time. In code I catalog which projects (both those of my own and others) solved particular problems, and I can quickly reference them and get definitive answers (rather than speculative answers). While I'm not the sort of type that can endlessly recite facts and details about esoteric kernel calls, I do manage to find exactly the information that I need immediately using modern tools (I've always been great at making search engines sing. One manager many years back was sure that I was hoarding some techniques, because I always managed to find solutions to vexing problems. The key was that I had enough mental hints to narrow down to specifically where the solution was hidden). My memory technique, coupled with an excellent problem solving ability, has made me an extremely productive, capable developer and application designer. Let's say I'm a cheetah, and tools like the MSDN Library and Intellisense are hugely beneficial in my hunting arsenal. I'm a cheetah with a crossbow.

There is another type of developer - let's call them the elephant. The elephant remembers everything about every technology, every function call, and exactly how to solve specific types of problems in a very literal way. The elephant can remember every detail of things that interest them (e.g. Star Trek trivia), and could probably operate fairly effectively without any sort of online, or even offline, help. The elephant often makes a very capable developer, and is a very capable complement to any teams. The elephant functions based upon precedent and a cumulation of literal knowledge.

Of course there are an endless number of points in between, such as there are with most human traits.

I mention all of this after hearing yet another peer recounting their experience with a prospective employer. Like many before, they were given an "aptitude" test (because years of experience and a 4-year university degree just don't demonstrate much anymore, apparently) where the test was a paper/verbal quiz of select esoteric elements of languages and libraries.

I just don't get this.

Are organizations looking to hire an expensive organic version of manpages? Do they really, truly think that this is a logical way of evaluating skill? Are they afraid that all reference material will disappear and they'll be at the forefront of reimplementing mankind's knowledge?

Come on industry, grow the heck up. Quit these nonsensical and meaningless tests. Just because someone on your team could think up what they think are "clever" questions to trip up prospects doesn't mean that this is even marginally effective at pruning your candidates (you might as well roll dice). Getting developers to code on paper (when many of them have awkward, barely functioning handwriting given that they've been typing for most of their lives) is just as destructive, despite all of the dubious arguments used to support it..

I can draw from personal experience as well: Several years back I did an interview with a firm (for a position that I turned down), and I still remember that the answer to one particularly hilarious question was the SQL Server function PATINDEX. I've designed and implemented several large scale, very advanced database systems on SQL Server, using the most advanced techniques and practices. In none of them did I use the function PATINDEX (it's one of those functions that you'd better have a very good justification for using. It largely appears in very poor designs). It's not that I hadn't come across it - I had in several tragic designs that I was called in to fix - but it certainly wasn't top-of-the-mind material. Yet here it was, being used as a test of whether I had an "advanced" knowledge of SQL Server. This is fairly typical nowadays, where candidates will find their knowledge "tested" by being quizzed about some fringe technology that the interviewer happened to be working on that week.

If you want to assess your candidates, give them a realistic environment - call them in, give them a workstation, and ask them to solve a particular problem. Let them use the online resources that they would regularly have available (e.g. no online rooms of experts waiting to help them in their assessment, unless they can promise to have the same once they're on fulltime), give them the normal reference material, and let them go wild. At the end look at what solution they've developed. If necessary screen capture their activities (with their knowledge) so you can see their process. Hire the people who work in the way you want. Even better hire the people who yield the results you want, regardless of their personal techniques.

Of course if you really do operate without reference material, you code on lined paper, and you largely deal in esoterics, then perhaps you might want to continue with the current norm of interviewing.