What I like most about this is how close to reality their interview model is. Less than stellar equipment, legacy code, and a maintenance task... just a normal Monday.
Good times.
Of course, that's not true at all. But giving someone a defective-but-not-entirely-broken tool can be a clever way of seeing how they work around problems or how they deal with frustration. Joking aside, we once let a guy go during his 1 week probationary period because he got a little too angry at a slow server. It's a valuable test.
If the "w" key weren't working I'd copy-paste "w" characters from elsewhere in the document, or bring up the on-screen keyboard. Writing bastardized code -- for (;;), really?! -- would be a huge negative against a candidate. And, of course, if a company really didn't have a working keyboard to provide me with, I'd never work there in the first place, because if they can't even provide working peripherals there's no limit to what else they might skimp on.
I actually have three keyboards at my desk right now -- one with Cherry MX blues, one with Cherry MX browns, and a Model M. No way in hell would I ever write code without "w"s.
#define ever (;;)But then computers were not provided, each school had to travel with a computer for each student. So around 1993/94 a friend of mine, who also had some terrible medial situation at the time, and was quite weak decided to compete, and to make things worse for him - his spacebar wasn't working. I think he did a lot of presses of Alt+32 (or was it Alt+20 - I haven't used this combination of entering ASCII codes in a long time). He finish pretty good for the situation and keyboard problem he had, and next year when he was healthy and with good keyboard he did just awesome!
Unless you're from a very poor country there is no excuse for not having a working keyboard.
I don't know if that was part of the test, but if it was, it's worse than the big blue chip corps asking about the number of piano tuners. Which actually can be valuable at understanding how one reasons about unknown problems/areas.
About the server being slow, well I don't know the magnitude of the slowness or the anger, but unless you're a ramen fueled startup there is no excuse for having slow machines. It's management failure. It's a waste of developer time. Instead of coding the dev is having to deal with stress inducing constant 5 second hiccups or similar things.
Put yourself in the interviewee's shoes. Do you really want to work in a company that can't conduct a proper interview and has broken/slow hardware?
And yes, I do use vim and I do like w very much.
Slow is relative. The employee in question was trying to figure out why a remote server was experiencing extreme slowdown. He ssh-ed in, but he was able to type far faster than the beleaguered remote could echo his keystrokes. So he needed to just carefully type his commands, wait for them to appear, and then press enter. Instead, he typed angrily and too quickly, swore at the connection, and eventually started slamming his keyboard in a fit of pique.
It was a totally reasonable real-world slow machine problem, and a totally useful insight into the mindset of a potential new employee.
Not egregious at all. We're developers, sometimes we have to walk into an annoying situation and deal with it like adults.
>Joking aside, we once let a guy go during his 1 week probationary period because he got a little too angry at a slow server.
If someone's approach to a broken keyboard is some workaround instead of just asking for another keyboard it is a sign they handle problems very, very poorly.
(And then make a preprocessor run where \/\/ is replaced with a w)
I have a keyboard with a broken 'w' key myself, and I know exactly why that key cap died young. It sure wasn't from typing out "while".
It was a great interview experience though. One of the engineers commented that they gave the same task to other interviewees too.
I think this is a smart and lazy way to hire people :P No need to spend an hour in the room asking random questions, having awkward pauses etc. Just let the candidate fight with the codebase - lazy and simple!