Think—what language would you immediately reach for? Do you start your experimentation with ipython, or irb? Do you pop open Eclipse and write some Java? Or create a new .cpp file?

I have 13 years of experience leading teams in building and designing web applications in a wide variety of languages and platforms - some pretty big ones, too.

I would not be able to do this in any language without looking at the API.

And they wonder why "It's so hard to find good people!"

I don't deduct points for not getting the syntax precisely, but if they don't know the very basics of "open()" and "for line in file" and "int()", but say they have 3 years Python experience, I'm thinking No Hire.

My brain, right now, is working on a way to pop messages off of a RabbitMQ queue onto a clustered pool of Akka workers while minimizing the duplication of work and avoiding race conditions in the output.

My career experience is in Java with a sprinkling of Python. I honestly cannot recall off the top of my head the I/O Api to do that task. Let alone on a whiteboard or in some shared google doc.

Hm, I need to open a file. OK, no problem - new java.io.File(path). Er, wait, I remember there's a FileReader. Probably should use that. Do I need a File first? Or can I just give FileReader the path? Ah, shit - I need to read each line. I think that's a BufferedReader. How do I get from a FileReader to a BufferedReader? Is it constructor param? Wait, maybe FileReader _IS_A_ BufferedReader.

So, I 'fail' the interview with you. Maybe your company has a need for someone who can write a 10 line script that can read a file line by line without having to look at the API while being timed. In that case, yes, you probably have weeded out a bad candidate.

     * Libraries for reading arbitrary size integers

     * and for computing with arbitrary size integers

     * Efficiently handling files larger than RAM

     * Error handling when the file is not as promised?

    #!/usr/bin/python
    import sys
    with open(sys.argv[1]) as f:
        for l, i in enumerate(f):
            print l * int(i)

I can write this kind of thing with my eyes shut.

You need problems like this, but also big architectural ones to really get an idea where someone is at.

    var fs = require('fs');
    var lines = fs.readFileSync('./somefile.txt','utf8')
      .trim().split(/\r\n|\r|\n/g);
    for (var i=0; i<lines.length; i++) {
      lines[i] = i * +lines[i];
    }
    fs.writeFileSync(
      './outfile.txt'
      ,'urf8'
      ,lines.join('\n')
    );

Why JS, I find that this type of scenario begs for a language that does coercion well... say what you will about JS, it does do that.

   with open('input') as fin, open('output', 'w') as fout:
       for line_num, line in enumerate(fin, 1):
           fout.write('{0}\n'.format(int(line) * line_num))

    main :: IO ()
    main = writeListAsLines . toDoubleList . lines =<< readFile "nums.txt"
           where
             toDoubleList y = zipWith (*) (map read y) [1..length y]
             writeListAsLines z =  writeFile "output.txt" (concat $ intersperse "\n" $ map show z)

    #include <stdio.h>
    int main(void){
        unsigned int lineno=0;
        char line[1000];
        unsigned int number;

        while (fgets(line, 999, stdin)) {
            sscanf(line, "%u", &number);
            printf("%u\n", number * lineno++);
        }
        return(0);
    }

I'm sure the C may not be perfect, I've not really used it in years. Node for a task like this is a bit like using a Nimitz Class Aircraft Carrier to hammer in a nail...

    var i=0
        ,stream = require("stream")
        ,rl = require('readline').createInterface({
            input: process.stdin
            ,output: new stream.Writable() 
        });
    rl.on('line',function(line){
        process.stdout.write(((+line || 0) * ++i) + '\n');
    });
    process.stdin.resume();

IDEs like Visual Studio and Idea will show you classes, methods and parameters as you type. You only need to know which namespace to use for a given operation.

In the interviews I've been in, none of them required that I load information from a file, usually I only wrote the function that did the real (algorithmic) work. Only one of them required me to write code that compiled; and that was a SQL question.

Even TopCoder doesn't require you to "read a file full of numbers"

But, I still think its a good idea to refresh yourself on stuff like this before hand, because in an interview:

- you don't need the mental distraction from the real problem.

- you're always under time pressure.

- it's never a positive, if you don't know something.

awk '{print $0 * NR}' fileOfNumbers > output

I did use > to dump the output to file. Should that count as bash-fu?

  nl input | sed -e 's/$/*p/' | dc > output

E.g., "Oh, you want me to twiddle bits? Let's do this in C.", "Oh, now doing silly text file stuff? Ruby.", "Write a simple properties thingy? Javascript.", "Find all permutations of blah? Lisp or Scala."

I wonder how common that is.

According to the table about relative popularity of programming languages, Javascript (5.2%) and C# (5%) have only 5 times the popularity of Scala (1%) and Haskell (1.2%). In most contexts, this data is just wrong.

This just proves that unless you know or show the underlying method and context, quoting statistical summaries is almost completely pointless in trying to enhance your point.

I realize that this is probably being a bit pedantic as that graphic is hardly the main point of the article however it does tend to place a question mark over the rest of the article when a seemingly dishonest bit of data is used to help prop up other points.

Consider this great visualization of the most popular coding languages of 2013 from the interactive practice problem website CodeEval:

What are your thoughts about candidates who code correct solutions in a language not in use at your workplace?

I have a nagging feeling that some positions in my group have gone unfilled due to tech stack mismatches in candidates who were probably perfectly capable (or better) coders, but were most recently working in other tech stacks. Considering these types of candidates seems to be challenging in my workplace.

I think it's a big mistake to avoid hiring a Python programmer because they don't know Ruby, but it's one people seem happy to make, even in otherwise relatively enlightened organizations.

Exception: first jobs and very inexperienced people. Basically if the answer is given in a specific language because they don't know any other and couldn't produce the answer you want after short time of studying relevant docs, then it may be a real problem.

I suppose the only thing that would make me frown is if the candidate was evidently a huge language zealot and wanted to use nothing but their language of choice. But I've never interviewed such a person actually.

Well worth it if the alternative is hiring someone who knows the language/framework you're working in, but pretty much only knows that language/framework.

Writing in Python can be almost like writing in pseudocode.

Maybe that's changing, but I find it hard to believe.

So you are right about the doubt. Simply put, a lot of interviews tend to be fixed. Interviewees don't get to choose the PL to use during coding session. It is usually fixed. If you are interviewing for Java software engineer candidate, then coding in Python makes no sense. So that statistics does not reflect reality. It's merely to say that "Python and Ruby alike PL" are popular should the candidate has the right to choose a PL.