For IC roles, the person's main responsibility is writing code. It's pretty important that when someone is interviewed, we get to know whether they can do their main responsibility. It's also a fairly "objective" process, so it can some what mitigate the biases of interviewers.
The problem with "coding interviews" isn't the code -- if your job is to write code this shouldn't be too unbearable (sometimes things do just go wrong, but that's why most companies put you through many rounds; that way a single outlier won't reject a good candidate).
The problem is expecting candidates to solve problems that they would never have to solve in their real jobs (e.g. 'count the number of connected graphs of n nodes', a problem I got on Google Foobar) and expecting candidates to code on a whiteboard instead of in an IDE with a debugger and syntax highlighter.
My company stresses interview questions that are small, not heavily algorithm based (ideally not much more than dictionaries and arrays, though some problems require standard structures like queues or trees) and lets you use your own computer to solve them, so you can work they way you always work! I think this ends up being fair to candidates and let's us see most of what a candidate can do.
Thanks for replying, I definitely agree with you when you say:
The problem is expecting candidates to solve problems that they would never have to solve in their real jobs (e.g. 'count the number of connected graphs of n nodes', a problem I got on Google Foobar)
That's my main problem, I've had interviews where they requested me to write an API that would consume 3rd party services and gave me a few days. That makes sense to me, and that's real.
But I've also had those "solve this riddle in 2 hours using this auto-testing platform to check how well your code behaves" type of problems, where I always keep failing. I get frustrated and fail, and the worst part is (at least in my experience) the biggest companies tend to do that kind of interviews (I'm talking Amazon, Google and the like).
Whenever I get to interview a possible candidate, I try to stay away from seeing their code, I prefer having a conversation about their experience, actually listening to what they say and ask follow-up questions to verify their claims. I've found that works great and it doesn't really take a lot of time either.
Anyways, thanks again for sharing your opinion!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.