Candidate is fast and chatty: "I don't know. He seems smart, but he was also talking a lot of fluff. Kind of pretentious and arrogant."
Candidate is slow and hesitant (and perhaps pauses awkwardly now and then): "I don't know. He seems smart, but he seems a bit underconfident. We need someone with more energy."
On the other hand, everyone's favorite anecdote: "senior engineers" not passing basic tests like mine.
I still don't feel qualified for entry level (and other peoples' interview experiences don't help!) and that's because entry level and other competency levels are subjective right now. What knowledge should you know from memory? What knowledge are you safe delegating to Google to remember? However, my feelings about my skill could just be nerves.
Lines in the sand would really help the self taught crowd and could be used to bring outdated, lagging CS programs and their graduates, up to speed.
You should commit things to memory the things your memory naturally keeps. If it doesn't it means you aren't using it often enough to bother remembering it. There's so much information I used to keep re-learning and forgetting because I never used it. I finally realized that it was a waste of time.
I guess the problem is when the job you're interviewing for will need vastly (or slightly) different things committed to memory than what your current job does.
I also like something between google and memory: cheatsheets. I have a dev notebook full of checklists and cheatsheets for various technologies I've used and tasks I've done.
Organization is pretty simple. Just need a decently named file with the relevant information. E.g. I would have an sql.txt file containing sql database operations that I don't use often enough to remember, but use often enough to be annoyed by having to search the web on how to do them.
Another example might be a centos5.txt file, giving me a quick rundown of the various setup options I've wanted in the past, and the location of various configuration files.
For programming languages, there's many that I use maybe once every 3 or 4 months. So ruby.txt might contain a quick rundown of how to do basic things: how to define a function, a class, perform loops, instantiate an object, access command line arguments, etc. I find it much better than having to hunt down a tutorial which will also be more wordy than needed.
I also have some for more computer science related things, such as tables of graph and search algorithms, along with their tradeoffs.
Checklists are another good thing. I have checklists for processes I've messed up.
E.g. committing new code. If I don't use my checklist, I always seem forget to forget to update a sample file. Or add a file.
Another big checklist is for giving estimates. For example, one of our legacy products is translated into 5 languages. This checklist reminds me to think of translations, because they have been a huge bottleneck in the past.
Hope that helps some.
What else can you do that would be an accurate simulation of their job that only takes 1hr?
First 1/2 hour: Discuss their code samples in detail -- asking pertinent questions about each as to what they do, and why they did things they way they did. Drill down for detail, ask how they might have done things differently for different use cases, etc.
Second 1/2 hour: Bring out some of your own production code and do the same (allowing them space to ask questions this time). Works best if you let them see something that's a bit "raw", i.e. quick and dirty, which you know you could have done a lot better if you had more time or knew better about the requirements (or perhaps you're simply older and wiser now).
In both sessions, nuance (both in what they can observe, and how they chose to express themselves) is key. And it'll come out a lot more freely than in in a whiteboard interrogation precisely because they interaction will be natural, uncontrived and unforced.
Simple, non-confrontational and 100% reflective of what engineering work is like. That's what we do during the day, 99% of the time -- digging up (sometimes woefully) less-than-perfect components of production systems, and trying to make them a little bit better.
But as to how often we drag someone to a conference room, throw them at a smudgey whiteboard with creaky pens and no eraser, and force them to solve some abstract problems while we boredly look at our watch, and interrupt them with hints?
Basically never. Except, that is, in coding interviews.