> and in most cases programmers who are comfortable with the command line version are also the ones who are better at writing code

These two statements indicate to me that you are ineffective at communicating what skills you are looking for in a programmer.

The reason they are coding a sorting algorithm is that you're interviewing a programmer for a programming position. The assumption is that they are being tested on the knowledge in that domain, which includes sorting algorithms.

If I answered the exact same question by putting the file lines in a data structure and calling Sort() in someone else's interview, I might be thrown out for not giving them the actual algorithm that Sort() implements.

Or maybe you just want people calling system()/exec()/execvp() or whatever. I dunno.

I needed to get some work done on a remote machine. I didn't have time to download and re-install graphics drivers so I just soldiered. GNU Screen, elinks, vim, ssh, rsync, irssi, et al. I was amazed how much distraction free actual programming I could do. On an aesthetic full-screen bash console, no less. Was even have tempted to setup Gmail in pine.

Until I needed a browser to test a layout. Finally, I had reached the limits of CLI. Believing I could merely surf to amd.com, download the appropriate tarball (linux x64 supported), unpack install reboot and rejoin modern civ.

Fired up elinks, went to amd.com and was properly re-buffed. There was a javascript "system detection" routine that could not be bypassed to navigate directly to the download urls!

In the end, apt saved the day. Moral of the story: always test your http works in elinks, please ;)

Although, I do actually totally agree that the more a person knows about the CLI in general, the better they sometimes appear to be. I feel like learning to use command line tools also sort of inspires that general DRY attitude about software in general. Don't reinvent the wheel!

"I am looking for the candidate who can give me this simple command line solution [...]"

I live at the command line. I spent a year at a gig maintaining 90k lines of bash. And yet I think I stand a substantial chance of failing this test.

Not because I am incapable of trivially producing the line in question (even without recourse to the manual). But because interviewers usually aren't looking for "I would run the code someone else wrote to solve your problem". Of course, in practice, reusing code is great - and that should be the answer where it's applicable! But in an interview asking for a solution to a problem where existing code cannot be the bulk of the solution is likely to be too big a question.

Generally, programmers who are afraid of the command line aren't very good at putting textual commands into a program text file, either.

They will cling for dear life to code generators and other such facilities in an IDE. (but not the good kind of code generators that define an original source DSL to be expanded into otherwise unseen code by the build process itself, always the IDE based code generators that generate mountains of crap code that now must be read and saved in source control)

They will cling to rigid, bloated, frameworks that require that they fill in parameters in an XML file, and write (many, scattered) tiny pieces of code to fill in the blanks for that framework, but which allow little variation from the application style which the framework mandates.

Beware the illiterate, programmer, grunting at cave paintings on the wall (clicking pictures on the screen, only).

See also: Pragmatic Programmers - power of text/shells sections; Neil Stephenson - "In the Beginning was the Command Line" essay.

I do believe that a programmer ignoring the CLI would not go far, it's not a MUST know it is a HAVE TO know.

First it is about tooling, you will unlikely use a programming language that does not work first on the command-line: the compiler(s), even for non-compiled languages like JS things like grunt, gulp, closure, etc. are part of what you have to know to be efficient.

But most importantly it is about the Unix tools philosophy, the classic "do one thing, and do it well", when you do know how those different tools are unique independently but can also connect (pipe) with each others it helps tremendously to write better code in general.

Last but not least, every single languages we take for granted now (like PHP, Python, Ruby, etc.) have all started with the CLI and with CGI, the basic abstraction of standard I/O (as in stdin, stdout) is the root of many many more complex problems.

I don't see how a programmer could have a deep understanding of HTTP for example if he/she does not grasp the CLI first, sure you may not need it all the time or to know it that deep but really knowing the details of the CLI is a bit like knowing a bit of "assembler", it is a layer of tech you really HAVE TO know to become really really good opposed as to just know enough to write some code and make it works.

