How can one interview somebody for a job requiring work under severe stress?

Question

A friend of mine is working in a company which is developing and maintaining a set of mission critical products. If one of those products fail at 3 AM, it is mandatory to do something immediately to get it back online, including solving the issue in the source code itself.

The company is now searching for a developer capable of solving issues related to the development itself. The friend will be in charge of the technical part of the interview, and asked me for hints.

Actually, a good candidate must be able to solve technical problems under severe stress. If the application stops working on the server of a customer, the company is paying a huge penalty per hour of downtime, meaning that the developer will know that while he is currently working on the issue, the company loses thousands of dollars. There may also be indirect pressure from angry customers¹.

How can I emulate or test such a stressful situation during an interview?

All the usual elements used during the interview to test how an interviewee would handle the stress² seem too small compared to what the person would do once hired, i.e. being required to rush in the middle of the night to the workplace in order to solve a bug as fast as possible.

Asking for previous similar experience seems harsh too. I'm not sure whether it is frequent to find workers who had worked in such frightening conditions.

So how can I gauge this skill during an interview? How can I know someone has this ability to work under stress before they're hired?

---

Update: more than two years passed since I asked this question. I kept regular contact with my friend, and was glad to hear a lot of good news. The company had a chance to hire some talented persons who took a bunch of good ideas and pushed them up to the management which was clever enough to accept them, by trusting those people unconditionally.

Among the changes, the development workflow was entirely redesigned, with the introduction of DevOps which works surprisingly well. Other measures related to code reviews, tests and the quality of code ensured that the product became progressively better. Now the developers are not afraid any longer to push their changes to production, because they are pretty sure those changes won't break anything.

There were difficult choices to do as well. Several programmers and managers were fired, because of their lack of skills and their unwillingness to learn, including a manager who were in this company for twenty years. Also were painful the decision to outsource a few jobs.

This being said, the company became much more mature, and, more importantly, much more pleasant place to work. Nobody screams at developers because of a regression they introduced, because there are none (at least not severe enough), and nobody should wake up at 3 AM because a problem was discovered and should be solved ASAP.

Surprisingly, the solution was very simple: the company now have three teams in three countries around the world, geographically chosen so that an evening in one country corresponds more or less to the morning in another country (there is, I believe, a three hours gap at some point that they have to manage by asking employees to start to work later than usual and to end later as well). This allows the permanent availability of skilled personnel whenever a problem occurs.

The only problem is that a bunch of services is still hosted in-house. This means that the company should have system administrators at reach day and night, on location, in case where a problem occurs to the data center itself (UPS failures, flood, servers starting to shut down unexpectedly, etc.)

This problem is about to become obsolete. The company is migrating its services to Amazon EC2, which appears to be slightly more expensive, but also much more reliable: a good price to pay.

I'm both happy and sad: happy to hear that the company is doing well, and sad telling myself that I focused my attention purely on the hiring process itself, instead of having a broader look at the problem, as any developer is expected to do. I had all the necessary info to think about a larger picture, but I haven't seen that the solution to hiring persons ready to wake up at 3 AM is to simply make the original problem irrelevant, would it be by outsourcing or by migrating to cloud computing.

This could be a good lesson—at least I consider it like one for me. Instead of looking for management-centered solutions to technical problems which often make employees unhappy, one should look at technical solutions to management problems. This case is a perfect illustration of that.

---

^{¹ Developers have a workspace separated from support department, but at night, I'm pretty sure that if an issue is found, there would be only two people in the company's building: the developer and the person from the support. While the support person will handle all the calls outside the developers workspace, the two will still talk together, so the developer would know that the customer is expecting a quick response.}

^{² For example asking the interviewee to read or write code during a limited amount of time, or asking technical questions without telling if the answers are right or wrong, etc.}

Answer 1

Screening

You can't screen for candidates who would react well under the specific stresses of your environment. At best you can select candidates who have demonstrated capability during high stress positions in the past.

Even then however, as in finance, past performance is no guarantee of future performance.

Transparency

The most important thing is to make it plain during the interview that a candidate will be put in this position. You need to ask how they feel about it and let them ask any questions they might have.

If they are not prepared to work under these conditions, it is better to find out in the interview than later, when their job performance fails to meet expectations, they have to take time off work to cope^† and/or resign to find a less stressful job.

^{† I have worked somewhere this happened to a colleague.}

How different people react

Different people react very differently to different kinds of stress. While many people would get very stressed in the situation you describe, other might be decidedly relaxed about their employers or customers losing money.

In fact, it could easily be the case that while the stressed developer might work faster, they might also make more mistakes and thus the relaxed developer might work more efficiently overall.

Role-playing as an interview technique

