8 ms·

> If you ask the candidate the define the requirements for the task you're going to give them, you can't be surprised if the candidate imagines a use case with

> If you ask the candidate the define the requirements for the task you're going to give them, you can't be surprised if the candidate imagines a use case with entirely different requirements from what you expected! This section really resonated with me. I've had a few interviews where I came up with a different answer than what the interviewer expected and this resulted in a lot of tension, as the interviewer asserted they were correct with zero exception. This often led to a lot of dead-end scenarios and the interviewer trying to get me to see an alternate solution without telling me explicitly. I once had an interviewer tell me that O(k) was constant if k was a config parameter (I disagreed because in practice, k would need to be tuned as a function of the size of the data, and it would be like saying O(n) is constant if you just fix n = 1M), and an interviewer tell me that you could solve an optimization problem without an objective function (in actuality, he had an objective function, he just thought it was obvious and didn't want to specify it). In both cases, I understood what they were trying to get at after they explained their solutions, but in the process it was incredibly frustrating as they seemed to just disregard my answer all together.

baddox 9y ago
I love interview horror stories! In my most recent job search, which was early this year, I debated with one interviewer whether checking for key existence in a hash was a constant time operation. I insisted it was, and the interviewer insisted otherwise with the same amount of conviction. That was just a small portion of an all-day onsite interview. After leaving, I was told they were looking for a more senior candidate. I was not upset.
- jerryr 9y ago
  Wouldn't that argument be easily settled by discussing the implementation of a hash table?
  - baddox 9y ago
    I discussed it briefly. My interviewer was unpersuaded, and the other interviewer in the room (who wasn't performing this interview) suggested we just move on. I believe the unconvinced interviewer was simply a very junior developer and an even more junior interviewer. He seemed quite nervous.
    - kevmo314 9y ago
      One of the worst interviews I've had the interviewer was not only similarly incorrect, but then afterwards proceeded to try to give me advice on interviewing skills, and how I should've "taken his hint" and been "more amenable to other answers". I probably would've been open to alternate answers if they were, y'know, factually correct.
      - zaphirplane 9y ago
        Thinking you are awesome because you know the answer to a question you have prepared for and asked many times, is one of my minor irritant
      - SilasX 9y ago
        If you think that's bad, I was this guy[1]. tl;dr: 1) Interviewer insists that an operation must be n^2 "because it has a nested loop" even though the nested loops are only iterating over their own subset of the master string. 2) Interviewer refuses literally any test that would help decide which of us is right. 3) Interviewer turns out to not even understand the concept of resolving disagreements by appealing to agreed-upon facts, insisting that he would only be convinced by the absence of a nested loop (i.e. talking about some other algorithm). 4) Interviewer is five-year backend lead. 5) Interviewer vetoes me from the rest of the process purely because of that disagreement. 6) Because I thought I was going insane, I implemented it at home and ran the problem with different sizes and the run time with up as O(n) like clockwork. [1] It's okay, I'm fine with people knowning and have outed myself elsewhere: https://news.ycombinator.com/item?id=6070001 https://news.ycombinator.com/item?id=6070001
        baddox 9y ago
        > Interviewer turns out to not even understand the concept of resolving disagreements by appealing to agreed-upon facts That's a wonderful description of an attitude I have encountered many times.
- GeneralMayhem 9y ago
  Could just be a terminology mismatch. Checking for hash existence should always be constant, but checking for key existence is generally only amortized constant (that is to say, not constant across all lookups) - he may have wanted you to talk about addressing schemes and degradation at high load factors?
  - baddox 9y ago
    There was no subtle argument. It only came up because I was on the whiteboard solving some simple word game that involved matching user input against a list of valid words (e.g. the Scrabble dictionary). When asked to explain the running time of the various operations, I said that we can store the dictionary in, well, a dictionary, and checking whether the user input is a valid word will be a constant time operation. The interviewer insisted, with no subtle argument about amortization or collisions or addressing, that this was in fact a linear time operation.
    - fencepost 9y ago
      So likely thinking of it in terms of checking a tree based on characters instead of hashes of full words. Which is more viable would likely depend on what kind of memory constraints and dictionary size was being considered. Also very implementation dependent, what's the size of the hashes generated? Edit: curiosity got me looking at this for Python, with an answer of "it depends, and both have correct aspects" based on Python's implementation [1]. The hashing varies by string length, the lookup is fixed unless there's a collision and probing, probing will be minimized by growing the dictionary as items are added. In any case, better than O(n) but worse than O(1) and with some possible slowdowns during loading unless you can set an expected final size during initialization. Edit again: since I brought it up, turns out initialization doesn't really matter, resizing is not a speed factor. Relevant discussion starts from https://stackoverflow.com/questions/1298636/how-to-set-initial-size-for-a-dictionary-in-python https://stackoverflow.com/questions/1298636/how-to-set-initi... [1] http://www.laurentluce.com/posts/python-dictionary-implementation/ http://www.laurentluce.com/posts/python-dictionary-implement...
      - 9y ago
- Jabbles 9y ago
  It can also depend on whether you count the O(k) time needed to hash a string of length k.
- jon_richards 9y ago
  My favourite was an interview (in Java), where the interviewer said I needed to process some data (something abstract like a "record") and that I could assume I get my data in a "var". I asked what sort of data structure the variable held. He said "It's a var. You know what a var is, right?" So many problems...

baddox 9y ago

I love interview horror stories! In my most recent job search, which was early this year, I debated with one interviewer whether checking for key existence in a hash was a constant time operation. I insisted it was, and the interviewer insisted otherwise with the same amount of conviction. That was just a small portion of an all-day onsite interview. After leaving, I was told they were looking for a more senior candidate. I was not upset.

jerryr 9y ago
Wouldn't that argument be easily settled by discussing the implementation of a hash table?
- baddox 9y ago
  I discussed it briefly. My interviewer was unpersuaded, and the other interviewer in the room (who wasn't performing this interview) suggested we just move on. I believe the unconvinced interviewer was simply a very junior developer and an even more junior interviewer. He seemed quite nervous.
  - kevmo314 9y ago
    One of the worst interviews I've had the interviewer was not only similarly incorrect, but then afterwards proceeded to try to give me advice on interviewing skills, and how I should've "taken his hint" and been "more amenable to other answers". I probably would've been open to alternate answers if they were, y'know, factually correct.
    - zaphirplane 9y ago
      Thinking you are awesome because you know the answer to a question you have prepared for and asked many times, is one of my minor irritant
    - SilasX 9y ago
      If you think that's bad, I was this guy[1]. tl;dr: 1) Interviewer insists that an operation must be n^2 "because it has a nested loop" even though the nested loops are only iterating over their own subset of the master string. 2) Interviewer refuses literally any test that would help decide which of us is right. 3) Interviewer turns out to not even understand the concept of resolving disagreements by appealing to agreed-upon facts, insisting that he would only be convinced by the absence of a nested loop (i.e. talking about some other algorithm). 4) Interviewer is five-year backend lead. 5) Interviewer vetoes me from the rest of the process purely because of that disagreement. 6) Because I thought I was going insane, I implemented it at home and ran the problem with different sizes and the run time with up as O(n) like clockwork. [1] It's okay, I'm fine with people knowning and have outed myself elsewhere: https://news.ycombinator.com/item?id=6070001 https://news.ycombinator.com/item?id=6070001
      - baddox 9y ago
        > Interviewer turns out to not even understand the concept of resolving disagreements by appealing to agreed-upon facts That's a wonderful description of an attitude I have encountered many times.
GeneralMayhem 9y ago
Could just be a terminology mismatch. Checking for hash existence should always be constant, but checking for key existence is generally only amortized constant (that is to say, not constant across all lookups) - he may have wanted you to talk about addressing schemes and degradation at high load factors?
- baddox 9y ago
  There was no subtle argument. It only came up because I was on the whiteboard solving some simple word game that involved matching user input against a list of valid words (e.g. the Scrabble dictionary). When asked to explain the running time of the various operations, I said that we can store the dictionary in, well, a dictionary, and checking whether the user input is a valid word will be a constant time operation. The interviewer insisted, with no subtle argument about amortization or collisions or addressing, that this was in fact a linear time operation.
  - fencepost 9y ago
    So likely thinking of it in terms of checking a tree based on characters instead of hashes of full words. Which is more viable would likely depend on what kind of memory constraints and dictionary size was being considered. Also very implementation dependent, what's the size of the hashes generated? Edit: curiosity got me looking at this for Python, with an answer of "it depends, and both have correct aspects" based on Python's implementation [1]. The hashing varies by string length, the lookup is fixed unless there's a collision and probing, probing will be minimized by growing the dictionary as items are added. In any case, better than O(n) but worse than O(1) and with some possible slowdowns during loading unless you can set an expected final size during initialization. Edit again: since I brought it up, turns out initialization doesn't really matter, resizing is not a speed factor. Relevant discussion starts from https://stackoverflow.com/questions/1298636/how-to-set-initial-size-for-a-dictionary-in-python https://stackoverflow.com/questions/1298636/how-to-set-initi... [1] http://www.laurentluce.com/posts/python-dictionary-implementation/ http://www.laurentluce.com/posts/python-dictionary-implement...
    - 9y ago
Jabbles 9y ago
It can also depend on whether you count the O(k) time needed to hash a string of length k.
jon_richards 9y ago
My favourite was an interview (in Java), where the interviewer said I needed to process some data (something abstract like a "record") and that I could assume I get my data in a "var". I asked what sort of data structure the variable held. He said "It's a var. You know what a var is, right?" So many problems...