I felt similarly about whiteboard questions the first time I went through interviews, but after having to interview other people myself (and a lot of them), I quickly realized that I simply hadn't properly understood the purpose of these exercises. They aren't designed to see if you can code (you are usually given the benefit of the doubt on that one), rather they are designed to see how you think.
Usually a whiteboard question (with me) will go something like this: I will ask you to write a pretty simple algorithm, then tell you there are no tricks because people are surprised that is so simple. I then change the problem scope which makes you change the algorithm to something slightly harder. We then spend time debugging it because no one ever gets it "right" the first time. That's fine, a big part of the exercise is to debug it together. And from this I can glean something I never would by just looking at your GitHub commits: how you think about a problem. Do you make a table for yourself and step through the function mentally? Do you immediately think about edge cases? Etc. The way I can figure this out is by the interviewee talking (and if he isn't talking I ask him some questions to get him thinking out loud).
If you just give them a terminal and leave them to program it, it doesn't really tell you anything about these aspects. Unfortunately I can't jump in your head to see what's going on, and if I leave you to start blasting away at a keyboard I probably won't be able to analyze you're wild moving of code around or fast typing, not to mention it being hard to see on a screen over your shoulder. The whiteboard slows down their writing (since they're not typing), forces them to think vs. blindly changing values and hitting run -- again, it accommodates having a conversation about the code. I already know that you can look this algorithm up online or its included as part of the standard libraries for this language anyways, and I'm fairly certain given a debugger and sufficient test cases you could whip it up in ten minutes.
The other reason something simple like "print a string in reverse" is chosen is precisely because it is understood that it is harder to program on a whiteboard without tools and while being watched and nervous. Not to mention if you asked an actually difficult question, it would be really hard for even the interviewer to know what's going on (whether it be looking at the code you wrote afterward or as you wrote it on a whiteboard). I cannot understand being "offended" by an easy question. If its easy then better for you right? You were already planning on spending an hour in the room with me, how could this possibly be a "wasting your time"? Just do it. Also, it is well known that this is part of many CS interviews, why would anyone be surprised by it? If someone gets offended by a whiteboard question its usually a fantastic indicator that they are a bad candidate in my opinion.
Additionally, these questions can sometimes also serve as fantastic early indicators that a person is way out of their league. As I said earlier, I don't think I've ever met someone who got everything right immediately (and I agree, if they did, the question would be useless). Lots of people think they did poorly because they choked and missed some edge case that had to pointed out to them -- not at all, I've been incredibly impressed with people that took them multiple revisions to hone their algorithm. However, when someone really doesn't know what's going on its painfully obvious, they usually won't even understand what the algorithm is supposed to do or have never even heard of it. I've had people with Masters take the entire interview, not finish the simple question, and not even be really sure what was asked.
My thought process is roughly "Okay. Which language? Is it null-terminated, random addressable, or mutable? Do I get compiler errors or unit tests? Should I buffer manually? Do I have a signature? Can I assume single-width characters? Should I ask?"
caveat: The question needs to be asked right. Instead of "here's a task I need you to perform", it should be "can you walk me through how you would solve a task like this?".
Usually a whiteboard question (with me) will go something like this: I will ask you to write a pretty simple algorithm, then tell you there are no tricks because people are surprised that is so simple. I then change the problem scope which makes you change the algorithm to something slightly harder. We then spend time debugging it because no one ever gets it "right" the first time. That's fine, a big part of the exercise is to debug it together. And from this I can glean something I never would by just looking at your GitHub commits: how you think about a problem. Do you make a table for yourself and step through the function mentally? Do you immediately think about edge cases? Etc. The way I can figure this out is by the interviewee talking (and if he isn't talking I ask him some questions to get him thinking out loud).
If you just give them a terminal and leave them to program it, it doesn't really tell you anything about these aspects. Unfortunately I can't jump in your head to see what's going on, and if I leave you to start blasting away at a keyboard I probably won't be able to analyze you're wild moving of code around or fast typing, not to mention it being hard to see on a screen over your shoulder. The whiteboard slows down their writing (since they're not typing), forces them to think vs. blindly changing values and hitting run -- again, it accommodates having a conversation about the code. I already know that you can look this algorithm up online or its included as part of the standard libraries for this language anyways, and I'm fairly certain given a debugger and sufficient test cases you could whip it up in ten minutes.
The other reason something simple like "print a string in reverse" is chosen is precisely because it is understood that it is harder to program on a whiteboard without tools and while being watched and nervous. Not to mention if you asked an actually difficult question, it would be really hard for even the interviewer to know what's going on (whether it be looking at the code you wrote afterward or as you wrote it on a whiteboard). I cannot understand being "offended" by an easy question. If its easy then better for you right? You were already planning on spending an hour in the room with me, how could this possibly be a "wasting your time"? Just do it. Also, it is well known that this is part of many CS interviews, why would anyone be surprised by it? If someone gets offended by a whiteboard question its usually a fantastic indicator that they are a bad candidate in my opinion.
Additionally, these questions can sometimes also serve as fantastic early indicators that a person is way out of their league. As I said earlier, I don't think I've ever met someone who got everything right immediately (and I agree, if they did, the question would be useless). Lots of people think they did poorly because they choked and missed some edge case that had to pointed out to them -- not at all, I've been incredibly impressed with people that took them multiple revisions to hone their algorithm. However, when someone really doesn't know what's going on its painfully obvious, they usually won't even understand what the algorithm is supposed to do or have never even heard of it. I've had people with Masters take the entire interview, not finish the simple question, and not even be really sure what was asked.