Now to test it like that in an interview I would go more blunt about it "do you know the CLI, give me examples how you use it (or which tools) in different daily programming tasks?", anything CLI-related that shows knowledge of the operating system, of the compilers or other programming tools, of automating tasks, etc. is imho a sign of a damn good developper, any lack of it is probably a sign that you are either a junior dev (didn't discovered the CLI yet) and certainly not senior (can't be if you don't know the CLI).

I'm not going to take the challenge as I have the opposite problem. Since I wrote software for 20 years before I had a GUI, I find myself using the CLI too much in certain cases. I've been trying to learn more of the hot-keys for the windowed tools that I do use ... and how to do some of my CLI tasks in a windowed environment.

One curious note: I could live with 8.3 file names (since I did for years) but I ditched Mac OSX because I couldn't tolerate it being case-insensitive.

Nowadays I have a half-decent machine but I still keep resource usage low where possible. The only 'GUI' application I use on a regular basis is the web browser. Media is handled by cmus/mpv.

Widescreen monitors make it easy to have a permanent tmux sidebar. So 20-30% of the screen is made up of terminals at all times, the rest can be a web browser/IDE. Or, three panes side by side with terminals at left, vim at centre, firefox at right.

I find it cathartic. It's also really easy to knock together scripts and run them with watch. For example I have one that shows me clockspeeds, battery life, uptime, etc and takes up 2 lines on the screen.

I also find hotkey based navigation easier than futzing around with the mouse - goes doubly when i'm working mobile on a laptop.

also contrast the submission with this post: http://pgbovine.net/command-line-bullshittery.htm

If you know the name of the command you need, read the man page. If you don't, search for the man page using apropos. If you don't know how to use apropos, read its man page.

Although, forgoing the web browser might do more for your productivity than anything else...

/me closes HN

Maybe because one does not need to change the way he/she is interacting with machine?

Onemonth.com is in a very similar space and the conflicting names will likely hurt you.

It stimulate creativity like nothing else.

I literally expect to see people like this writing about how they're experimenting with punch card input any day now.

This is the difference between being a craftsman or being an academic. If you're a craftsman, you'd better know how to use your tools well. They're not an "obstacle" in the way of interesting research. They're a means to an end in accomplishing a goal.

At some point one should realize not every programmer is a computer scientist. Many of us are so much of computer scientists as a carpenter is an architect. For those of us who like to build things rapidly, familiarity with the posix shell and variants is a huge asset.

If what you are using is in a mature (not likely a field of research) domain, then yes, just click on install.exe and grunt (click) at [Next] once or twice, or on *nix go to Debian/Ubuntu style package manager and click on "install that" (and all its dependencies). BUT, if what you are doing is research that involves some newer tools, you might have to get a little bit dirty.

Maybe we can have a discussion about "dialog box bullshittery" (or registry bullshittery)? And how if you are stuck in that tar pit, there is no easy way out such as rolling up a tar of several packages which includes a top level "install.sh" script. You simply have to include the instructions of all the dialogs in a sequence and all the arcane buttons, checkboxes and radio buttons to be selected "just so", of you're SOL.

Yeah, cry me a river about the mean old command line.

There's some interesting comments in the "anti-forward" of the Unix Hater's Handbook suggesting that the "former prisoners" offer some commentary about the "facilities" to which they have been reassigned. ... "a system whose content and tone are set by Sonic the Hedgehog" indeed :-)

Why? Because if I want to program in Racket, I install DrRacket, and then I run it, and now I am programming in Racket. When I want to run my program, I click run.

The end.

Whereas with basically every other language out there there is indeed a whole wall of bullshit in between me and just writing some goddamn code.

First I have to install the language. If I'm on Linux, this probably means installing a package from my distro's package manager, unless of course I'm on Debian or something, in which case that's the last thing I want to do because it's probably out of date anyway, so I go hunting for an alternate package somewhere. If I'm on Windows, if I'm lucky there's a standard installer and it goes without a hitch, except almost none of them ever set the path properly so now I have to dive down into the environment variables to make sure cmd.exe can actually find my compiler when I need it.

Next, I need an editor, because of the contemporary languages present, virtually none of them actually include one, and the ones that do are usually terrible. So now I have to find an editor or IDE I can stand, then whatever plugin I need for it to properly recognize my language syntax, and there's a good chance the latter is only available for Emacs or Vim, neither of which are exactly a trivial learning curve.

So now I have my language, and I have my editor, and it's time to start coding, right? Oh my no. Turns out I've picked one of the increasingly common languages that basically requires you to set up a package or project file before you can even start writing the bloody thing, so now I'm diving into making sense of Leiningen syntax or hunting for and then configuring Visual Studio templates, just so I can doodle out a quick script.

And now, if I'm lucky, I finally start coding! But now I've done some coding, and I want to actually run my program (hope you got your path set right!), which means I need to know what arcane series of compiler flags I have to pass in just to get the damn thing to run a file, and if anything goes wrong there's always the chance that rather than being able to just click "stop" and halt the process, it will instead hang my entire system with a runaway thread because I typoed an if statement somewhere in one of my loops.

Compare all this to Racket: Download Racket, install Racket, run DrRacket from convenient shortcut or commandline, write code, run code. It's the first language since QBasic that's really got it right.