I was really enthusiastic about a recent interview, because the process started with a take home coding assignment that I thought I did well on and got me invited for a 4+ hour interview. But then the in person interview session ended with asking me to write a simple program in an unfamiliar IDE and language while they talked at me - they called it "pair programming". I am utterly unable to work anything out if I can't have intermittent peace and quiet. So, the verdict was accurate (in a tautological sort of way) that I wasn't a good fit, but clearly they have preconceptions that are preventing them from hiring useful people.
One thing to keep in mind though, is that whenever you're dealing with a lot of similar trials of something, avoiding all the big mistakes is more important than getting all the big successes. I think this applies to hiring people, choosing investments, relationships, probably other things. So having irrational reasons for rejecting people is less harmful than having irrational reasons for accepting people. Which is probably an important reason why free markets don't automatically eliminate the prejudices we consider unacceptable.
Did they tell you it was going to be pair programming or was it a surprise? I find things like this are better to practice beforehand or if one knows beforehand one would prefer not to do it, to just reject it before it gets that far along in the process.
"Pair programming" in an interview wasn't something I'd seen before, so I didn't prejudge it. I'm still not sure what to think of the exercise - because it may or may not resemble what is actually done on the job.
From a previous HN thread on pair programming[1]:
"Both partners must be fairly versed in the language and methodology of the programming."
I got into the weeds with the minutiae of the editor pretty quickly. Figuring that out and the language and the program in a few minutes while maintaining a conversation about all of the above is far beyond my limit of simultaneous tasks. It's not about the difficulty of any of them, it's about the contention for locks, if you will.
Also from the article it links to:
"Navigator knows the system well while the driver does not" is described as a fairly good situation. This jumps out at me because (presuming I was the driver and interviewers were navigating) in actual driving situations, I really don't function well with someone telling me what to do and carrying on a conversation at the same time as I the driver am trying to exercise higher brain functions.
It may be there is a segment of the programming population that uses mathematical processing brainpower for programming, and another segment that uses verbal processing power, and the disconnect here is that I am in the latter category. Thus, while talking is very helpful to me to work out a problem, I can't talk about one thing while doing another because they both require my verbal faculties. Maybe people who multitask better are using different parts of the brain that are inherently more independent.
I've done it before and it can be difficult to get into a flow state that is more natural for me by myself but like all things requires practice to acquire and maintain skills and also, familiarity as you say, with the tools and problem space or it's not a very good assessment of your ability except for that one very particular set of circumstances of going in blind on tools/editor!
One thing to keep in mind though, is that whenever you're dealing with a lot of similar trials of something, avoiding all the big mistakes is more important than getting all the big successes. I think this applies to hiring people, choosing investments, relationships, probably other things. So having irrational reasons for rejecting people is less harmful than having irrational reasons for accepting people. Which is probably an important reason why free markets don't automatically eliminate the prejudices we consider unacceptable.