4 ms·

I was once asked in an Amazon interview a famous problem of theirs, find all phone numbers on their website. This was a real world problem they ran into. The fi

I was once asked in an Amazon interview a famous problem of theirs, find all phone numbers on their website. This was a real world problem they ran into. The first engineer there went about it in java, took days and pages of code (and still various corner cases were issues, it was slow, etc..) Another came along, threw down a few lines of shell and was done. There are some things shell does really well.

jks 3y ago
This reminds me of the story in which Don Knuth wrote a literate program in WEB (reportedly over 10 pages) to do some text processing and Doug McIlroy did the same thing in a six-line shell script: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...
- cb321 3y ago
  Knuth was asked to demonstrate his new literate programming and probably thought an 8-page mini-paper was about the right "length" to do so: https://buttondown.email/hillelwayne/archive/donald-knuth-was-framed/ McIlroy was asked to show off productivity in the newly popular Unix system, and he did that. While often framed as "a contest" the two approaches are really solving different enough problems as being apples-oranges. So, the only meaningful judgement of a contest is "who better achieved their narrow goals?" I've found in discussions with people that they seem unable to separate their judgement of "a winner" from their own personal weight on the value of the two narrow goals ("detailed articulation mixing code & text" vs. "just getting shit done"). There is probably some broader lesson about people in that (and indeed probably a specific term in the science of psychology) - those who really like apples or really like oranges being inclined to force a non-contest into one of their favored "Eat oranges!" rhetorical moves. EDIT: and it's actually even more subtle - the very same person can side with either depending on broader context or framing. There are those who would praise detailed documentation over write-only hacks requiring detailed memory of tool innards in one situation yet decry it as a waste of time in another. (All part of why survey results are not to be accepted naively.)
fbdab103 3y ago
I am trying to be charitable to the Java implementation, but I am struggling to understand the complexity there. Java can iterate over files, it can iterate over strings, the rules to permissively identify phone numbers are not great, but both implementations would suffer from that complexity. Unless it was full-on FactoryFactoryPPIExtractor<PhoneNumber> style coding.
- Arnavion 3y ago
  "find all phone numbers on their website" sounds like it had to act like a web crawler, not parse a bunch of files, so perhaps the complexity was because of that.
  - seadan83 3y ago
    I like how y'all are thinking the complexity was in the web crawling. It was actually just a simple act of crawling over source files! Amazon was looking to remove their customer support phone numbers from all web pages (to save money, they wanted people to stop calling them; back in the early 2010s) I share the wonder that it took several days (perhaps that is the anecdote taking a life of its own, perhaps it was actually several hours. Or maybe it was was several days interspersed with on-call support, meetings, and other work running in parallel). Though.. the file parsing libraries back in the early 2010s in Java are somewhat basic, probably using Java 5. Which does make me wonder, how long would that exercise take in Java 8 or later compared to Java 5?
    - qohen 3y ago
      Steve Yegge discusses this in his "The Five Essential Phone-Screen Questions" blog post[0] from 2004 and states that his team-member (at Amazon) produced the list of phone-numbers in an hour: Here are some facts for you to ponder: 1. Our Contact Reduction team really did have exactly this problem in 2003. This isn't a made-up example. 2. Someone on our team produced the list within an hour, and the list supported more than just the 2 formats above. 3. About 25% to 35% of all software development engineer candidates, independent of experience level, cannot solve this problem, even given the entire interview hour and lots of hints. [0] https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho...

jks 3y ago

This reminds me of the story in which Don Knuth wrote a literate program in WEB (reportedly over 10 pages) to do some text processing and Doug McIlroy did the same thing in a six-line shell script: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

cb321 3y ago
Knuth was asked to demonstrate his new literate programming and probably thought an 8-page mini-paper was about the right "length" to do so: https://buttondown.email/hillelwayne/archive/donald-knuth-was-framed/ McIlroy was asked to show off productivity in the newly popular Unix system, and he did that. While often framed as "a contest" the two approaches are really solving different enough problems as being apples-oranges. So, the only meaningful judgement of a contest is "who better achieved their narrow goals?" I've found in discussions with people that they seem unable to separate their judgement of "a winner" from their own personal weight on the value of the two narrow goals ("detailed articulation mixing code & text" vs. "just getting shit done"). There is probably some broader lesson about people in that (and indeed probably a specific term in the science of psychology) - those who really like apples or really like oranges being inclined to force a non-contest into one of their favored "Eat oranges!" rhetorical moves. EDIT: and it's actually even more subtle - the very same person can side with either depending on broader context or framing. There are those who would praise detailed documentation over write-only hacks requiring detailed memory of tool innards in one situation yet decry it as a waste of time in another. (All part of why survey results are not to be accepted naively.)

fbdab103 3y ago

I am trying to be charitable to the Java implementation, but I am struggling to understand the complexity there. Java can iterate over files, it can iterate over strings, the rules to permissively identify phone numbers are not great, but both implementations would suffer from that complexity. Unless it was full-on FactoryFactoryPPIExtractor<PhoneNumber> style coding.

Arnavion 3y ago
"find all phone numbers on their website" sounds like it had to act like a web crawler, not parse a bunch of files, so perhaps the complexity was because of that.
- seadan83 3y ago
  I like how y'all are thinking the complexity was in the web crawling. It was actually just a simple act of crawling over source files! Amazon was looking to remove their customer support phone numbers from all web pages (to save money, they wanted people to stop calling them; back in the early 2010s) I share the wonder that it took several days (perhaps that is the anecdote taking a life of its own, perhaps it was actually several hours. Or maybe it was was several days interspersed with on-call support, meetings, and other work running in parallel). Though.. the file parsing libraries back in the early 2010s in Java are somewhat basic, probably using Java 5. Which does make me wonder, how long would that exercise take in Java 8 or later compared to Java 5?
  - qohen 3y ago
    Steve Yegge discusses this in his "The Five Essential Phone-Screen Questions" blog post[0] from 2004 and states that his team-member (at Amazon) produced the list of phone-numbers in an hour: Here are some facts for you to ponder: 1. Our Contact Reduction team really did have exactly this problem in 2003. This isn't a made-up example. 2. Someone on our team produced the list within an hour, and the list supported more than just the 2 formats above. 3. About 25% to 35% of all software development engineer candidates, independent of experience level, cannot solve this problem, even given the entire interview hour and lots of hints. [0] https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho...