5 ms·

You were supposed to know why a particular implementation of a tool was fast beforehand? Or they gave you GNU grep and BSD grep to compare?

taeric 12y ago
Yeah, this definitely falls into the absurd category of interviewing whiteboard questions. Ridiculously absurd. I have a book with this algorithm detailed in it, and I think I would still have trouble implementing it well. That or I am just dumb. Very likely.
- perdunov 12y ago
  I wonder where that douchebaggery culture among employers comes from.
  - nikanj 12y ago
    These are often the same companies that complain about how hard it is to find 'talent'
- tedunangst 12y ago
  "Let's implement BM" (with some hints/guidance) doesn't seem absurd. It's not much code; handwritten can fit on a piece of paper or two. "Why is GNU grep fast?" would definitely be an absurd question though.
  - perdunov 12y ago
    Okay, let's suppose a software engineer cannot implement the BM off the top of their head. What would you make of that? How relevant is this kind of testing to the actual work of a software engineer?
    - tedunangst 12y ago
      Like I said, with hints and guidance. Write a function to find a substring. Ok. What's its runtime? Can we make it faster? What if we skip ahead a bit after a failed match? How much? What's the fastest way to calculate that?
  - taeric 12y ago
    I could understand possibly going through sections. Though, really, that form of algorithm coding is so different from what I typically do day to day, that it just seems irrelevant. I would probably find it fun, provided the hints/guidance were good. Not sure what to expect of it, though. As the sibling post asks, what would be the takeaway?
    - tedunangst 12y ago
      Is the candidate capable of decomposing a problem and analyzing subproblems? Are they capable of integrating subsolutions back into a working whole?
      - taeric 12y ago
        The problem really comes down to expectations on your point. For many of us, this would just be knowing that there are good algorithms on doing this. If you don't already know of this algorithm, finding it is something that took a surprisingly long time to do. Using a field of algorithm design (pushdown automata) that just isn't that widely utilized nowdays. (Well, I suppose your domain may vary in this claim.)
- rdc12 12y ago
  Curious to know which book that is, could you tell me please?
  - taeric 12y ago
    The book I've got is Knuth's Selected Papers on Design of Algorithms.[1] I will confess that I do not have the book with me, so it may actually be a different algorithm in that text. I can not remember. :( Going off of here[2], the algorithm I am referring to is chapter 9, "Fast pattern matching in strings." [1] www.amazon.com/Selected-Papers-Algorithms-Language-Information/dp/1575865823/ [2] http://www-cs-faculty.stanford.edu/~uno/da.html http://www-cs-faculty.stanford.edu/~uno/da.html

taeric 12y ago

Yeah, this definitely falls into the absurd category of interviewing whiteboard questions. Ridiculously absurd. I have a book with this algorithm detailed in it, and I think I would still have trouble implementing it well. That or I am just dumb. Very likely.

perdunov 12y ago
I wonder where that douchebaggery culture among employers comes from.
- nikanj 12y ago
  These are often the same companies that complain about how hard it is to find 'talent'
tedunangst 12y ago
"Let's implement BM" (with some hints/guidance) doesn't seem absurd. It's not much code; handwritten can fit on a piece of paper or two. "Why is GNU grep fast?" would definitely be an absurd question though.
- perdunov 12y ago
  Okay, let's suppose a software engineer cannot implement the BM off the top of their head. What would you make of that? How relevant is this kind of testing to the actual work of a software engineer?
  - tedunangst 12y ago
    Like I said, with hints and guidance. Write a function to find a substring. Ok. What's its runtime? Can we make it faster? What if we skip ahead a bit after a failed match? How much? What's the fastest way to calculate that?
- taeric 12y ago
  I could understand possibly going through sections. Though, really, that form of algorithm coding is so different from what I typically do day to day, that it just seems irrelevant. I would probably find it fun, provided the hints/guidance were good. Not sure what to expect of it, though. As the sibling post asks, what would be the takeaway?
  - tedunangst 12y ago
    Is the candidate capable of decomposing a problem and analyzing subproblems? Are they capable of integrating subsolutions back into a working whole?
    - taeric 12y ago
      The problem really comes down to expectations on your point. For many of us, this would just be knowing that there are good algorithms on doing this. If you don't already know of this algorithm, finding it is something that took a surprisingly long time to do. Using a field of algorithm design (pushdown automata) that just isn't that widely utilized nowdays. (Well, I suppose your domain may vary in this claim.)
rdc12 12y ago
Curious to know which book that is, could you tell me please?
- taeric 12y ago
  The book I've got is Knuth's Selected Papers on Design of Algorithms.[1] I will confess that I do not have the book with me, so it may actually be a different algorithm in that text. I can not remember. :( Going off of here[2], the algorithm I am referring to is chapter 9, "Fast pattern matching in strings." [1] www.amazon.com/Selected-Papers-Algorithms-Language-Information/dp/1575865823/ [2] http://www-cs-faculty.stanford.edu/~uno/da.html http://www-cs-faculty.stanford.edu/~uno/da.html