Hacker News Reader

Comment by Quarrelsome | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com