Hacker News Reader

Comment by budman1 | Hacker News Reader

quitting vi is a basic competency test.

would you listen to a doctor that could not suture a cut? how about a mechanic that could not remove a socket from a ratchet?

simple file editing. vi has been around for every. if you haven't seen it, and needed it at least once, what have you been doing?

(personal anecdote: once had an engineering VP bring up that a stray ":wq" in a document was a sign of a real engineer...working outside of where he should be..)

View on HN

It's more of a cheap gotcha than a valid test. If we take somebody like me, I learned to code in IDEA/PyCharm, these days mostly code with either Zed or OpenCode, and occasionally drop into nano and Positron. I wouldn't be able to do anything in Neovim without looking it up simply because I had no reason to learn it. A doctor who learned practices appropriate in the 20th century might now necessarily be hired for knowledge of these practices today.

I'm certainly not listening to someone who thinks vi is used by every developer

used. maybe not. but cognizant of it. sure. and having used it once or twice.

come on! you are a software expert and you never had to edit a file on a machine where claude was not available?

what would you say about a EE that could not use a scope?

i would say that analogy was made by someone who seems to labour under the misunderstanding that you can only write code from within vi.

I'd say, their degree is BS. You can't finish Uni as a EE, without using a scope a few times.

what if I told you some people weren't baptised into the unix ecosystem. Wild, I know.

aside from gedit and geany and nano and emacs and notepad and vsc and notepad++ and sublime text and...

I’d been developing with emacs for years before I learned how to quit vi. Just means he’s never had to change the config on a remote server with a barebones setup :-)

> quitting vi is a basic competency test.

no, its pop quiz bullshit. Oh you know about ":wq"? Well done! But if you don't know, you do it a few times and now you know. It does nothing, outside of teaching you a bit about poor UX.

> if you haven't seen it, and needed it at least once, what have you been doing?

using one of the other available ides?

> once had an engineering VP bring up that a stray ":wq" in a document was a sign of a real engineer...working outside of where he should be..

That's not a sign of good judgement, that's a sign of being technically fashionable. It's hipster shit, akin to rejecting a candidate because they're a fan of Taylor Swift and don't know who the band Tool are.

What distinguishes knowing about vim from knowing about virtually anything else? If you apply to a job in tech, you should know that by long-pressing the power button, your PC turns off. Is this pop quiz shit, too? The bar is ridiculously low these days, apparently.

are you being sarcastic? Its nothing like the power button. Everyone has to press the power button but not everyone has to use Vi.

:wq is one of the most insane key combinations to quit an app and this is just hipster shit where people who use vim think they're the only "real engineers". It's just a disgusting level of arrogance and masturbation. The code is what matters, not the IDE. To focus on it as a sign of technical excellence makes a mockery of what engineers are supposed to care about (comp sci things) and replaces them with all the elegance of a high school bully belittling some other kid for not wearing Nikes.

It's not about using vim, it's about when you had to sudoedit a config on a server you visited the first time, and it had vim as default EDITOR, so you have to know how to exit it and open nano, or whatever you use. It's about exposure, exposure to many small things is a sign of experience, it is experience, to be precise. If they don't know small basic things, it's a sign, they don't have relevant experience. Can also check, if they have empty lines at the end of their files, know how to remove docker images from their machine, or get a TCP/UDP joke.

Its about people wanting to hire themselves. It's a cognitive bias we all suffer from. Being completely unaware of it and purity testing others based on your own experience, is: to be precise, a lack of experience in realising that other people can be just as good as you but took a completely different path to get there.

Nah, I bet they suck, why can't they do what I've already done?

Yes, this is the bias we are looking for. If you can't quit vim, don't know how your frontend communicates with your backend, can't type on a regular qwerty keyboard without looking at letters, or navigate UI without mouse, never used a debugger, don't know how to check if it was DNS, can't write a spec for a feature, after talking to stakeholders (and defend it's priority on their behalf), or don't know how to open dev tools in your browser - you are not ready to herd the cats yet, they will herd you off the cliff instead. And that's okay, you'll get there someday.

I couldn't breathe before I learned how to quit vim. Its surprising just how fundamental it is.

Okay, how about having the problem-solving skills to figure out how to exit vim when you inevitably encounter it? Sounds like a reasonable middle ground to me. Do you disagree with this?

(FWIW I agree with pavlus.)

I still think you're just trying to hire yourself and its kinda gross. Its like being British and refusing to hire someone that doesn't read or know about theregister.co.uk. Sure, most people probably should but there might be a great dev out there who don't and its extremely cruel to "other" them.

Does vim always happily tell you that its running? It used to be the default diff tool on devices I worked with and IIRC it was just a blank shell in some cases, so it might be non-trivial to work out if you're in it, without knowing it.

So yea, its probably interesting as a challenge but it doesn't prove shit, outside of "you like vim". I like Jetbrains products but I wouldn't assess someone's ability based on how someone might use the products, but rather what they create by using them.

Since you are denying the importance of baseline exposure (consequently accumulated experience), I will just say this: if you are unable to figure out how to quit vim, it absolutely proves quite a lot about your experience. If you do not think that problem-solving skill is valuable, I do not know what to tell you.

Edit: you keep heavily editing your comment so I will leave this as-is. FYI, you are the only one talking about gatekeeping.

I had been sole technical owner for many distributed solutions for industry, as well as responsible for like ~20% of code running my nations transportation infrastructure before I learned how to quit vim. So that makes me think you're full of shit and lack the imagination to consider any other paths except your own.

Are you telling me that when you got vim opened, you panicked and could not figure it out in a relatively short timeframe?

FWIW I still maintain the belief that it is usually a decent indicator of whether you have got the experience to work through unfamiliar tools. It is often a good sign, although not a guarantee.

When vim auto opened the bloke next to me doing my induction told me I needed to type ":wq" and then made a joke about how unintuitive it is.

> FWIW I still maintain the belief that it is usually a decent indicator of whether you have got the experience to work through unfamiliar tools

if you just said that in the first place I'd agree, but that's different. Good engineers are brave and able to just dive into some unknown to get the job done. I'm sure there's been plenty of times where we've been thrust into scenarios where we have to use unfamiliar tech to solve an issue or throw up some infra. However, personally I've never _had_ to use vi, so its not come up, but that's probably because my background is very much a windows one, not a linux/unix one.

Fair enough.

> Good engineers are brave and able to just dive into some unknown to get the job done.

I agree. We (I) do it all the time.

Just to circle back on the "pop quiz" point: do we agree that asking loosely relevant trivia questions is not the most effective way to assess ability? I would argue it is more meaningful to be given a task and the space to solve it. To be honest, I do not know how to implement heapsort off the top of my head, but I know how to look up its pseudocode and how it works, and from there, I can translate that into working code.

> that's probably because my background is very much a windows one, not a linux/unix one.

Yes, that explains it. I find no issue with that at all. What matters is the ability to bridge gaps when needed.

> do we agree that asking loosely relevant trivia questions is not the most effective way to assess ability?

yeah. I been interviewing recently and the best interviews are those most like the job, where you either go in on-site and pair with some toy example, or get given some awful existing code and be given an amount of time to achieve a particular goal within that code.

The conversations that fall out of such exercises after they're completed are probably more valuable than the exercise itself.

Nailed it!

You probably don't want a CIO who knows vim.

Reply on news.ycombinator.com