4 ms·

Deadline pressure != interview pressure. Also stressful deadlines are an indicator that sosmthing else is wrong in a company. The company should fix that issue

Deadline pressure != interview pressure. Also stressful deadlines are an indicator that sosmthing else is wrong in a company. The company should fix that issue instead of hiring people that can "program under pressure".

bitwize 16y ago
At my company (we make AUVs), stressful deadlines mean you're out on a boat and you've got ops personnel looking over your shoulder and if you can't push out that code fix or configuration change NOW then they may not be able to run missions for the rest of the day because the vehicle would be dead in the water and the sun is going down. Needless to say, actual software development in the office is pretty relaxed. But when you go out on ops, you will be in the pressure cooker and you will need to handle it.
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.
prodigal_erik 16y ago
Occasionally I have to troubleshoot our production code while we lose several thousand dollars per hour in revenue and jeopardize business partnerships. Sometimes it's just pointing out which servers need a kick in the head, but sometimes it's a recent code change that didn't handle all cases and we need to fix forward on the spot (because rolling back all interdependencies would take longer).

bitwize 16y ago

At my company (we make AUVs), stressful deadlines mean you're out on a boat and you've got ops personnel looking over your shoulder and if you can't push out that code fix or configuration change NOW then they may not be able to run missions for the rest of the day because the vehicle would be dead in the water and the sun is going down. Needless to say, actual software development in the office is pretty relaxed. But when you go out on ops, you will be in the pressure cooker and you will need to handle it.

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.

prodigal_erik 16y ago

Occasionally I have to troubleshoot our production code while we lose several thousand dollars per hour in revenue and jeopardize business partnerships. Sometimes it's just pointing out which servers need a kick in the head, but sometimes it's a recent code change that didn't handle all cases and we need to fix forward on the spot (because rolling back all interdependencies would take longer).