I'd love to read an honest post from somebody from Twitter (or GitHub or...) on why they don't support IPv6. Not a shaming thing, it's something I don't quite get. Like I get why an old school bank wouldn't: their infrastructure predates IPv6 and it's a project that has to be financially justified and I can understand how that can be hard. But presumably something like Twitter had an experienced networking team, who surely know all the advantages here and want to somewhat future-proof, build up their infrastructure and they decided not to support IPv6 and I would love to understand the reasoning. Is the extra cost really that high?
I have no special insight, but it's probably something like "we're working on it, but there are lots of legacy things that expect v4 (including non-obvious like anti-abuse systems) and since all our users have some sort of v4 connectivity it's not urgent".
I am guessing the reasoning goes like this: if we only support IPv4, then it's on all these ISPs with IPv6-to-IPv4 CGNAT to make sure their stuff works properly (and chances are they will notice if it doesn't). But if we support IPv6, it will be on us to make sure people behind those ISPs can still reach us (because hardly anyone goes via this IPv6 route and if it doesn't work it's likely nobody at the ISP will notice).
IPv6 is also usually faster than ipv4 these days, because the overhead of fragmented ipv4 routing is large. In the past it was slower because of lack of understanding/support for it from larger ISPs, and consequently poor routes, or really suboptimal tunneling setups.
Saying this method of interview is not 100% effective so it's useless is not a great argument. Reality is that bad hires are really expensive (as argued above) and that current interview methods are somewhat - admittedly not 100% - effective at avoiding those while mostly - again not 100% - effective at admitting the great hires. Maybe this "convert to discussion" method is more effective (I have my doubts), and I'm sure there are more effective methods out there and we should look for them, but let's recognize the reasons for what we have while we look for something better.
Your comment makes no sense to me - you're saying we shouldn't blame open source but in the same breath say that anyone who uses open source without carefully reviewing and auditing every line of code is an idiot who can't even do FizzBuzz. I'm a developer and if I'm faced with the choice of auditing every line of code in a dependency or just writing what I need I'll just write what I need nine times out of ten. Honestly your position is closer to the article than you seem to realize.
There's a huge difference between compelling not lying vs compelling disclosure. We do require disclosure in some cases like in the ingredient example you mention, but even the it's limited to what's necessary: companies don't have to disclose exact recipes and can hide a lot behind the "flavorings" label for example. I'm not sure if forcing disclosure in this case is good, but I do like keeping a high bar on that in general.
