When I started my career, I also used to find trivial interview coding questions irritating.

As I developed and started applying for more senior positions, I started to find them downright patronising.

As I developed further and started to sit on the other side of the table, I realised that they aren't there to catch out the people who forgot a closing brace, they are there to catch out the people who don't know what a closing brace is even for.

The first time you do the interviewing from the other side, it is truly amazing how many people with extremely impressive-looking CVs fall into that latter category. Having a CS PhD and experience assessing undergraduates on more complicated programs is no guarantee of any sort of programming competence by professional standards. Neither is having been a Senior Software Engineer leading a team of developers at a past employer, for that matter.

This is a side effect of the broken hiring process. Typically candidates are found by acronym matching. The folks who are below average (don't know what a closing brace is) will keep tweaking their CV/resume until they get called since it is pretty easy to guess what acronyms are being looked for.

When they don't succeed in getting hired they will keep repeating the process which means they will go through many interviews. A person on the other end of the bell curve is likely to interview a handful of times in their entire career so you are unlikely to ever see them.

It's definitely true that poor candidates are on the market much longer than excellent candidates so they are over represented in interviews. I don't think it follows that the hiring process is broken though. I think it's just evidence that hiring is hard. The very best candidates are essentially never on the "open market."

I meant that it is broken at a specific organization if you end up doing an in person interview, they walk up to the whiteboard and do not know what a closing brace is. They should never have made that far through the organisation's interview process, unless that specific process was broken.

> Asking someone experienced to write the "print a string in reverse" algorithm will naturally insult them.

Why? It's a trivial question that any programmer should be able to answer easily. An interview is a test. An interviewee should be happy if the test starts so simply. It's a chance to warm up and get in the groove.

When you took tests in school were you insulted if the first question on the page was too simple? No, you just answered it and were happy that you earned your first points so easily.

The reason it is annoying for people who are experienced is that generally they are looking for jobs where they get to work on difficult and interesting problems. Being asked such a simple question might indicate that you are interviewing for a position you won't want.

I'd personally be very tempted to answer the whiteboard question and immediately explain that I'm not interested in a job that consists only of writing trivial implementations and ask if they can give examples of real problems they face which are non-trivial.

I have actually had one interviewee ask me such a question, although not in response to a simple test or question of my own. This impressed me, although I get the impression that most interviewers would not appreciate this in a similar way to how they do not appreciate candidates that find their fizz-buzz test annoying.

An interview is not a one way test. It is a two way test where the employer can also fail.

Your answer implies you have a high ego as you consider the questions below you and only interested in satisfying your own intellect/ego instead of working in a team that gets shit done... read shipping products.

Precisely. It's a bozo-filter. _You_ know you're not a bozo but the interviewer doesn't (yet).

I ask questions like this in interviews because experience shows that a significant percentage of supposedly experienced developers have trouble with them.

If you ace the simple questions, you'll get something harder next.

Some people will take 30 seconds on a question a tiny bit harder than print a string in reverse... and some people take 30 minutes . Those people have similar looking resumes. It's a useful signal.

So if you are offended by that, then it's really your problem. Just answer it in the 30 seconds it takes and the interviewer will immediately go on to other (harder) things.

Your complaints kind of conflict, because it doesn't matter if you don't have a compiler -- you should able to write code to reverse a string on the board. People realize that it's not an ideal coding situation.

> Asking someone experienced to write the "print a string in reverse" algorithm will naturally insult them.

Being insulted is the wrong reaction. Either you are a good coder, you will write it down on the board in one minute and we'll move on, or you are not a good coder, you have a crappy attitude and you are not getting an offer.

How about third possibility: they will think that your company has a crappy attitude and hiring policy and move out?

>Their ability to program? Or their ability to practice interview tricks?

Often, neither. It can be the ability to think clearly and communicate that thinking. I personally avoid whiteboard coding questions when I interview people, but the good ones I've been given involve a good back-and-forth, basically working on the problem together.

I usually ask more open-ended questions, like "how would you go about solving this large, potentially ambiguous problem". Both types of questions give the interviewer the ability to gauge personal skills and mental clarity. Whiteboard questions provide some ability to test technical ability in exchange for some ability to test higher-level knowledge. They both work in the same kind of way, though.

I agree in general, but easy fizzbuzz-type questions are not the main problem with interviewing process by far. There are just too many people who almost cannot write code, including CS PhDs.

This is true. For CS PhDs you should always look to see if they've done any large implementation work or if they've focused more on math. The former will generally have large amounts of source code available for inspection. The latter may or may not be good at programming.

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.

"I cannot understand being "offended" by an easy question."

My thought process: Reverse a string? Really? Is this how they hired their existing programmers?

I think it's a fine question.

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?".

No -- this is how they weeded out prima donnas.

I did an interview with a C++ exam. They left me in a room for an hour, without the internet. Damn, that was embarrassing. I need to log into facebook to tell you my name and birthday. Who the codes without google?

Actually, the article doesn't mention anything about coding on a whiteboard.