Harder programming questions do a worse job of predicting outcomes

Re:Harder programming questions do a worse job of predicting... by cshg on Monday February 18, 2019 @01:23PM (#19192828)

Specific examples of what classifies as a “hard” or “easy” interview question would be very helpful to have reference points and assess one’s own interview process.

[ Parent | on HN ]

Re:Harder programming questions do a worse job of predicting... by geebee on Monday February 18, 2019 @07:24PM (#19195739)

I wish this comment were higher in the thread, because it's essential. I'm very interested in this finding from triple byte, but we have no guidelines for what hard and easy questions are.

I know these questions are part of triplebyte's product, so a full, repeatable study isn't in the cards. But if someone from triplebyte could just post a few examples of each, I'd be able to get a lot more out of this result.

[ Parent | on HN ]

Re:Harder programming questions do a worse job of predicting... by akhilcacharya on Monday February 18, 2019 @01:28PM (#19192880)

Easy - reverse a string, determine if a string is a palindrome, reverse the digits of an integer, determine if one string is an anagram of another.

Hard - implement a subset of regex match in optimal time+space, find the operations required to turn 1 word into another word given a list of transitory words, find the median of 2 sorted arrays in optimal time, find the next permuted value.

[ Parent | on HN ]

Re:Harder programming questions do a worse job of predicting... by kbp on Monday February 18, 2019 @02:21PM (#19193421)

I think those "easy" examples are too easy to get any meaningful signal from. If they struggle, they have no idea what they're doing, and if they don't, you don't really learn anything about how they work because there's not much to them.

Other people have mentioned Triplebyte using console tic tac toe as a question; that seems like a better sort of "easy" question that still lets the interviewee have a chance to show off their problem solving and factoring skills.

[ Parent | on HN ]

Re:Harder programming questions do a worse job of predicting... by pps43 on Monday February 18, 2019 @01:33PM (#19192939)

That's more like small/large than easy/hard.

[ Parent | on HN ]

Re:Harder programming questions do a worse job of predicting... by akhilcacharya on Tuesday February 19, 2019 @09:42AM (#19199190)

I'd argue finding the next permutation is actually very difficult if you don't know the standard algorithm.

[ Parent | on HN ]

Re:Harder programming questions do a worse job of predicting... by pmiller2 on Monday February 18, 2019 @02:14PM (#19193359)

The key word here is “optimal.” These aren’t difficult tasks if you can just write down the straightforward code to do them.

[ Parent | on HN ]

Re:Harder programming questions do a worse job of predicting... by ensiferum on Monday February 18, 2019 @01:45PM (#19193075)

examples of hard (subjective), recursive algorithms, anything that requires dynamic programming, generating permutations/subsets, problems that require a "de facto" memorized algorithm such as tree/graph traversals, coloring of subsets etc.

easy.. anything that is not hard :-)

[ Parent | on HN ]

Re:Harder programming questions do a worse job of predicting... by pixeloution on Monday February 18, 2019 @02:27PM (#19193496)

And here's the problem. People don't agree what's hard/easy. If I ask you to find duplicate values in a nested data structure (arrays of arrays) ... that calls for recursion. I think that's easy.

So I'm curious how they define hard/easy.

[ Parent | on HN ]