1. 4

  2. 2

    Why, when I log in with GitHub, does this need permission to “read [my] private email addresses”? My GitHub profile’s public email address should be enough to identify and contact me. You promise that you “won’t post on your wall or message your friends”, but promise nothing about sending newsletters to or selling my private email addresses. Without an explanation, and with only two more free questions being offered, I’m not going to risk logging in.

    The question I got before being asked to log in was compress-url-list. It’s a good, interesting question that made me remember some CS theory stuff that would be useful in an interview. But the “Gotchas” when you click “I have an answer” was poorly written and actually led me away from the answer. It says

    The strategy I came up with doesn’t take a hit on runtime.

    That led me to think my answer was not what he was thinking of. But it actually was – my and his answer was to use a trie. The “gotcha” is poorly stated: compared to a dumb hash table, where you look up visited["www.example.com/products/311"] and get true, it will be slower to use visited['w']['w']['w']['.']['e']['x'] … ['3']['1']['1'] = True, even with a trie stucture implemented using pointers. This is because it is slower (I’m guessing) to find and follow len(url) pointers than to compute one hash of the whole string and look it up in the table. Or perhaps my estimation is wrong, and it is faster to follow all those pointers – but then the site should at least explain that, somewhere in the long explanation of tries they have as the answer.

    1. 1

      (I have emailed the site owner linking to the above and this feedback, which explains the amount of detail in it.)

      I tried another question, largest-stack, by visiting the site using another computer. Their proposed solution for it is actually totally wrong. They ask for a stack with methods to push, pop, and get the stack’s largest value. Easy enough. Then they say they have a solution that gives O(1) time for all three operations – but I couldn’t think of any way to accomplish that. It turns out that the solution they describe in their answer accomplishes that by being buggy and giving the wrong answer in some cases. Here is a translation of their Python-like pseudocode to Ruby. It gets an error when you push a number because its logic fails to account for an empty list (it’s an error in their code, not the translation). But fine, leaving out edge cases might be forgiveable in pseudo-code. But here is a running version of their algorithm with that error fixed. If you run that and push 1, 5, and 3 in that order, then pop, it tells you that the largest element is 5. Their solution is just wrong – as I predicted when I evaluated that approach while trying to answer the question. It feels unfair that I thought of the solution they hint at, and dismissed it as wrong, and then the site suggested it as the correct answer anyway.

      With two mistakes in two questions, I can’t trust any of Interview Cake’s hints – I can only rely on the questions to better myself. I did like the questions – they were good at making me think, and remember CS theory. But the site really needs to review its hints and its answers for accuracy and clarity. Though at least the site is easy to use and the text is easy to read. Interview Cake is still very buggy, but if you’re willing to be skeptical of and do indepdent research on its hints and answers, then trying to answer its questions might still help you prepare for interviews anyway.

      The site’s questions are good, but it really needs to review its hints and its answers to be correct and clear. The site is a mixed bag – helpful questions but wrong answers. Though at least the site is easy to use and the text is easy to read.

      1. 1

        Whoops, never mind, I was wrong. I don’t know what I was thinking, but their proposed solution for largest-stack is correct. Maybe I was too tired last night. I thought the behavior of the stack in the situation I described was incorrect, but it is correct – after removing the 3, the largest element remaining is 5. For some reason I thought that the 5 should be removed, and 3 would be the largest remaining.

        The only problem with their solution was that is not Python (has a keyword Class, uses Stack without importing it), but it uses a Python-specific feature: that any value is greater than the None you get when you peek() an empty stack. I tried the equivalent in Ruby, saw it didn’t work, and assumed it wouldn’t work in any language. So the edge case of pushing to an empty stack is handled if you convert the Python-like code to actual Python, but not to some other languages.