Thanks for the great article! I totally agree with you and can admit of being guilty of sometimes carrying out "litmus tests" myself. It is total nonsense to discard a candidate if they don't know a specific thing or two in a given language.
Could such tests bring more value when there are sufficiently many of them? If the applicant doesn't know async-await, cannot explain "this" in JS, cannot code a binary search tree, and doesn't know what a pure function component is, isn't it then reasonable to be able to make the assumption that this candidate may not be the ideal candidate for our company? We cannot rank the candidates by how many they got "right", but we can say whether they passed or failed. Does this make any sense?
Yes, I totally agree. It's incredibly valuable to ask a candidate a range of questions on a range of topics - or to ask them to attempt a range of different whiteboard-style challenges. But as you point out, the key is to not treat any one of those questions/challenges as a "knockout" issue. Instead, look at the aggregate value of all the answers combined.
Also, I think it's important to differentiate between "the candidate can't code this from scratch off the top of his head" versus "the candidate has no idea what this concept is, when to use it, or where to find information about it."
In the example I gave regarding binary trees, I know dang well that I can't sit down, right now, and code it up from my head. But I know what a binary tree is. I know when you generally consider using one and what benefits (and downsides) it provides. And I know that, if I had to go code one up tomorrow, I could absolutely be "up to speed" on it in a very short period of time. That's far different than dealing with a candidate who's never even heard of a binary tree and has no clue what purpose it would serve.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the great article! I totally agree with you and can admit of being guilty of sometimes carrying out "litmus tests" myself. It is total nonsense to discard a candidate if they don't know a specific thing or two in a given language.
Could such tests bring more value when there are sufficiently many of them? If the applicant doesn't know async-await, cannot explain "this" in JS, cannot code a binary search tree, and doesn't know what a pure function component is, isn't it then reasonable to be able to make the assumption that this candidate may not be the ideal candidate for our company? We cannot rank the candidates by how many they got "right", but we can say whether they passed or failed. Does this make any sense?
Yes, I totally agree. It's incredibly valuable to ask a candidate a range of questions on a range of topics - or to ask them to attempt a range of different whiteboard-style challenges. But as you point out, the key is to not treat any one of those questions/challenges as a "knockout" issue. Instead, look at the aggregate value of all the answers combined.
Also, I think it's important to differentiate between "the candidate can't code this from scratch off the top of his head" versus "the candidate has no idea what this concept is, when to use it, or where to find information about it."
In the example I gave regarding binary trees, I know dang well that I can't sit down, right now, and code it up from my head. But I know what a binary tree is. I know when you generally consider using one and what benefits (and downsides) it provides. And I know that, if I had to go code one up tomorrow, I could absolutely be "up to speed" on it in a very short period of time. That's far different than dealing with a candidate who's never even heard of a binary tree and has no clue what purpose it would serve.