3 ms·

> can we also bring back walk-on hiring? This used to happen in the 80s. I went to interview at a startup company in Mountain View in 1987. There was some chit

> can we also bring back walk-on hiring? This used to happen in the 80s. I went to interview at a startup company in Mountain View in 1987. There was some chit-chat then the interviewer asked me to wire-wrap a circuit (diagram was provided) and power it on and connect it up to the logic analyzer - he went away for about 1/2 an hour while I did that. He came back and complemented me on my neatness. Then he took me over across the room to talk to the VP of engineering who, after a few minutes of chit-chat, asked me when I would like to start. Those were the days.

eastbound 4y ago
Pretty much my interview process. I ask them to program a contains(string, substring), then come back 30 minutes later to code scattered all over the place, sometimes with “// 54 upvotes http://stackoverflow.com/…” http://stackoverflow.com/…”, code not compiling, and I’m still wondering whether I should accept them. I wonder what’s so hard with my interview. 5 years ago, even interns could do it, one of them could even tell the difference between UTF-8 and UTF-16.
- IggleSniggle 4y ago
  Maybe the problem is that nobody needs to solve that problem in their jobs anymore? For the last few months I've had the joy and privilege to really get to know the TCP and TLS stack intimately, and find myself looking for the patterns that are going to be most useful for handling data bit by bit. But prior to that, I really needed to care much more about the semantics (and the engineering culture around them) and the large scale structure of my code. I might get more hung-up/distracted by `contains(string, substring)` vs `string.contains(substring)` than what the actual operations to achieve it might be. And also, "surely this problem is already solved, optimally" aligns with one of the 3 great programmer virtues: A Great Programmer is Lazy. 30 minutes is unfortunately exactly the wrong amount of time if somebody has fallen into this trap. Anyway, I guess it depends what compute layer you're interviewing for, but it doesn't necessarily sound like your interview process is broken, exactly. Like, it could be testing for the right thing, but in the absence of that thing, maybe you just need to find another thing that is substitutable.
  - eastbound 4y ago
    Our real algo: We save a bunch of objects, but some of then exist in the DB, so you need to intersect what’s in the DB with what’s in memory before saving, except you can never hold all of the db at once. It should be our real-life test, but it’s too long. It’s our most complicated algo, and honestly it’s very simple in the end. But given all the variables scattered around in a string.contains() (I don’t even look whether the result is correct, I look whether it’s structured for intelligibility and how they debug the off-by-1 errors), I can’t suppose a more complex algo will be done cleanly. Maybe I’m mot giving them their chance - It might have taken time for me to output clean algorithms.
    - virtualwhys 4y ago
      `upsert`, not sure how having someone implement `contains` is going to help solve your IRL problem optimally, but I guess the interview process is more about testing cognitive strength vs. practical experience.

eastbound 4y ago

Pretty much my interview process. I ask them to program a contains(string, substring), then come back 30 minutes later to code scattered all over the place, sometimes with “// 54 upvotes http://stackoverflow.com/…” http://stackoverflow.com/…”, code not compiling, and I’m still wondering whether I should accept them. I wonder what’s so hard with my interview. 5 years ago, even interns could do it, one of them could even tell the difference between UTF-8 and UTF-16.

IggleSniggle 4y ago
Maybe the problem is that nobody needs to solve that problem in their jobs anymore? For the last few months I've had the joy and privilege to really get to know the TCP and TLS stack intimately, and find myself looking for the patterns that are going to be most useful for handling data bit by bit. But prior to that, I really needed to care much more about the semantics (and the engineering culture around them) and the large scale structure of my code. I might get more hung-up/distracted by `contains(string, substring)` vs `string.contains(substring)` than what the actual operations to achieve it might be. And also, "surely this problem is already solved, optimally" aligns with one of the 3 great programmer virtues: A Great Programmer is Lazy. 30 minutes is unfortunately exactly the wrong amount of time if somebody has fallen into this trap. Anyway, I guess it depends what compute layer you're interviewing for, but it doesn't necessarily sound like your interview process is broken, exactly. Like, it could be testing for the right thing, but in the absence of that thing, maybe you just need to find another thing that is substitutable.
- eastbound 4y ago
  Our real algo: We save a bunch of objects, but some of then exist in the DB, so you need to intersect what’s in the DB with what’s in memory before saving, except you can never hold all of the db at once. It should be our real-life test, but it’s too long. It’s our most complicated algo, and honestly it’s very simple in the end. But given all the variables scattered around in a string.contains() (I don’t even look whether the result is correct, I look whether it’s structured for intelligibility and how they debug the off-by-1 errors), I can’t suppose a more complex algo will be done cleanly. Maybe I’m mot giving them their chance - It might have taken time for me to output clean algorithms.
  - virtualwhys 4y ago
    `upsert`, not sure how having someone implement `contains` is going to help solve your IRL problem optimally, but I guess the interview process is more about testing cognitive strength vs. practical experience.