6 ms·

Agree. I have enormous social anxiety that completely wipes out my thought process... But give me a project to do with a due date (ex a school project due in 2

Agree. I have enormous social anxiety that completely wipes out my thought process... But give me a project to do with a due date (ex a school project due in 2 days) and the stress from that actually motivates me to get it done and does not mash my brain up like the stress of being in a social situation like a interview.

doktrin 14y ago
Unfortunately, there's no good solution to this problem. I recently had a company ask me to work on a 2-day project for them (in the office), for which I performed sub-optimally. There are some other variables which might be involved (I was working with a new language, database & framework), but I never really found a "flow". Reflecting upon it, I think the pressure to create a product + learn the tools in a given timeframe threw me off.
badgar 14y ago
Work is social. What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed the FoobarService to return X instead of Y when Z? They can't release the latest features until it's fixed! What you were doing isn't important anymore, you're holding up everything! If you want to work for a web services company: what are you going to do when your service goes down, you're oncall, and angry users, coworkers or your manager start asking you what's wrong? Are you gonna meltdown? If so, I think you should address that first. My company, which does do whiteboard interviews, can wait to hire you until you won't freak out, and we likely will. By the way... real work actually gets worse than this. Sometimes the co-workers involved aren't gentle about things in the heat of the moment and they're gonna say you did something stupid, that your mistake was obvious. You need to address their concerns anyway. Or during an outage, your nervous manager might start checking in every 2 minutes - you need to calm him down.
- pifflesnort 14y ago
  > What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed the FoobarService to return X instead of Y when Z? They can't release the latest features until it's fixed! What you were doing isn't important anymore, you're holding up everything! This should have been caught before it was an emergency, through standard processes such as integration and unit testing. > ... you're oncall, and angry users, coworkers or your manager start asking you what's wrong? If your coworkers and managers are angry during an outage, or asking anything other than "what can I do to help", they're not helping. > Sometimes the co-workers involved aren't gentle about things in the heat of the moment ... Those coworkers need to be instructed in proper workplace behavior. The time to be critical about work is before an emergency occurs. Institute policies to ensure code quality and IT robustness, define roll-back plans to be enacted in case of failure, and supply other policies, procedures, and evaluation criteria necessary to steer your employees to ensure that the chance of success is maximized (and the chance of outage is minimized). When (not if) the shit hits the fan, you -- and all your employees -- are prepared for it. If a nervous manager is still checking in every 2 minutes instead of asking how they can help, it's your job to MAKE THEM STOP. This strategy is how you prevent most failures, and make the ones that happen manageable. Your strategy is how you create failures, and then make them worse for everyone involved when they happen.
  - badgar 14y ago
    > This should have been caught before it was an emergency, through standard processes such as integration and unit testing. Things always go wrong in the development cycle. Problems happen. Conflicts between individuals occur. I was giving an example. Are you asserting these issues don't arise in the workplace? Or that my example is of a rare situation in software development? > If your coworkers and managers are angry during an outage, or asking anything other than "what can I do to help", they're not helping. People sometimes do unhelpful things. Sometimes people even make emotional decisions about what to say to others. Are you aware of the fallibility of man? > Those coworkers need to be instructed in proper workplace behavior. They likely will be. Have you met engineers? A lot of them could use some workplace etiquette training! Until then, you need to do your job - you can't just go home because it's stressing you out. This is something that happens in every single workplace. If you can't handle it, you aren't a very valuable employee. > This strategy is how you prevent most failures, and make the ones that happen manageable. Your strategy is how you create failures, and then make them worse for everyone involved when they happen. This, and the rambling before it, is completely off-topic. I have no idea why you're rambling on and on about software development practices when the issue I'm addressing is that social stress always exists at work. If you feel my examples are unsatisfactory, but don't have any issue with my core argument, then you aren't being helpful. If you have an issue with my core argument, please address it instead of nitpicking my examples.
    - pifflesnort 14y ago
      Your examples are all cases where someone creates social stress by reacting poorly to avoidable, stressful situations. Your goal seems to be to hire people that will put up with these avoidable stresses. My goal is to build an mature workplace where we avoid creating unnecessary social stresses by applying collective wisdom and experience to plan ahead. This is one of the many difference between engineering and hacking.
- trotsky 14y ago
  You're just lumping two different things together. Everyone has performance anxiety at times - whether rare, mild, common, or occasionally overwhelming it's something everyone deals with. Something like public speaking to a room of strangers or flirting with a super model really doesn't share many physiological triggers with diagnosing code you wrote while people you're friends with look on anxiously. Assuming that because something's easy for you (and most people) that anyone who has trouble with it is likely to be broken in lots of ways isn't too safe a bet. If someone gets overwhelmed by vertigo on a skyscraper does that mean you won't be able to trust them to drive in rush hour traffic? If a guy pisses his pants when he gets a gun pulled on him does that mean he can't be trusted to be an airline pilot? Those are exaggerated to make the point, but interviewing is an art. You have great latitude in terms of making people comfortable or uncomfortable depending on your goals. With enough effort I'd be willing to bet you could engineer an interview that would send almost anyone over the edge. So now that it's just a case of degrees, all you have to do is decide whether you're hiring someone that needs to be able to solve programming puzzles in front of a stranger that's actively critiquing them.
  - badgar 14y ago
    > solve programming puzzles Your argument all comes down to dismissing the content of the interview. Since you clearly assume the interview is worthless, you aren't even discussing this in good faith, so I'm just ignoring this post.
    - trotsky 14y ago
      It didn't at all. It carefully explained why the two activities produced entirely different chemical reactions in the brain. If you're too invested in your process to even consider that a test of one thing may not translate into the performance on a totally different task then perhaps you're taking this all a bit too personally.

doktrin 14y ago

Unfortunately, there's no good solution to this problem. I recently had a company ask me to work on a 2-day project for them (in the office), for which I performed sub-optimally. There are some other variables which might be involved (I was working with a new language, database & framework), but I never really found a "flow". Reflecting upon it, I think the pressure to create a product + learn the tools in a given timeframe threw me off.

badgar 14y ago

Work is social. What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed the FoobarService to return X instead of Y when Z? They can't release the latest features until it's fixed! What you were doing isn't important anymore, you're holding up everything! If you want to work for a web services company: what are you going to do when your service goes down, you're oncall, and angry users, coworkers or your manager start asking you what's wrong? Are you gonna meltdown? If so, I think you should address that first. My company, which does do whiteboard interviews, can wait to hire you until you won't freak out, and we likely will. By the way... real work actually gets worse than this. Sometimes the co-workers involved aren't gentle about things in the heat of the moment and they're gonna say you did something stupid, that your mistake was obvious. You need to address their concerns anyway. Or during an outage, your nervous manager might start checking in every 2 minutes - you need to calm him down.

pifflesnort 14y ago
> What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed the FoobarService to return X instead of Y when Z? They can't release the latest features until it's fixed! What you were doing isn't important anymore, you're holding up everything! This should have been caught before it was an emergency, through standard processes such as integration and unit testing. > ... you're oncall, and angry users, coworkers or your manager start asking you what's wrong? If your coworkers and managers are angry during an outage, or asking anything other than "what can I do to help", they're not helping. > Sometimes the co-workers involved aren't gentle about things in the heat of the moment ... Those coworkers need to be instructed in proper workplace behavior. The time to be critical about work is before an emergency occurs. Institute policies to ensure code quality and IT robustness, define roll-back plans to be enacted in case of failure, and supply other policies, procedures, and evaluation criteria necessary to steer your employees to ensure that the chance of success is maximized (and the chance of outage is minimized). When (not if) the shit hits the fan, you -- and all your employees -- are prepared for it. If a nervous manager is still checking in every 2 minutes instead of asking how they can help, it's your job to MAKE THEM STOP. This strategy is how you prevent most failures, and make the ones that happen manageable. Your strategy is how you create failures, and then make them worse for everyone involved when they happen.
- badgar 14y ago
  > This should have been caught before it was an emergency, through standard processes such as integration and unit testing. Things always go wrong in the development cycle. Problems happen. Conflicts between individuals occur. I was giving an example. Are you asserting these issues don't arise in the workplace? Or that my example is of a rare situation in software development? > If your coworkers and managers are angry during an outage, or asking anything other than "what can I do to help", they're not helping. People sometimes do unhelpful things. Sometimes people even make emotional decisions about what to say to others. Are you aware of the fallibility of man? > Those coworkers need to be instructed in proper workplace behavior. They likely will be. Have you met engineers? A lot of them could use some workplace etiquette training! Until then, you need to do your job - you can't just go home because it's stressing you out. This is something that happens in every single workplace. If you can't handle it, you aren't a very valuable employee. > This strategy is how you prevent most failures, and make the ones that happen manageable. Your strategy is how you create failures, and then make them worse for everyone involved when they happen. This, and the rambling before it, is completely off-topic. I have no idea why you're rambling on and on about software development practices when the issue I'm addressing is that social stress always exists at work. If you feel my examples are unsatisfactory, but don't have any issue with my core argument, then you aren't being helpful. If you have an issue with my core argument, please address it instead of nitpicking my examples.
  - pifflesnort 14y ago
    Your examples are all cases where someone creates social stress by reacting poorly to avoidable, stressful situations. Your goal seems to be to hire people that will put up with these avoidable stresses. My goal is to build an mature workplace where we avoid creating unnecessary social stresses by applying collective wisdom and experience to plan ahead. This is one of the many difference between engineering and hacking.
trotsky 14y ago
You're just lumping two different things together. Everyone has performance anxiety at times - whether rare, mild, common, or occasionally overwhelming it's something everyone deals with. Something like public speaking to a room of strangers or flirting with a super model really doesn't share many physiological triggers with diagnosing code you wrote while people you're friends with look on anxiously. Assuming that because something's easy for you (and most people) that anyone who has trouble with it is likely to be broken in lots of ways isn't too safe a bet. If someone gets overwhelmed by vertigo on a skyscraper does that mean you won't be able to trust them to drive in rush hour traffic? If a guy pisses his pants when he gets a gun pulled on him does that mean he can't be trusted to be an airline pilot? Those are exaggerated to make the point, but interviewing is an art. You have great latitude in terms of making people comfortable or uncomfortable depending on your goals. With enough effort I'd be willing to bet you could engineer an interview that would send almost anyone over the edge. So now that it's just a case of degrees, all you have to do is decide whether you're hiring someone that needs to be able to solve programming puzzles in front of a stranger that's actively critiquing them.
- badgar 14y ago
  > solve programming puzzles Your argument all comes down to dismissing the content of the interview. Since you clearly assume the interview is worthless, you aren't even discussing this in good faith, so I'm just ignoring this post.
  - trotsky 14y ago
    It didn't at all. It carefully explained why the two activities produced entirely different chemical reactions in the brain. If you're too invested in your process to even consider that a test of one thing may not translate into the performance on a totally different task then perhaps you're taking this all a bit too personally.