I guess it depends on the industry/clientèle, but meetings are fundamentally very similar. You are worried about what "they" will ask and if you will be able to answer the questions.
With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles.
In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have something memorized, but to check your familiarity with the subject. Everyone sits with a browser while they code - I don't think that's a unique workflow. The thing is, if you've done this HTML -> CSS conversion a hundred times before, you wouldn't need to look it up. They're trying to gauge your experience level and if you've done this stuff hundreds of times before. I bet even a highschool student could find that with Google.
EDIT: I think a more relatable example would be if the interview gave you a simple geometrical problem and you were upset you can't look up the Pythagorean theorem. You're not being tested on your ability to memorize the Pythagorean theorem per se - it's just that everyone is expected to know the Pythagorean theorem b/c it's so fundamental to the sciences. Super simple problem with no google are testing if you have domain familiarity and experience and are a metric of whether you will hit the ground running or not. They're not gauging you problem solving ability, or your ability to memorize crap.
My experience has been that with a client, the universe of potential questions is much smaller than the universe of potential questions in an interview. An interviewer can go almost anywhere. . .that's not usually the case with the client. As you said, the client is asking about the software you are developing, not - typically - details about how you would handle their business need in a different language or on a different platform. Or about textbook information you may have covered in a class a few years back and haven't used once since.
I've had the polar opposite experience. I guess we have very different clients. Clients generally ask questions that don't make a lot of sense or that show a fundamental misunderstanding of how the system works. They may introduce new constraints and requirements on the fly that you've never heard of before. It's generally a lot more difficult. The "universe of potential questions" is basically limitless.
Interviewers aren't going to ask you nonsensical questions about the STL or to use algorithms in contexts that make no sense. The "universe of potential questions" is limited to the reasonable.
But with clients (at least the ones I've dealt with) it is part of your job to educate them.
Question doesn't make sense? Let them know (gently, of course). Fundamental misunderstanding? Same thing. You are speaking from a position of authority.
I suppose you could try to take that posture in an interview but you are gambling on the interviewer being receptive to that approach.
I completely agree. Ostensibly the client should know more because he's the one ordering the product, but the reality is you often need to educate them.
But that just goes to show it's more stressful and difficult than an interview.
I admit I've never experienced what you describe with a client - at least not to that degree. On the other hand, as another poster stated, with a client you've already established some level of authority and can bring them back down to earth or tap a teammate for help/clarification (unless you are working solo) or give a general response and say you will need to get back to them with more specifics. (Of course, with a prospective client, you are, in fact, interviewing and may not want to do that.)
I guess it depends what you want to test. I've not once done the task untog described, but if you sat me in front of an Internet-connected PC with an editor and browser, I'm pretty sure I could do it in ~30 minutes or so. I sure as hell could not do it on a whiteboard.
So. What kind of skills are you looking for? Someone who's memorized a limited set of knowledge and can slap it on a whiteboard on demand, or someone who can get shit done? Not that they're mutually exclusive or even uncorrelated, but why test for a poor proxy of what you want instead of exactly what you want?
When I'm working, I'm looking stuff up all the time. And, everyone I've ever paired with has been looking stuff up on a constant basis.
It's not that I'm crap, it's that the tools I'm using are always changing. HTML -> CSS? Sure, I won't look that up. CSS -> SASS? Sure, I probably won't look that up. Ask me to use LESS, I'll be on much looser footing. And, what's coming next? Do I have to have the new ES6 specifications memorized? I don't, though I've used those 100 times already, in the past weeks.
I never ever hold it against someone if they say they need to look something up. No one should nor can memorize all the things we developers need to remember.
It'd be interesting why Einstein said this. I'm guessing because it takes time and effort to memorize something, not because he thought the brain had finite memory capacity.
The thing is, if you've done this HTML -> CSS conversion a hundred times before, you wouldn't need to look it up. They're trying to gauge your experience level
That really doesn't make sense, though. They were gauging my experience level by forcing me into a development process I have never used before?
I don't think the best way to test if a person can do X is to take them far, far out of the environment in which they've always done X, and would be doing X if hired by you.
I think the computer there would be so you could see your progress, not so you could look things up. Write the display rule, then sanity-check; fix the margins and remove the bullets, then make sure it's right; etc.
With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles.
In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have something memorized, but to check your familiarity with the subject. Everyone sits with a browser while they code - I don't think that's a unique workflow. The thing is, if you've done this HTML -> CSS conversion a hundred times before, you wouldn't need to look it up. They're trying to gauge your experience level and if you've done this stuff hundreds of times before. I bet even a highschool student could find that with Google.
EDIT: I think a more relatable example would be if the interview gave you a simple geometrical problem and you were upset you can't look up the Pythagorean theorem. You're not being tested on your ability to memorize the Pythagorean theorem per se - it's just that everyone is expected to know the Pythagorean theorem b/c it's so fundamental to the sciences. Super simple problem with no google are testing if you have domain familiarity and experience and are a metric of whether you will hit the ground running or not. They're not gauging you problem solving ability, or your ability to memorize crap.