If you really want to find out how someone might react, you could role play out a typical situation, but this would be considered by many a rather extreme form of interviewing for a software development position (though not for some jobs like sales or call centre staff).

It can never be fully representative of the situation they are likely to find themselves in however - after all, many people will already be stressed by being in an interview situation.

---

Though your situation may feel extreme, it is actually fairly common.

Many of us work in environments where a fault in our software could cause financial loss or even injury, and being expected to be available on call to deal with incidents is a common requirement for a software developer in many sectors

Answer 2

How to emulate, at best, a such stressful situation during an interview?

You don't.

That's what probation periods are for - to see how the person handles the pressure for real and if they don't then they do not pass their probation.

So long as it is clear in the interview process what the work requires and that there is a probation period the result of depends on performance under stress, the person being interviewed will know what they are getting themselves into and the company insures itself against hiring someone unsuitable long-term.

Answer 3

What some people forget is that an interview works both ways. While you are interviewing a person for a role, they are interviewing you to see if you are worth working for.

Your simulation aside, if you described as above my first question in the interview would be "Why do you only have one developer for a mission critical system?", also "Why don't you have fail-over / clustering set up?".

I would also ask how often would you expect me to be woken up at 3AM? Do I go to work the next day if I spent 3AM-6AM working on an issue? Or am I required to be on call 24/7? What happens if I become sick and something happens?

So I would seriously question if such a company would remain viable if it had a single point of failure which I would be interviewing to be.

Any serious professional knows money is being lost in downtime, and explaining the stipulations of the contract they will work to that.

Answer 4

Don't tell the employee it's a stressful environment.

As others have stated, create a probationary period, setup the environment that the employee will be in, and watch his/her performance. If you tell them

You're going to be in a very stressful work environment.

That automatically gets the prospective employee to cringe at the opportunity, and it just sounds like he/she will have a horrible time working for your company. No one wants to be put into that kind of situation.

You can inform them that

Our work is challenging and demanding.

So instead of giving the message that 'your life is going to suck here', you're giving the message that 'this role is very important', and will give the prospective employee a sense of pride for the position.

EDIT: P.S. NEVER TELL AN EMPLOYEE THAT THEY ARE MAKING THE COMPANY LOSE MONEY! It's not constructive and does nothing for either you or the employee. That includes making any program/diagram showing the negative effects of their 'lack of urgency'. Find ways to motivate and not scare the employee to creating positive performance.

EDIT2: When you tell the employee "Our work is challenging and demanding", watch their reaction. Some will slump in their seat, draw their shoulders in, and their facial expression may change. This shows a lack of confidence.

If they show a sense of seriousness or excitement when you say this to them, their confidence levels are at least there and it puts them into the mental position that they need to step up to the plate if they want to work here.

Answer 5

If it were me doing the hiring, I would look first for candidates who had done night time support in the past. At least they know what they are getting into and whether they would be willing to do it again.

I would also look more favorably on people who realy really know their stuff. If you have in depth knowledge, fixing things on the fly at 3 am is much less stressful than for the person who doesn't know where to start. I would look for people who go the extra mile in their current or past postions. People who know thier data model inside out, people who are organizaed and can put their fingers on teh tools and techniques they need to solve a problem quickly and people who have a track record of being a successful troubleshooter.

In addition to some programming problems, give them some troubleshooting tasks to perform. Take one of those things that went wrong at 5am and see if they can find the problem. More important than finding and solving the problem (they are afterall not familar with the code base) is how they go about looking for the problem.

Techniques I learned to test how they handle stress in the interview include (use these with care, they may turn off some good people): Use a panel of people all of whom do not react favorably or unfavorably to the answers given. If you give the person no clue what you are thinking, the interview becomes much more stressful. Ask some questions that you don't expect people to get correct. (it's a plus if they actually do get those correct as well) Disagree with a correct answer.

Answer 6

1 - Narrow it down

"Able to handle stress" is a very vague concept. A person who gets stressed with very fixed work hours and excessive management supervision, may find a job where they have to react immediately, think fast, and communicate well with minimum supervision to be an ideal job.

Figure out what traits you really need and what the context of the work will be. I'd suspect you want someone who can:

• be a jack of all trades, and able to dig into anything, strong debugging skills across complex systems

• readily ask for help and give good feedback/guidance/status since in a crisis communication like this is key

• work largely unsupervised with minimal oversight

• take ownership of the problem and take the crisis seriously

• accomodate the demands of critical outages with their work/life balance

• can perform sustainably - what I mean is, a one-hit wonder who can solve the crisis fast, but who is such a jerk in the process that no one will pick up the phone the next time he calls isn't going to do you any favors in the long run.

That's going to vary depending somewhat on your conditions. For example:

• can they fix the crisis from home or do they need to drive into worK? If they work from home, your communication needs go up, but your "can get to the office in X minutes or less" requirement is not necessary.

