Hacker News Reader

Comment by cshg | Hacker News Reader

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.

View on HN

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.

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.

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

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

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

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.

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 :-)

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.

Reply on news.ycombinator.com