Retiring a Great Interview Problem
thenoisychannel.com
Retiring a Great Interview Problem
1–10 of 122 posts
Re: Retiring a Great Interview Problem
#2A spiritually similar question at a previous employer resulted in many candidates attempting to iterate over the dictionary rather than iterating over the string. We hired them. At least they could iterate over a dictionary. That's a surprisingly rare skill in the hiring pool.
Maybe I'm just getting cynical in my old age, but sometimes I think the world is awash in incompetence. We see so much of it in tech because our incompetencies are (marginally) harder to hide.
Re: Retiring a Great Interview Problem
#3A spiritually similar question at a previous employer resulted in many candidates attempting to iterate over the dictionary rather than iterating over the string. We hired them. At least they could iterate over a dictionary. That's a surprisingly rare skill in the hiring pool. Maybe I'm just getting cynical in my old age, but sometimes I think the world is awash in incompetence. We see so much of it in tech because o…
Many years ago ('97) we had a Java programming test for new hires that included a question that involved iterating over a Hashtable containing String keys and values and printing them all out.
Nobody ever answered that question correctly and I used to joke that if anyone ever did we'd hire them immediately.
NB I've long since stopped using those kind of trivia questions in interviewing, but I didn't know any better at the time.
Re: Retiring a Great Interview Problem
#4Its a great question. Pretty sure its not nearly as much of a secret as the author thinks though. I've seen a detailed write-up before somewhere (HN?) and I'm not even a programmer by profession.
Re: Retiring a Great Interview Problem
#5The problem he's having is that good interview questions are getting busted, as people post solutions on the web.
If you have a lot of similar interview questions, then there's no way anyone other than a savant can memorize them without actually learning the theory.
Re: Retiring a Great Interview Problem
#6Just for fun I decided to rewrite his first version in Haskell. This is probably not idiomatic, though.
segment_string :: String -> Set String -> Maybe String
segment_string [] _ = Nothing
segment_string str dict =
if str `member` dict
then Just str
else let pairs = zip (inits str) (tails str)
pairInDict (x, y) = x `member` dict && y `member` dict in
do (x, y) Re: Retiring a Great Interview Problem
#7A spiritually similar question at a previous employer resulted in many candidates attempting to iterate over the dictionary rather than iterating over the string. We hired them. At least they could iterate over a dictionary. That's a surprisingly rare skill in the hiring pool. Maybe I'm just getting cynical in my old age, but sometimes I think the world is awash in incompetence. We see so much of it in tech because o…
Many years ago ('97) we had a Java programming test for new hires that included a question that involved iterating over a Hashtable containing String keys and values and printing them all out. Nobody ever answered that question correctly and I used to joke that if anyone ever did we'd hire them immediately. NB I've long since stopped using those kind of trivia questions in interviewing, but I didn't know any better a…
I'm sorry, my Java is rusty; is this the equivalent of the Python
print("\n".join("%s: %s" % (key, value) for key, value in mydict.items()))
Re: Retiring a Great Interview Problem
#8Only slightly joking:
re.findall("(your|dict|here)", "yourword")
Re: Retiring a Great Interview Problem
#9The author just mentioned dynamic programming. Usually in dynamic programming, e.g., as in Dreyfus and Law, to say that a problem has a dynamic programming solution we outline the solution. But the author did not outline such a solution.
An outline usually includes at least the definition of the 'stages' of the dynamic programming solution. For the problem of 'string segmentation', the obvious selection of stages would be each of i = 1, 2, ..., n for the given string of length n. But this definition of the stages does not yield a dynamic program because the solution at stage i needs more than just the solution at stage i + 1 and, indeed, potentially needs the solutions at each of stages i + 1, i + 2, ..., n.
So, first-cut, there is no dynamic programming solution. For a second-cut, there might be a dynamic programming solution if the author would outline one!
There is now some question if the Google interviewers really understand dynamic programming!
Re: Retiring a Great Interview Problem
#10Earlier quoted context omitted.
Many years ago ('97) we had a Java programming test for new hires that included a question that involved iterating over a Hashtable containing String keys and values and printing them all out. Nobody ever answered that question correctly and I used to joke that if anyone ever did we'd hire them immediately. NB I've long since stopped using those kind of trivia questions in interviewing, but I didn't know any better a…
I'm sorry, my Java is rusty; is this the equivalent of the Python print("\n".join("%s: %s" % (key, value) for key, value in mydict.items())) ? If so, is it hard to do in Java?
No, it's really not - even with the java.util.Hashtable class that was all that Java had at the time. I think it was something that people from a C,C++ background didn't really expect to be able to do.