I have an off topic question. I don't see what the problem being discussed has to do with how glands reduce activity in certain parts of the brain. Sounds to me like a fancy way of saying 'people don't perform well under stress'.

You could of course ask - "what mechanisms control human behaviour, and how does stress specifically affect body systems?" Then, great, let's hear all about adrenal glands and prefrontal cortexes. When that's clearly not what the question was though, I find it a form of poor communication.

Anyone have any thoughts on this?

I have panic attacks if I feel too enclosed, particularly big crowds in small spaces. I would definitely fail to code FizzBuzz if I was having a panic attack! But if I needed to, I could disguise it pretty well. You might not notice that I was having a panic attack.

Stress isn't linear, so you can't really extrapolate from it that well.

Also, I would question whether absolutely everybody on your team needs to be exposed to lots of stress. Sure, some people have to care about live systems crashing (as one example of a majorly stressful event), but not everybody, surely?

Personally, interviews don't stress me out and I can do whiteboard coding tests no problem. A big component of that is because I went to the right schools and they rigorously trained me on that from a young age. I don't think it's fair that it's easier for me to get a job than someone whose grandmother was less well off (she paid for my schooling).

Poor communication aside, I was attempting to make a finer point than you read to it.

Stress is an extremely broad term medically, and used broader still colloquially. Medically defined stress may include anxiety, but frequently will not.

Anxiety, or technically in this case "performance anxiety" is a much more narrowly defined state with significantly more understanding about causes it, what it causes, and effective treatments.

It's know pretty commonly as "stage fright" - that's what you eliciting in some individuals when you put them in front of people they just met to prove that they are smart. I think we'd all agree that most programmer jobs shouldn't be withheld from someone who has trouble with public speaking.

I chose to use neuro chemical terms not to attempt to confuse anyone - but to make the point that this is a biological process triggered by hormones and not anything related to raw intelligence or a weak personality.

As an aside, it's extremely likely that they wouldn't have any trouble at all at the interview if they took a 80mg of propranolol hydrochloride (a beta blocker) an hour before the interview. It's probably used by 50% or more of public speakers and musicians playing big rooms. Unfortunately it's expensive, on patent and that's an off label use.

If you're not looking for someone to do regular public speaking then detecting what you consider "stress" probably has little bearing on their job applicability.

In the UK you can still get it prescribed for anxiety, and get it free on the NHS, so if you're wondering about betas it's worth checking what the situation is wherever you live.

I would strongly recommend that you do seek out medical advice regarding them, there are several very important caveats and contraindications.

Other than that you are right. Propranolol is an excellent calming drug.

Now, maybe getting into the biological mechanism by which they go to pieces is too specific, and trotsky could have communicated more effectively by eliding it. But it's an important point, and I don't think it reduces to just "people don't perform well under stress."

That's how I read it as well. But this got me thinking, why is it a good idea to test someone under interview stress when what they'll be doing 99% of the time won't be in interview circumstances?

I find some stressors don't have any negative effect on my performance but stress in an interview makes it much worse.

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.

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.

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.

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.

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.

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.

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.

I've come to enjoy technical interviews. How often do you get to spend a whole day talking one-on-one with people in your field who you can learn something from? I enjoy giving technical presentations to groups of 1000 people or so and been not nervous at all. But I have to keep water with me because some reflex makes my mouth get really dry. So I'm fine with public speaking (the most commonly cited phobia).

On the other hand, the prospect of sitting down to pay a bunch of paper bills or do taxes makes my body want to hyperventilate. If, in a place where there are only people around I know well, and I remember an event in my past that involved a social interaction in which I acted suboptimally while at the same time someone is crinkling a plastic bag, I will startle to the point of crying out "Aah!". It's true :-)

My only point here is that people are complex critters who change with time and environment. So attempts to think of others as a box of predictable glands and cortexes (cortices?) can easily turn into a pseudoscientific projection of one's own preconceptions. (I find it very helpful when thinking about myself, however.)

Has anyone ever tried asking candidates to design their own interviews?

* Does a stressful interview necessarily actually increase adrenaline? * Is there actually a link between incresed adrenaline and reduced prefrontal cortex output? * What role does the prefrontal cortex play in answering interview questions?

And while these may all have good answers, it just throws up a whole bunch of mental '[citation needed]' annotations all over the whole argument, that can just be skipped entirely if we aren't talking about neuro-science. And if we insist on talking about the bio-chemestry, we should probably go into the details.

"What happens in job interview is that adrenaline binds to a variety of adrenergic receptors, which triggers a number of metabolic changes" [1]

It'd be just as real, also clearly connected, but also quite clearly not what the conversation is about.

[1] http://en.wikipedia.org/wiki/Epinephrine

Unless you are specifically hiring people for a death march kind of project (which I find unwise anyway), targeting people good at high-stress situations doesn't seem very productive.

If your programming projects are a series of high-stress, high-adrenaline runs, either you work for NASA or you're doing it wrong.