7 ms·

I did an experiment while interviewing interns once. For half the group, I posed this problem: > Given a log file, with each line prefixed with either WARN, I

I did an experiment while interviewing interns once. For half the group, I posed this problem: > Given a log file, with each line prefixed with either WARN, INFO, ERROR or DEBUG, explain briefly how you would determine the number of errors logged assuming that each line corresponds to a single event and vice versa. For the other half, I posed the same question, but I said the log file was 50MB big. Most people didn't know how to solve the second problem even though given the scales involved the solution is essentially the same. (By the way, the question wasn't used as part of the criteria for the job)

imaginenore 11y ago
No, the solution is not the same. The 50MB one is easier, as it fits in RAM and we know none of the counts exceed 25 million. With the first one we don't even know if the counts fit into the standard numeric types.
- MichaelGG 11y ago
  Considering how easy it is to get a linear implementation, why would anyone choose to use a slower method?
TheLoneWolfling 11y ago
Those two are not equivalent. Actually, I'm surprised that people didn't find the first one harder: I've had log files that were larger than RAM before (mainly due to overzealous logging).
- userbinator 11y ago
  If the first thing your solution does is attempt to read the entire file into memory, then you probably failed the test. The same goes for trying to read an entire line into memory, however long it may be - this is a problem that can be solved with an essentially constant space of around a dozen bytes.
- kstrauser 11y ago
  Exactly! I've been asked the followup question: "now assume that you have 8 petabytes of log files to search", which leads into distributed computing, realtime vs on-demand collection, eventually consistent counters, the pros and cons of sampling vs exact counts, and so on. The unbounded form of that question can be astonishingly hard, and for the kinds of jobs I'd be interviewing for I'd expect the challenging next questions. I'd still answer along the lines of "for a quick solution I'd grep for the error level and count the number of lines, but that's not scalable".
  - TheLoneWolfling 11y ago
    Ditto. (Also, no need to pipe + count: `grep -c` works.) Also, problem with sampling: you oversample long lines. I'm not actually sure if there is any way to count probabilistically that doesn't. I suppose if you had some prior of how long the types were you may be able to do better, but in general, good luck.
ColinWright 11y ago
So: $ grep ^ERROR | wc
- wtetzner 11y ago
  $ grep ^ERROR | wc -l
  - ColinWright 11y ago
    Absolutely. I noticed that soon after I typed the other, but decided to leave it. Usually I'm passing the results to something else so it doesn't matter, but you're right, that produces just the number we want.
- zimpenfish 11y ago
  Or if you want to avoid a useless use of wc - $ grep -c ^ERROR
  - ColinWright 11y ago
    Hah! I'd completely forgotten about "-c". Thank you!
ilitirit 11y ago
The people who are replying and saying these problems are not the same because of the file size are are seeing the same type of illusion of complexity described in the submission. You count the number of lines you that begin with the word ERROR. That's it. At this scale, the tools you use are, for all intents and purposes, irrelevant. Saying that the files might not fit into standard numeric types is like writing a custom BigNum implementation when I ask you to write a program that adds two numbers because I might give you value that doesn't fit into an int. It's of course fine to raise it as a potential issue, which would also show you know the practical implications. But what about if I ask you to write FizzBuzz? Are you going to give me the simple answer, or write something needlessly complex because I might test your program with a value like -3x10^78? Perhaps I should have been clearer that the interns were fresh out of college, or part of a placement program, and that the rest of the interview wasn't technically challenging for anyone with real-world programming experience. In my case, nearly everyone who struggled with the second question told me they thought there was some significance behind the file size and that made them avoid the obvious answer.

imaginenore 11y ago

No, the solution is not the same. The 50MB one is easier, as it fits in RAM and we know none of the counts exceed 25 million. With the first one we don't even know if the counts fit into the standard numeric types.

MichaelGG 11y ago
Considering how easy it is to get a linear implementation, why would anyone choose to use a slower method?

TheLoneWolfling 11y ago

Those two are not equivalent. Actually, I'm surprised that people didn't find the first one harder: I've had log files that were larger than RAM before (mainly due to overzealous logging).

userbinator 11y ago
If the first thing your solution does is attempt to read the entire file into memory, then you probably failed the test. The same goes for trying to read an entire line into memory, however long it may be - this is a problem that can be solved with an essentially constant space of around a dozen bytes.
kstrauser 11y ago
Exactly! I've been asked the followup question: "now assume that you have 8 petabytes of log files to search", which leads into distributed computing, realtime vs on-demand collection, eventually consistent counters, the pros and cons of sampling vs exact counts, and so on. The unbounded form of that question can be astonishingly hard, and for the kinds of jobs I'd be interviewing for I'd expect the challenging next questions. I'd still answer along the lines of "for a quick solution I'd grep for the error level and count the number of lines, but that's not scalable".
- TheLoneWolfling 11y ago
  Ditto. (Also, no need to pipe + count: `grep -c` works.) Also, problem with sampling: you oversample long lines. I'm not actually sure if there is any way to count probabilistically that doesn't. I suppose if you had some prior of how long the types were you may be able to do better, but in general, good luck.

ColinWright 11y ago

So: $ grep ^ERROR | wc

wtetzner 11y ago
$ grep ^ERROR | wc -l
- ColinWright 11y ago
  Absolutely. I noticed that soon after I typed the other, but decided to leave it. Usually I'm passing the results to something else so it doesn't matter, but you're right, that produces just the number we want.
zimpenfish 11y ago
Or if you want to avoid a useless use of wc - $ grep -c ^ERROR
- ColinWright 11y ago
  Hah! I'd completely forgotten about "-c". Thank you!

ilitirit 11y ago

The people who are replying and saying these problems are not the same because of the file size are are seeing the same type of illusion of complexity described in the submission. You count the number of lines you that begin with the word ERROR. That's it. At this scale, the tools you use are, for all intents and purposes, irrelevant. Saying that the files might not fit into standard numeric types is like writing a custom BigNum implementation when I ask you to write a program that adds two numbers because I might give you value that doesn't fit into an int. It's of course fine to raise it as a potential issue, which would also show you know the practical implications. But what about if I ask you to write FizzBuzz? Are you going to give me the simple answer, or write something needlessly complex because I might test your program with a value like -3x10^78? Perhaps I should have been clearer that the interns were fresh out of college, or part of a placement program, and that the rest of the interview wasn't technically challenging for anyone with real-world programming experience. In my case, nearly everyone who struggled with the second question told me they thought there was some significance behind the file size and that made them avoid the obvious answer.