Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Not sure if this is a "subjective" question or not.

I'm thinking about hiring a mid level java programmer and came to the realisation that all the competent programmers that I've worked with had a very strong knowledge of their chosen editor.

My chosen editor is vim (sometimes I use it as a plugin in IntelliJ IDEA). So in the case that someone puts that they use vim to program with I was considering giving them a couple of quick tasks to see how they go about it.

Something that you could do in varying different ways. For example today I had a xml file with placeholder strings of the form

<?xml version="1.0"?>
   ${placeholder.here} some text ${placeholder.there} 
   and some more text ${placeholder.everywhere}

and wanted to convert it into a string that I could then paste as a java string array literal, sorted alphabetically. e.g.

["placeholder.everywhere", "placeholder.here", "placeholder.there"]

Has anyone used this kind or metric in their interview process and if so what were the results? If you did use editor ability as a metric, what editing tasks did you set? Any problems with using this as a indicator (obviously amongst other criteria) of ability?


migration rejected from stackoverflow.com Oct 1 '13 at 10:52

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, MichaelT, Dan Pichelman, Kilian Foth, Ozz Oct 1 '13 at 10:52

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Read this meta.stackexchange.com/questions/5234/… –  Nasreddine Oct 27 '11 at 20:41
Problems? Well, would you reject a candidate because he says he uses vim, but is not a wizard? –  R. Martinho Fernandes Oct 27 '11 at 21:21
I remember we hired one co-op who was AWESOME (fast and very loud typing, not too accurate though) at typing and was going off on how his favorite editor was vi. I'm sure he knew vi better than me and I could get by with it. After 3 programming tasks, all of which he failed miserably, he became our permanent lab machine reloader. I'd hate for you to get stuck with him because he passes your vi test. –  DXM Oct 28 '11 at 3:00
As a proxy for actual programming ability, text editor ability is almost as poor as etch-a-sketch ability. –  Rein Henrichs Oct 28 '11 at 5:52
You can use that metric ... if you don't mind getting an image of a manager who believes that coding is only about typing. –  mouviciel Oct 28 '11 at 8:54

9 Answers 9

Absolutely not!

Just to set it clear; I love Vim, use it almost every day, but a knowledge of the editor you cannot "grade". Why not? Several points:

a) not everyone uses Vim (okey, you mentioned this one) - so how does that compare them to others who do?

b) a large majority of people use a very limited functionality of Vim (for the first 10-15 years, I used it without plugins at all ... practically, with only the basic functionality that comes with it) - do they know it less than others? Obviously not. How will you compare them?

c) For those that are used to using it with plethora of plugins, will you let them install it? Plus python/ruby/perl support to go along with some of them?

d) Some of the best people I've ever worked with type very slowly (veeeeery sloo.oo..w ... wait for it ... ly) - yet, each of them could replace two without thinking. How do they rate in your test?

e) put me on a different machine with a different language layout keyboard and a different layout of keys (from my rather weird notepad keyboard, for example) any I guarantee my Vim skills will sharply take a direction towards the floor.

I could think of a dozens more reasons, but in the end ... it comes down to: with these in mind, and potentially many more what would be the point of such a test?

You're not hiring typists, you're hiring (I hope) programmers. Hire those think well, not type well.

+1 I completely agree. The limiting factor of your coding is the speed you think not the speed you type –  Tom Squires Oct 28 '11 at 8:11
+1 for 'Hire those think well, not type well.' Jeff Atwood seriously needs to read this answer! –  Gary Willoughby Oct 28 '11 at 21:16
@GaryWilloughby - Sorry? "Jeff Atwood"? –  ldigas Oct 28 '11 at 21:22
@ldigas, en.wikipedia.org/wiki/Jeff_Atwood He gets a bit upity about not being able to type: kalekold.net/index.php?post=12 You may of heard of him? He invented this site along with all the other stack-exchange sites. ;) –  Gary Willoughby Oct 28 '11 at 21:30
@GaryWilloughby - No, no :) I know who Atwood is. I just didn't get the reference. –  ldigas Oct 28 '11 at 21:38

I love vim, but would never consider knowledge of vim as an indicator of the candidate's quality. One of the best engineers I worked with uses only IDEs and types with two fingers.


Wanted: Programmer with 5+ years vim experience. Knowledge of Java also a plus.

Seriously, if you're looking for a Java programmer, find ways to discern how much Java they know. If vim experience is important to the job, then by all means test that as well. Otherwise, leave it alone.

If you don't care how the code ends up in a file, then the only reason to ask about vim is to try to catch someone in a lie.


If the guy specifically says that he uses vim? Sure, test him. But if he doesn't know every arcane feature, don't hold it against him.


Don't do it.

The best software developer I have ever met used this editor:


This guy absolutely refused to use any graphical tool. But he was able to do amazing things anyway.


Programmers should first think, then type. And have to type what they though. fast typing desn't necessarily mean "fast thinking", and "fast thinking" doesn't necessarily mean "good thinking".

It is the quality of the overall process you have to focus on. If the time I spent to type is less than 1/10 of the time I spent to think to an algorithm, being "faster in typing" is a "full cost" than doesn't allow to me to be better than 10% of what I am. Not a good investment.

If an employer use that as a test, that employer will be so disqualified in my perception, I can even be encouraged to fail the test and try a different employer and job!

Well, programming involve a lot of trial/error before comming up with the right solution. This cycle is greatily improved with editor mastery. –  deadalnix Oct 28 '11 at 12:35
@deadalnix: Not necessarilly true: sorry for the rudeness, but ... typing shit faster produces more shit, not better solution. It's the second thermodynamic principle. If you're lucky you can find something that works, but there is the serous risk that you don't know why it works. –  Emilio Garavaglia Oct 28 '11 at 17:20
@deadalnix: Programming by accident involves a lot of trial and error. Programming by design involves a lot of thinking (and the occaisonal correction of typos). –  Stephen C. Steel Oct 28 '11 at 21:29
Seriously guys ^^. yeah sure, you write prgrams right at the first shot. Yes, yes, I believe you ! No bugs at all, no need of testing, because you, you THINK ! Damn it, if everybody could do the same ! –  deadalnix Oct 28 '11 at 22:49
@deadalnix: No, my program don't runt at the first shot. But correcting them requires 80% of the time spent on the debugger, 10% to the compiler and 10% in typing. If I even emprove my typink skill to become 10 time faster, The percentage will become 88,11 and 1, qand the overall time will redic by only 10%. There is no clue in spending the effort of becoming 10 time faster, since I will never produce 10 times that. It's not a problem of how correct my programs are or can be. It just simple linear algebra. –  Emilio Garavaglia Oct 29 '11 at 19:36

The tools do not make the developer, testing them on a specific one is a poor metric as if they're a good developer they'll know to take the right tool for the job and adapt to it.


I would be more concerned with someone who cannot explain their thinking without making me guess. For example, when you say "convert it into a string", what do you mean by "it"? I presume you mean "${placeholder.here}", but that is an assumption. It could also mean the ENTIRE XML FILE (as shown). BTW, I would likely create a bash script using sed and sort. Much depends upon whether I would need to repeat the task.


Using an editor is a basic programming skill, so it is a rational thought process to say - "Hey, lets test this skill in our applicants."

You conjecture that would give you a better chance of getting a good hire since as you say the better programmers you have known were also skilled with their editors.

So you'll hire someone who is good with their editor for the increased likely hood they will be good at their job as well.

I can see both sides. The guy may be good, or he may put all his editor skills to work starting flame-wars on your team using TL;DR emails typed out whit those editor skills that helped him get the job.