[mikestew]

If you're the kind of shop that would rather write your own code than use third party libraries, then that's a really great sign that I shouldn't work there.

Do keep in mind that you're eliminating the places that wrote that "third party library" in the first place. Libraries don't just grow on trees (though they can help you navigate a tree).

Just a few weeks ago I had to knock out a test framework, creating an API from scratch (basically an object model on top of some websockets messages), because there's no library that's going to do what we need. Oh, I friggin' abused Python's import keyword to hell and back, but there was a lot of stuff that just needed to be written from scratch. Given there are a few tree-like structures, I'm sure I briefly weighed depth-first vs. breadth-first before hammering out the code. And this is nothing exotic, just a small company working in the industrial controls industry. And such a task is nothing exotic, it's why they hired me. But I think to effectively create something like this in an efficient manner, having at least a rough idea of something like BFS is table stakes.

One is not being asked to implement a red-black tree on a whiteboard, just something that I think a competent software developer could come up with from first principles. A company asks you, "which direction will you be searching, and how would you do that?", and you'll reject them. I mean this with due respect: you're probably right, neither party will want you to work there, and the filter worked. Hurray?

I'll tell you what grates me, though: the companies that insist they need someone like that, and then the new employee finds out that the culture is so borked, that said employee will never get to actually do that stuff. "We need test infrastructure." Turns out the reason they don't have any isn't for lack of someone to write it, it's lack of culture to do anything with it. As just one example.

[zanny]

If I had to write a fresh impl of BFS I for sure wouldn't just go off what my algorithms book said a decade ago. I'd reference how other languages and frameworks have implemented and matured the problem in actual deployment and use their versions as a basis of mine (assuming license compatibility).

Writing code in a vacuum is humongously dangerous even for simple things like piping strings. Its why so much C software ends up chock full of overflows, segfaults, and myriad security vulnerabilities.

[zentiggr]

All good reasons for not getting stuck in front of a whiteboard redoing the unprotected unoptimized core of just the basic algo.

Wouldn't it be nice to be able to use references / existing implementations while at the board being watched and timed.

[zanny]

At least then it wouldn't be purely artificial. I'm not surprised at all that there are so many people "bad" at technical interviews when they are fundamentally designed to leave you a fish out of water. Nobody likes to flounder, but some people it shakes much more than others.

But I wouldn't think for a second those people would be incapable of being good team members or productive coders. You just let them stay in their comfort zone and approach uncertainty in the ways they are comfortable with. They will know the best way they can approach solving a problem, and if you were testing for that instead in these interviews, they wouldn't be so harmful to participation in tech by "minorities" such as women or people of color.