Hacker News Reader

Comment by dmurray | Hacker News Reader

There's a bit of a "draw the rest of the owl" thing going on here. If you have the experience to confidently eliminate the likely approaches that don't work, then you must know quite a bit about those approaches and their applications.

And in particular, I'm not sure I can agree on eliminating recursion in the anagrams problem. He just says

> Recursion – No way to apply recursion to the problem.

but...there is? One plausible approach, I sort each of the strings and put them in a trie. A fancy sounding thing, but really just a data structure which allows me to rephrase "someString in myTrie" as the recursive "someString is null || (head(someString) in myTrie.keys && rest(someString) in myTrie[someString])". I'm not arguing that this is better than a hash table, though I think it probably is on some workloads - just that it's not possible to rule this out and solve the problem by pure process of elimination.

View on HN

That's the nature of thought frameworks. You need to fill in the gaps yourself. It's still useful to have an organized approach. In my experience, people can know how well each technique would be suited to the task at hand if asked. But, they rarely consciously go through each technique they know and consider if it's the right approach. Most people would be well served to do this more often.

Btw, this is a big failing in interviewers who help. Asking the right questions (what data structure could you use here?) is incredibly helpful. So helpful that you're not testing them on a slow moving, relevant skill (structured thinking) but instead a fast moving, less relevant skill (what data structures do you know?). Bad move.

I kind of agree, in that a good candidate should probably already be thinking "what data structure should I use here" no matter what the problem is. Just always think about what data structure to use. Every problem requires one.

More in the vein of what you're getting at though, I think helping a nervous candidate by asking obvious questions like this can be helpful: "What data structure would you recommend using for this problem?", or "What programming paradigm do you think would fit this problem best?". It's a bit of an ice breaker, and can lead to more interesting conversation than the candidate just sitting there, quietly thinking (admittedly, possibly not a good sign for a candidate if they do this, but interviews should be built around making it a good experience for the candidate as well).

I have completely the opposite opinion of your second paragraph. I’m fine with candidates quietly thinking in an interview. It’s a big part of the job. I’m not optimizing for interesting, but for signal. And dropping the signal of “can get themselves going with structured thinking” is not worth it to make it a better experience for the candidate in that moment. I’m okay with a candidate feeling uncomfortable while they’re failing an interview. If anything, I think it’s better than the standard which is to give hints, act like everything is great and then thumbs down them later. Makes people so confused. There’s also a whole thing about who gets hints fastest, confirming biases. But that’s another giant thread.

Reply on news.ycombinator.com