I really dislike the idea of "cramming" for interviews. If a person hasn't been developing problem solving and coding skills throughout their career, then it's hardly something they can read up on and develop in a week before an interview.
In most cases, the point of coding interview questions is to see how a person goes about solving a problem as much as it is to see the solution. "I know this because I just read the solution in 'Interviewing for Dummies'" doesn't help at all.
"I really dislike the idea of "cramming" for interviews. If a person hasn't been developing problem solving and coding skills throughout their career, then it's hardly something they can read up on and develop in a week before an interview."
You're misunderstanding the issue here. For the type of things that matter in 95% of actual software, it's true that you can't learn all that in a week before an interview. However, those things are somewhat difficult to get across in a 60 minute interview, and good interviewers who can do that are rare. So they resort to algorithm questions because they don't require much skill to know. Which sucks but the interviewee can easily account for it by (re)learning that same stuff with a week of preparation, maybe a little more if they've got no experience in algorithms.
There is a very real disconnect between a lot of interviews (whiteboards, algorithms) and what people experience in the (current, prospective) job though.
I've found actually pairing with the candidate to be a better measure than quizzing their knowledge of algorithms, etc.
FWIW I think exactly the same way. Since I was in high school I remember not studying a lot for the exams the day before. This was maybe a combination of me being lazy or uninterested and because I thought that whatever I did not know "by heart" at the time I won't learn in 5 hours.
Still, I got out of HS quite fine, I got a BSc with highest GPA of my generation and went to do a PhD in Comp. Sci.
Nowadays I have to do interviews quite often and I although I use some of the "programming riddles" (there is so much you can test in 1 hour phone interview) I usually try to "read" the most I can from the guy I am interviewing.
It's not so much the problem solving and coding skills as the specific algorithm and syntax questions I tend to cram on. My memory is very pattern based so I'm not as good as randomly pulling some snippet up from memory but get me into that problem space and I can more easily give you what you're looking for. This is usually what happens in the real world but in interviews a lot of people just ask random questions with no connective tissue.
In most cases, the point of coding interview questions is to see how a person goes about solving a problem as much as it is to see the solution. "I know this because I just read the solution in 'Interviewing for Dummies'" doesn't help at all.