Some developers see technical interviews as just part of the process that they have to put up with when they’re looking for work. Others think they’re great, and a great deal more think they’re the worst thing to happen to programming since <insert most hated programming language here>.
Having made a business out of helping people prepare for coding interviews, let me be the first to say this: Technical interviewing isn’t perfect and I don’t think it is the way to interview a candidate. However, it has its benefits — if you understand why a company is asking such questions.
By technical interviews, I mean interviews were managers ask software developer candidates to write code on a whiteboard and solve algorithm problems. For example, a typical question might be something like, “Write code to rotate an NxN array in-place (without using additional memory).” Or, “Design an algorithm and write code to find the longest palindrome in a string.” It might even be something like, “Write the binary search algorithm.”
A lot of candidates object to such questions, arguing that if you have such a problem in real-life, you’d just look up how to do it. That’s fair – except that’s not why you’re being presented with such problems.
A company asks coding / algorithm questions not to test you on specific knowledge. They don’t really care if you know how to find the longest palindrome in a string. If you happened to know the solution off the top of your head, it wouldn’t really earn you any bonus points. Or, at least it wouldn’t with a good interviewer.
Employers ask these questions as a way to “sample” your problem solving and coding skills. They don’t particularly care if you know how to solve that particular problem, but they do care about how good you are at solving challenges that you haven’t seen before. So, they throw a bunch of questions at you that are hopefully new to you. By asking you a bunch of different questions, they can sense how strong of a problem solver you are in general.
In some cases, you’re absolutely right when you say you could look up the solution if necessary, or call an API to do something if there’s one available. Unfortunately, you won’t be able to do that in all problems in the real world. That’s why these questions exist.
Is this process perfect? No. Some companies put too high a standard on performance here, thinking that there’s a substantial difference between a candidate who does well and one who does very well. Some focus so much on these questions that they don’t look at factors like your references, personality, work ethic, prior experience, etc. And, there’s a lot of great engineers who just don’t “test well” on whiteboard coding interviews.
So these questions aren’t perfect tests of your ability, but there’s good reason to ask them, at least until we can measure a candidate’s ability strictly by his/her resume. I’m not holding my breath for that day, though.