3 ms·

Plenty of code changes need to be made under pressure. Some recent examples from stories posted on HN: 1) Bug in Google authentication which allows websites ru

by ig1 16y ago

Plenty of code changes need to be made under pressure. Some recent examples from stories posted on HN: 1) Bug in Google authentication which allows websites running on App Engine to grab users email addresses without permission 2) Crunchbase making all historical searches public 3) Facebook downtime bringing down "like" buttons All three of these issues were for the companies in questions bugs that had to be fixed in realtime. Does it indicate that something is wrong with these companies ? - no. Any changing production system is going to suffer from bugs that on occasion will require programmers to be woken up in the middle of the night to urgently fix a bug.

arethuza 16y ago
"Does it indicate that something is wrong with these companies" It means that their testing wasn't very good. If programmers are being woken up to fix something then something is very wrong with an environment.
- ig1 16y ago
  You're never going to have 100% test coverage. Any complex system is going to have bugs. It's pretty much impossible to write even a small library without bugs, let alone huge websites with the complexity of Facebook or Google. Look at cryptographic libraries. Often they've been gone over line-by-line by hundreds of experts in the field, have extensive testing both unit and field. Yet bugs still get found in them.
  - arethuza 16y ago
    My point isn't that bugs happen - of course they do and of course they get missed by tests. It is that if you pull someone out of bed to fix a problem I would suspect there is a high likelihood that you will be introducing more problems when you deploy this fix unless you run a full QA cycle after the change.
VladRussian 16y ago
don't know about 1. and 2. The 3rd - Facebook - from what i read about it (bug in cache invalidation/update, herding the db) as well as recent problem at Foursquare (uneven sharding on MongoDb overloading a shard), as well as the production problems i have faced and resolved personally, have nothing in common with interview questions i've been asked so far in my life. Not even close, not even in the same Universe.
- ig1 16y ago
  The problem is that real world bugs are often too complex to use in interview questions. From my experience solving production bugs often involves having to piece together bits of information from logs, databases, etc. and making educated guess to track down the source of the bug. It's pretty hard to replicate in an interview environment. Spotting bugs in code, operational questions, and writing code samples are probably the closest you'll be able to come within the time restrictions of an interview.

by ig1 16y ago

arethuza 16y ago

"Does it indicate that something is wrong with these companies" It means that their testing wasn't very good. If programmers are being woken up to fix something then something is very wrong with an environment.

ig1 16y ago
You're never going to have 100% test coverage. Any complex system is going to have bugs. It's pretty much impossible to write even a small library without bugs, let alone huge websites with the complexity of Facebook or Google. Look at cryptographic libraries. Often they've been gone over line-by-line by hundreds of experts in the field, have extensive testing both unit and field. Yet bugs still get found in them.
- arethuza 16y ago
  My point isn't that bugs happen - of course they do and of course they get missed by tests. It is that if you pull someone out of bed to fix a problem I would suspect there is a high likelihood that you will be introducing more problems when you deploy this fix unless you run a full QA cycle after the change.

VladRussian 16y ago

don't know about 1. and 2. The 3rd - Facebook - from what i read about it (bug in cache invalidation/update, herding the db) as well as recent problem at Foursquare (uneven sharding on MongoDb overloading a shard), as well as the production problems i have faced and resolved personally, have nothing in common with interview questions i've been asked so far in my life. Not even close, not even in the same Universe.

ig1 16y ago
The problem is that real world bugs are often too complex to use in interview questions. From my experience solving production bugs often involves having to piece together bits of information from logs, databases, etc. and making educated guess to track down the source of the bug. It's pretty hard to replicate in an interview environment. Spotting bugs in code, operational questions, and writing code samples are probably the closest you'll be able to come within the time restrictions of an interview.