> 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.
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.