It has happened to me in the past, and the most frustrating part is that these were big-time companies. They were offering very interesting roles, big relocation packages and yet, I was turned down for not being able to solve those coding exercises that you never get in real-life scenarios.
What is your take on that kind of interview process? PRO? Or against it? And Why?
I'm personally against it, but not for the obvious reason... I personally think there are better ways to understand if a person knows what they're talking about particularly if that person is not applying for a coding role.
I do interview people on a weekly basis and I never ask to see the code, especially for higher seniorities. In those cases, the applicant should be able to provide proof without showing code. They can cover past experiences, problems encountered, solutions provided and so on.
But that's just me, I'd love to know what the rest of the community thinks, leave your thoughts below!
Top comments (2)
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!