undefined | Better HN

0 pointsjameshart3y ago0 comments

The author calls out several points where it's usually necessary for the interviewer to explain something to the candidate - or rather, to push them to have the insight you want them to have to progress the interview. Too bad if they have other insights they want to share! The interviewer needs you to buy into his view that the time it takes to generate your hash keys is an important part of your big-O analysis of this problem!

The danger here is that when you explain something to someone, and they get it, you get a warm fuzzy rush of happy brain chemicals. You will feel well-disposed towards candidates who appreciate and enjoy taking the breadcrumbs you feed them. Candidates who didn't think your clever insights were as clever as all that, or who fail to respond to your tutelage and try to solve it their own way... you'll get a negative feeling towards them. They're not playing your game.

That's great if you're interviewing a student to figure out if they will enjoy learning from you, and you will enjoy teaching them!

But while teacher/learner relationships might be part of your relationship with colleagues at work, it seems an odd part of the relationship to compatibility filter in an interview.

0 comments

6 comments · 2 top-level

yongjik3y ago· 4 in thread

Yeah, sorry, I don't think I'm following your argument. When you compute hash keys of a string, of course you want to read the whole string at least once, so the time complexity is at least O(N) (where N is the length of the string) - sure it's easy to overlook, but once explained there's not really much to disagree. It's not like the interviewer is asking a matter of opinion and punishing those who have different viewpoints.

Also, once you used the same problem half a dozen times in interviews, you no longer get any "warm and fuzzy" feelings for having to explain something which is now blindingly obvious to you: if anything, you'll give higher scores to candidates to whom you don't have to explain such things.

Of course, if you are a candidate and (hypothetically) your response is "Actually it can be less than O(N), because a hash function does not have to read the entire string, and I know how it works because I've been dealing with string hash functions for years in my professional career," then by all means, fire away, I'm pretty sure any reasonable interviewer would consider it as a big plus sign.

jameshartOP3y ago

It’s O(n) in an n that doesn’t matter.

The length of that word does not grow arbitrarily long, causing the asymptotic behavior of your algorithm to dominate. Because it’s a word.

In the case of ‘is this word of length n the result of concatenation two English words’, the time complexity as n approaches infinity is constant, because once you get past floccinaucinihipilificationantidisestablishmentarianism, any longer word than that you can just return ‘false’ immediately.

krackers3y ago

Right, for all practical purposes if the reader assumes the words are from the English language, you can assume that comparisons will be constant (both from the pedantic CS perspective since words are bounded in length, and also from a practical perspective since the bound is small, and with SIMD can be done fast enough for most words). See also responses from https://news.ycombinator.com/item?id=35550842 and https://news.ycombinator.com/item?id=35551114 which say the same better than I could.

It feels really disingenuous when interview questions start off posing a seemingly innocent problem where the intuitive and practical answer is usually the one that'd you go for if you wanted to implement this in the real-world, then as soon as you answer the interviewer turns around and throws a hidden assumption at you. You could argue that the point of the interview is to have the candidate suss out these things, but it's usually a one-way discussion where you're not allowed to even question if the assumptions make sense in the real-world (which is what you ultimately care about).

And if the words are truly big enough to be an issue then you better start being rigorous and benchmarking different approaches rather than just handwaving big-o.

Ultimately when you get down to it, the whole point seems to see if the interviewee can be led down the pre-determined golden path, even if the path is only fools gold.

yongjik3y ago

I see, yes I think you do raise a very good point, but on the other hand, the issue could be quickly resolved by talking about it. Any good interviewer would say something like "Ah yes that's a very good point, I forgot to consider the implication of the English vocabulary. However, for the sake of this interview, let's assume the 'vocabulary' is made of strings that can be arbitrarily long. Does that change your answer?"

After all, if we assume that all words are at most, say, 50 characters long, then there's no asymptotic complexity to speak of. Any string longer than 100 characters is trivially not a concatenation of two words.

planede3y ago

Have a rolling hash and compute all hashes of the prefixes in one go, in O(N). Per-prefix cost of hashes gets amortized to O(1).

bolanyo3y ago

Absolutely right. I once had an interview where the interviewer asked me for a way of calculating pi, along certain specific lines. When I didn't get it, he 'explained' to me how such an approach could work. I pointed out correctly that his idea was wrong. I was rejected. I'm pretty sure that he never found anyone who came up with this approach just based on the initial vague prompt, and was actually interested in people who nodded in an impressed way when he explained his idea.

j / k navigate · click thread line to collapse