Arguably, this will result in a slower result in most cases, but the reason for the rejection is wasting developer time (not to mention time to test for correctness) to re-develop something that is already available in the OS.
Interviewer: "Welcome to your hammer-stuff interview, hope you're ready to show your hammering skills, we see from your resumé you've been hammering for a while now."
Schmuck: "Yeah, I just love to make my bosses rich by hammering things!"
Interviewer: "Great, let's get right into the hammer use ... here's a screw, show me how you'd hammer that."
Schmuck: (Thinks - "Well, of course, I wouldn't normally hammer those; but I know interviewers like to see weird things hammered! Here goes...")
[Hammering commences]
Interviewer: "Well thanks for flying in, but you've failed the interview. We were very impressed that you demonstrated some of the best hammering we've ever seen. But, of course, wanted to see you use a screwdriver here in your hammering interview at We Hammer All The Things."
However, I've never found a use for it. Apparently it was written for the Version 7 Unix build system to sort libraries for passing to the linker. And still used.[1][2] But of the few times I've needed a topological sort, it was part of a much larger problem where shell scripting was inappropriate, and implementing it from scratch using a typical sort routine isn't that difficult. Still, I'm waiting for an excuse to use it someday, hopefully in something high visibility so I can blow people's minds.
[1] https://github.com/openbsd/src/blob/17290de/share/mk/bsd.lib... [2] https://github.com/NetBSD/src/blob/7d8184e/share/mk/bsd.lib....
Not to mention that these days people often ask ChatGPT "what's the best way to do this" before proceeding, and whatever you ask in interviews is completely irrelevant.
It is exactly for these reasons we never ask such questions in our interviews. There are much more important aspects of a candidate to evaluate.
It costs me more effort to read and understand a screenful of unfamiliar code than the equivalent "sort -k 1.1" or "uniq" while skimming through a shell script. This adds up.
> It costs me more effort to read and understand ...
You don't need to. LLMs are meant for that. You probably will roll your own script anyway and none of this matters.
You are worrying about things that, in my experience, do not make any noticeable impact on overall productivity.
They are tricky and not very portable. Sorting depends on locales and the GNU tools implementation.
For example my python interpreter imports my custom List and Path classes and I could just do the following to get the same result:
List(List(Path("filepath").read_text_file().splitlines()).group_by_key(lambda x:x).items()).map(lambda x:(len(x[1]),x[0])).sorted()
and if used often enough, it could made an utility method:
Path("filepath").read_sorted_by_most_common()
So I find it shortsighted to reject someone based on that without giving them a chance to explain their reasoning.
I think generally people really underestimate how much more productive you can be with a good utility library.
List(List(Path("filepath").read_text_file().splitlines()).group_by_key(lambda x:x).items()).map(lambda x:(len(x[1]),x[0])).sorted()
sorted((count, line) for (line, count) in Counter(Path("filepath").read_text().splitlines()).items())
Sure, but you can do that for any functionality in any practical language.
What happens when everybody comes to the job with their own utility library and start working on the same codebase?
Would you like it if you had to get up to speed with several utility libraries your coworkers developed for themselves?
A common set of tools, like the Unix commands, makes it easier for people to collaborate. They were put in an official standard for a reason.
What is the definition of wasting developer time? If a developer takes a 2 hours break to recover mental power and avoid burnout, is it considered time wasted?