4 ms·

Read in a file full of numbers, one number on each line Represent those numbers as integers in your program Replace each number with that number times its lin

Read in a file full of numbers, one number on each line Represent those numbers as integers in your program Replace each number with that number times its line number Write the file out elsewhere And complete the task right now at your computer as fast as possible, you’re being timed 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!"

merry-year 13y ago
"leading teams" is very different from "coding 80 hours a week" 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.
benhoyt 13y ago
I've been interviewing a fair bit lately, and I just really struggle with what you say above. To me if you can't write that simple program in some language without looking at an API or consulting Google at every turn, it feels like you haven't used the language enough (either that, or the problem isn't in a domain your familiar with, but you can usually tell which it is pretty quickly). 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.
- OhHeyItsE 13y ago
  And that's where we disagree. I think this whole "FizzBuzz" craze is as equally stupid as the riddle craze was. 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.
- WildUtah 13y ago
  What about * 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? Should an interviewee just have all those APIs memorized in advance? Even in this age when reading an unformatted text file is so far from common?
- TheCoelacanth 13y ago
  It's surprisingly easy to make it a long time without needing to read from a file. If you're writing web apps, you almost never read directly from a file; all of the input comes from a database or HTTP requests.
tracker1 13y ago
I'd probably reach for node.js for something like this... 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') ); Easy peasy. That's off the top of my head so fs syntax may not be correct. I'd probably give it a quick run through in the node repl to start with. 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.
- benhoyt 13y ago
  Really, that's easy peasy? Looks terrible to a Python programmer. :-) 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))
  - biscarch 13y ago
    I would've went with Haskell myself ;) 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)
- deckiedan 13y ago
  I think you would really enjoy learning some other languages. You obviously understand programming concepts really well... but, node.js for this? really? Even C is less verbose than that JS...: #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); } which reads stdin, and writes to stdout. 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...
deckiedan 13y ago
In some ways it's more of a system admin/ops task than a 'programmer' one. #!/usr/bin/python import sys with open(sys.argv[1]) as f: for l, i in enumerate(f): print l * int(i) We keep MD5 file lists of all files we archive to tape before we delete them. Today one of our editors found some footage, and we needed to know if those files had been archived already. It was a couple lines of bash, and then a 10 line python script. 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.
blindhippo 13y ago
A good interviewer would never ask a question like this and expect actual code written in a proper language. Rather, they would ask for pseudocode and to have the interviewee to walk them through it. If the person can't explain how the code should work, it doesn't matter how much of the syntax or API they have memorized. I doubt it's hard to find good people - it's much harder to find good interviewers.
EliRivers 13y ago
Read a repetitively formatted text file line by line and do something relatively simple with it? It's just begging to be done with awk. awk '{print $0 * NR}' fileOfNumbers > output I did use > to dump the output to file. Should that count as bash-fu?
sukuriant 13y ago
Do people actually have interviews where they're required to read in a file? I would figure in this world, especially where most of our information is from a database, this type of code is either abstracted away or written in one or two places. 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"
chronomex 13y ago
nl input | sed -e 's/$/*p/' | dc > output
alanl 13y ago
I would normally have to look it up on google or within my existing code base. 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.

merry-year 13y ago

"leading teams" is very different from "coding 80 hours a week" 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.

benhoyt 13y ago

I've been interviewing a fair bit lately, and I just really struggle with what you say above. To me if you can't write that simple program in some language without looking at an API or consulting Google at every turn, it feels like you haven't used the language enough (either that, or the problem isn't in a domain your familiar with, but you can usually tell which it is pretty quickly). 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.

OhHeyItsE 13y ago
And that's where we disagree. I think this whole "FizzBuzz" craze is as equally stupid as the riddle craze was. 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.
WildUtah 13y ago
What about * 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? Should an interviewee just have all those APIs memorized in advance? Even in this age when reading an unformatted text file is so far from common?
TheCoelacanth 13y ago
It's surprisingly easy to make it a long time without needing to read from a file. If you're writing web apps, you almost never read directly from a file; all of the input comes from a database or HTTP requests.

tracker1 13y ago

I'd probably reach for node.js for something like this... 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') ); Easy peasy. That's off the top of my head so fs syntax may not be correct. I'd probably give it a quick run through in the node repl to start with. 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.

benhoyt 13y ago
Really, that's easy peasy? Looks terrible to a Python programmer. :-) 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))
- biscarch 13y ago
  I would've went with Haskell myself ;) 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)
deckiedan 13y ago
I think you would really enjoy learning some other languages. You obviously understand programming concepts really well... but, node.js for this? really? Even C is less verbose than that JS...: #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); } which reads stdin, and writes to stdout. 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...

deckiedan 13y ago

In some ways it's more of a system admin/ops task than a 'programmer' one. #!/usr/bin/python import sys with open(sys.argv[1]) as f: for l, i in enumerate(f): print l * int(i) We keep MD5 file lists of all files we archive to tape before we delete them. Today one of our editors found some footage, and we needed to know if those files had been archived already. It was a couple lines of bash, and then a 10 line python script. 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.

blindhippo 13y ago

A good interviewer would never ask a question like this and expect actual code written in a proper language. Rather, they would ask for pseudocode and to have the interviewee to walk them through it. If the person can't explain how the code should work, it doesn't matter how much of the syntax or API they have memorized. I doubt it's hard to find good people - it's much harder to find good interviewers.

EliRivers 13y ago

Read a repetitively formatted text file line by line and do something relatively simple with it? It's just begging to be done with awk. awk '{print $0 * NR}' fileOfNumbers > output I did use > to dump the output to file. Should that count as bash-fu?

sukuriant 13y ago

Do people actually have interviews where they're required to read in a file? I would figure in this world, especially where most of our information is from a database, this type of code is either abstracted away or written in one or two places. 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"

chronomex 13y ago

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

alanl 13y ago

I would normally have to look it up on google or within my existing code base. 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.