DEV Community

Discussion on: Litmus Tests in Tech

Collapse
 
ksaaskil profile image
Kimmo Sääskilahti

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?

Collapse
 
bytebodger profile image
Adam Nathaniel Davis

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.