2) I draw only if I need to explain something to the interviewer. But I have a visually oriented way of thinking, so I don't need this for myself in most cases. Then tell them how to implement this or that, when I know how it would work. (We will need a vector to store this data, run a search on this, have those tables in the database, linked this way, to be queried with this SQL expression). Would depend of course, if they actually expect you to show some code or just to outline the core points of the possible solution.
3) Normally I talk a lot and let them know intermediate steps (Watch their faces, you can see if you're on the right track). There is no problem in saying something that's wrong. If the interviewer knows a bit about the job, he won't expect you to be perfect on the spot. (If they send you somebody to interview you who doesn't know that: wrong company, good bye) If I get stuck, I tell them that that's a complex problem and I need to think some time about it. Shouldn't be a problem. Maybe I give them some of the points that make me worry and line out the possible problems and solutions. (If I do it that way it will use more memory, but the other way will give me better performance, cleaner code...)
4) I just tell them what I'm thinking. I don't think what they may want to hear. They get what I have and that's it. If they don't like it, that's bad luck (For them of course, not for me)