• will a manager be called in, too? If so, maybe you don't need someone who can communicate to ALL stakeholders, but the relationship between the person and his manager is critical, since they have to be a very strong team.

None of this is what I'd call "stress" - it's all a question of whether this person can perform well in the environmnent being provided.

2 - Get demonstration of skills, observe for characteristics

You can witness some of these skills in simulation - for example, giving an ambiguous problem which only sketchy details and focusing the candidate on time pressure is going to tell you something. But more important is how do they solve the problem. Be aware of the little things, when you observe, that show that the candidate is optimizing for the crisis, not just proving that he is smart.

3 - Be clear, have a discussion

When it comes to the question "is this guy going to be able to sustain these demands or will it collide with personal life?" - there's a lot of questins you can't ask in some countries like - "are you married?", "got kids?" and "are you pregnant?"

Instead, it's best to ask candidates if they can meet the demands of the job and ask them to give you supporting cases:

Question: We need this person to be on site to fix bugs within 15 minutes of being notified. Can you meet this, if so, tell me how?

Maybe they live close by, maybe they are willing to sleep in their car when they are on call - it only matters that they can meet your requirements in a way that you believe.

4 - Have a trial period

There's a strong case to be made that even if your company doesn't have a policy of probationary periods, you haven't hired for this type of job before, and it's different and could use a promotion period.

Answer 7

Unless you plan on interviewing them by calling them at 3 AM on a random morning and grilling them on tough interview questions (which I am not advocating), I'm not sure you can figure this out in an interview.

If they have prior experience in this type of environment, that is certainly a plus but isn't a true indicator. Survival in that type of scenario is primarily based on their in-depth knowledge of the system being supported. If they really understand the system they have a chance of succeeding, if not, don't put them on-call in the first place.

I work for a large finance company with global offices and a global customer base. Sometimes I'm the guy who gets that 3:00 AM call. Once I wake up, my success is tied directly to my comfort level with the sub-system which is failing. If it's something I've worked on, I'm in pretty good shape. If it's an interface with another subsystem, things get harder.

The best you can do to handle these stressful situations is to make sure you team (or at least the ones who will be on call) are capable people who truly understand your application. That comes from experience with your system and you can't get that out of an interview.

Answer 8

The military train people not to panic. It's all about training and experience; you don't hire somebody who doesn't panic, you train them. (Or somebody else trained them.)

Repetition builds confidence, and so you need at least one highly experienced support person. Nobody has confidence before they get experience.

Answer 9

May I answer your question with another question?

Are surgeons tested to work under stress before being hired? Do they jump out of bed an run through the streets when they are on call and there's an emergency? Don't they get quickly used to stressful situations even when every minute counts and take them with complete calm?

The only way to get things done is to pretend it's not an emergency and focus on what you need to do.

What you want is an experienced and intelligent person that can solve the problems that are expected to happen. I would focus on testing that and just making clear to the interviewed what his tasks and related conditions are.

Answer 10

Hire people who are ex-military with combat hours.

I know you are in France, but there are plenty of soldiers there who have had countless hours being shot at. Your company losing money is probably not going to ever be as stressful as the situations they have worked in before. It may be a small percentage of combat soldiers who program, but they are out there.

Answer 11

Planning a work environment for stress I believe is the wrong approach to start with. This is not a war, it's IT. There is no reason not to do serious planning to reduce stress by having sensible contingencies in the event of an emergency. Also constant practice in the form of drills also help greatly reduce the possibly of it being a stressful situation. If there is fear, for example, that a server might go down and cause a loss of revenue, then have back-up servers and mirroring the operations.

Practice taking them in and out of service, have mated pairs and off-site help in stand-by in the case of a real emergency like an extended power outage or fire. If you are going to plan to have a stressful environment and look to hire people who can handle that, then from my experience you are going to find people who don't plan, get bored very easily and do nothing until there is an emergency so they can play "fireman" and be a hero. This is a bad business practice and environment for IT and I would be doing and have done, everything possible to avoid such a problem.

Answer 12

There are some good answers here. I would like to add that there are some specialised support roles ( I am thinking Trading Floor support in banking / hedge funds ) which are very time critical and high stress since not having a timely resolution would lead to a direct financial loss. It is not easy to emulate such a situation, but your friend could look for people with similar experiences.

I have worked in such roles and even now work very closely with support personnel who have similar jobs. The best support people tend to:

• Learn from previous experiences: If a particular batch job fails and if for the first time it takes them three hours to figure it out - they document and communicate the solution so that the next time only takes minutes to resolve the situation.

• Be familiar with basic support tools: They should know how to search for errors in a log file, find out the disk utilisation on a server, how to check which processes are using which port to communicate, etc. Knowledge of a scripting language like Perl or Python is usually a good sign for a support person.

