"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.
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?
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.)
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?
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?
