Upvoting you to help prevent your comment from reaching oblivion - I don't agree with you, but I think what you said is a common belief.

The thing is, it's a vastly different kind of pressure. When I am coding as part of a job - by myself or with others - there is no inner monologue in the corner of my brain doing something like this:

"Could do that or... no damn, that's O(n^2), damn I'm taking too long that one looks bored, if I instead put those keys in a hash... no, I'm sure there's a better way, running out of time though, is he looking at his phone now? Okay, what was the profile of merge sort again? ... oh, shit! She felt like she had to offer me a guiding hint, I'm doing it wrong!"

And it never stops going. It picks apart every choice I make, and by five minutes into the interview I come across as a sub-articulate mess.

In no other high-pressure situation does this happen to me. Hell, this past summer I actually spoke at a conference and I didn't have the kind of trouble I do in an interview.

Whiteboarding, paired coding, participating in architecture design - these things come easily. In the context of an interview, though, it goes out the window.

Have you done pair programming before? Especially as you become more senior, the pressure to not look like an idiot in front of junior devs adds up fast. You have to learn, quickly, how to get over that kind of inner monologue, and just get to work.

That kind of scenario happens to me daily.

I've never felt that pressure. Keep an air of confidence. Let them assume you know way more than they do about almost anything else. They'll feel like they're really shining in this moment, and impressing you, and growing in their role. Win win.

I don't understand the desire to make it seem like you know everything.

If you learn something from someone, is it that much trouble to give them credit for expanding your horizon?

If this mindset is recursive down your organization's hierarchy, doesn't it create a scenario where a legitimate critique never gets heard because people don't question the decision of a higher ranked employee because there is the impression that they know more than you?

Seems like you and your employer are worse off, but your ego remains intact.

I do pair fairly regularly -- for whatever reason, the concerns don't manifest the same way as in interviews. I can't think of anything in my experience (professional or personal) that's comparable.

Thanks for clearing that up, it's exactly the same for me. I find technical mock interviews help.

It's not like software development is the same as being a fighter pilot.

Code now or die isn't usually something most people face in their day job.

The Swordfish art of tech interviewing

According to Vim aficionados, the experiences are similar.

I can't code with people staring at me, talking to me, asking me questions. If you can more power to you, but if that reflects the nature of the job then they can take that one and shove it. It simply doesn't reflect reality.

You almost certainly tell the project manager that they have dramatically failed at their job. You go to bed and come back when you aren't going to make stupid errors.

That is a thing that happens, yes.

If that happens consistently for months at a time, then as said the PM is severely fucking up. And if that wasn't communicated as an expectation before compensation was negotiated, then the company is probably fucking up.

As the quip goes "If a race doesn't have an end, then it's a death march."

A) Been there, done that, told my boss to fuck off. I've been on week long coding binges where I maybe got a cumulative 10 hours of sleep. This is a fundamentally different kind of pressure on yourself than having someone watching over your should or giving you a stare down on Skype while badgering you the whole time.

B) If you're working a job like this you're working a shitty job and ought to quit. Unless you're maybe hacking the Gibson to stop some oil tankers from going belly up there is hardly a reason in our industry for this kind of shit.

Your job sounds terrible.

I can code under pressure.

But I will not work in a company where that's the norm.

I value my health more than the potential money from that stressful job.

How do these opinions even survive? Yikes

All these "yeah but imagine this horror scenario" (sorry to pick your example) descriptions sound like badly managed situations. Even in total failure situations like that...the foreman shouldn't be looking over your shoulder. The first step is to take a deep breath, assess the overall situation and get the programmers into their most comfortable mode to fix it. That can very well mean letting them think for 1h before starting doing anything. You can ignore that 100k price tag because that just leads to "just do something" thinking. It's very likely manically hacking away will actually end up making the situation worse and costing more.

Also...these situations can be trained for to certain degrees. There's well established precedents in crisis management. If you write code for a customer with a 100k/h downtime risk you should have done a very thorough risk analysis and have mitigation plans for most scenarios. The unknown unknowns that can happen are obviously the hard cases but you should be able to justify that these are going to be expensive no matter what. But even for these cases bricolage is trainable to a certain degree.

If you know there's 100k/h costs of failure you should also very specifically mention the fact that you are looking for these stress coping skills in the job description (and as such the interviewee should be prepared).

In my experience, high-pressure "fix it now" scenarios are about leaning on what you know about the system, interpreting metrics and log messages, understanding how it's going wrong, and deploying a (usually very simple) fix. Sometimes just blindly hitting the "rollback" button as a first step fixes it, too.

Performing well in this kind of scenario is much less about algorithms and data structures, and much more about systems thinking and the level of your understanding of your system.

Both of you have points, but I absolutely agree with this. Outside of "Healthcare.gov goes live tomorrow and turns out it's completely broken" scenarios I've never seen something that would require a ground-up design and build of a system under emergency production time constraints.

System knowledge and knowing which one bolt to replace or turn is almost always more effective.

PS: Not to mention, if we're getting into algorithmic complexity levels of engineering on a monkey patch to a production system, then so many alarm bells are already ringing.

See my longer comment above. Last paragraph:

An interview situation is much more adversarial: They are looking out for reasons not to hire you, you are competing with others for the job and only one can get it! No such consideration on the job, unless the work environment is completely and ridiculously broken. When are you ever in a work situation where several people work on competing solutions and everybody else but the person who made the winning one is fired? At work you are working together, and to solve a problem, not to week you out of the pool.

If you've done your job properly in the first place you have sufficient testing and redundancy in place that the situation you're referring to is pretty much impossible.

If there's ever going to be a situation where something costs $100k/hour if it's offline then you have 5 test servers and 2 or 3 load-balanced production servers so a failure doesn't take you offline, and you've written procedures and processes to handle critical problems long before they happen.

You definitely don't try to hotfix things while the foreman complains. That will make things worse.

That's a terrible analogy. In a production crisis, you have full knowledge of and access to the system being diagnosed, have all your standard tools and information sources available to you, and are able to enlist your co-workers to aid you. Been there, done that and it's's nothing like a interview whiteboarding session.