> A person who has code fluency can create the algorithm in the language of your choice, pretty much on the spot.

I've professionally used each for a year or more C#, Python, Javascript, Objective-C, Java, PHP, Visual Basic, and ActionScript over the years. But if you asked me to write a function in anything but the first three languages, I will almost undoubtedly stumble a bit in producing them (hell, I still have to look up syntax for Python periodically).

That doesn't mean I couldn't pick them back up in a future job very quickly again (each job I worked for I was usually contributing to their code base in a few days, never longer than a week), it just means I don't have them fresh in my head and I can't store absolutely everything in my head forever.

But you'd still probably think I was incompetent. I've certainly given that impression before when I had an onsite scheduled by a recruiter and given less than 24 hours notice for an Objective-C job, a language I hadn't touched or thought about in over a year, and was handed a laptop by a Junior Programmer and was told "Code up an app for me." while another interviewer sat quietly across the table from me and stared at me the whole time while I refreshed on a years worth of XCode changes and forgotten syntax in real time.

After that wonderful performance they didn't give much weight to the two employees in their department that worked under me at a previous startup I was Lead Programmer for and vouched for my skills.

> I've professionally used each for a year or more C#, Python, Javascript, Objective-C, Java, PHP, Visual Basic, and ActionScript over the years. But if you asked me to write a function in anything but the first three languages, I will almost undoubtedly stumble a bit in producing them (hell, I still have to look up syntax for Python periodically).

It is for exactly this reason that if I'm interviewing you and want to know if you can code or not I will ask you to write up an algorithm rather than a program. I might say, "Show me the algorithm for locating a node in a binary tree, now do the same for a hash table. Now how would you insert into each of those?" And then, as many programming languages do, I try to tie one of your hands behind your back, "Ok so the language you're going to use doesn't have pointers" or "memory allocation" etc.

But I only interview that way because I see computer programming languages as an impediment to expressing what you really want the computer to do. And people who can code, first and foremost understand exactly what needs to be true for the code to work, then when they run into limitations of the language figure out ways to express those same concepts given the limitations.

If you were being mean you could add limitation after limitation until you were down to a minimally touring complete system. And if they can still make it do what you're asking, then they really deeply understand how to get computers to do what ever they want them to do.

I agree with every criticism that "coding tests" should not be about whether or not your syntax is accurate or you have the standard library memorized. I explained to a colleague at Google once that having total mastery of English grammar doesn't make you a writer.

I wouldn't think you incompetent if you didn't have the syntax at your fingertips.

But here is the rub, if the interviewer doesn't know how to code they can't reliably test for that ability in others. When I hear or read stories like yours I wonder about who the company has put in charge of interviewing these candidates and what biases are they bringing to the situation.

I think what you described here is all too frequent and, frankly, infuriating. Obviously not the right way to hire people, but more profoundly, I think it reflects poorly on the collegiate nature of our profession.