• Be able to communicate clearly: They should be able to explain the behaviour of the system clearly to the developer and to the business person. They will need to coordinate any emergency bug fixes, server restarts, etc., so being able to communicate clearly is very important

Your friend could check for these attributes in potential candidates for the role.

Answer 13

Another thing to consider. As an IT professional, I've ended such interviews when I felt they were planning games with me. The management might think they are clever, but no good person is going to put up with this sort of nonsense. Serious advanced planning is the only way to run things properly.

Answer 14

I can't work under stress at all. I solve this problem by not letting anything stress me. If I had to fix a problem at 3am in the morning that costs the company $10,000 an hour, that's not stressful. It's inconvenient because it's 3am. The money isn't my money, so that doesn't stress me. If I had a supervisor wanting a status report every ten minutes I'd tell them to **** off ahem go and pester someone else, I have work to do.

I can work focused, and I know what my most effective speed is. It's not my fastest speed, because that is where mistakes are made. It's the speed that leads to fixing the problem quickest in my experience.

And if it's so expensive to have delays, you'd have two developers coming in. It will save you money.

Answer 15

I think if you are fully upfront about the demands of the position, many candidates will weed themselves out. Some will have family situations that are not condicive to being on call.

Also, you need to rethink how you plan on reacting to these situations. Changing code is not the same as rebooting a server.

Answer 16

Since when have stopping a company losing some money be of that much importance? You have to find a better reason for the system to be fixed quickly and then interview for people that deeply care about that reason.

You are looking for someone that thinks the customer is doing a worthwhile task and will feels a sense of ownership of the problem.

Hopefully when the job is explained, most people that are not willing to do it will withdraw from the process. However some people will lose benefits, or have their family require them to take the first job they can get, or just be so fed up with their current job that they will take anything to get out.

So ask the person lots of questions over at least 2 interviews spread out over at least 2 weeks about how they will cope practically with it – you don’t care what the answers are, just that you are making them think about it.

Then only take on someone that loves their current job with a current job that does not pay much less. You are trying to select someone that has positively chosen to take your job.

Answer 17

Depending how much freedom you have with the interview process - you could possibly perform psychometric testing. @Oded I thought about a sedentary test which you could perform. Chess is possibly an answer, or speed chess. A timed game against a grandmaster is one way to put pressure player/interviewee, especially considering the interviewee will probably be under the impression they have to win.

There have been some interesting studies into chess, it's stress implications, and the various monitoring devices which you could use. Stressed Chess, and "The stress of chess players as a model to study the effects of psychological stimuli on physiological responses: an example of substrate oxidation and heart rate variability in man". These are only ideas, if indeed the need to monitor a persons ability to deal with stress is paramount.

Personally though, I think talking to person, finding out about their previous experience (work, and life) is probably more applicable. If the person is technical competent than they are less likely to suffer from stress, than someone who can deal with stress and is technically less competent. Testing for stress by chess, could be a little too bizarre?

Answer 18

Why not simulate that environment exactly?

For example, let's say you have a number of problems for them to solve during the interview process. Before you get to these problems, show the candidate something like the following:

Explain, as you did in your question, that the company makes thousands of dollars on a given project per hour. Thus, when there is a bug in the project which causes it to go down for an extended period of time, there is the potential for a great amount of profit loss. Furthermore, while some people may thrive in this type of environment, others would find it too stressful. Thus, in order to find out how they deal with this type of stressful situation, there is a portion of the interview process dedicated to replicating this environment to see how they will deal with it.

At this point, ask them if they are OK with this type of test. If not, then skip it and just ask the programming questions as normal and judge them on the rest of the interview, taking into account that they avoided the stressful situation. If so, click the "New Problem" button. Explain to them that a bug was found and the product is now down, and that in an actual situation, the clock would be running even while they are trying to figure out what the problem is. Also, explain that even though there is a time-crunch, fixing the bug properly is the bigger goal here. Then hand them the problem, preferably on a piece of paper with no further explanation and sit back, observe, and answer questions for them as you deem appropriate.

When they are finished with the problem, click the "Problem Fixed" button and evaluate their solution to make sure it meets the requirements. If it does not, click the "10-Minute Penalty" button, explaining again that fixing the bug properly is the bigger goal, and have them continue working as the Dollars Lost continues accruing.

Repeat for the remaining problems, asking them if they are ok to continue before starting the next problem, and possibly asking them how they are dealing with the stress of the situation. Be empathetic, understanding that this is not a fun process to go through (for most).

At the end you will get a concrete number for total dollars lost on all problems, as well as the qualitative experience of how they perform under pressure.

Here's the editable link for the simulation if you want to tweak it to better match your case.