I agree with you. Sometimes stressful situations arise, and there is nothing you can do about it.

Even if you have the best QA process in the world, and people can't break the build because you can't merge code that doesn't pass the test suite, at some point you are still going to ship a bug to customers, and even if your manager is the nicest person in the world it will be a very uncomfortable situation once you realise that your bug is losing customer data.

If you can't deal with an occasional stressful situation, life is going to suck for you, because there are always going to be stressful situations.

Being given 3 hours to add a minor feature to a pretty run-of-the-mill C program really shouldn't be an issue to anyone who is familiar with C, assuming the job asked for experience with C.

Sure job interviews are stressful, but if you can't calm yourself down in 3 hours and do something that would take an average C programmer maybe 30 minutes of time, you probably aren't a good fit for a job where people are going to rely on you.

Yeah a shitty working environment where people are constantly stressed, is not a good fit for me.

Generally speaking if your build process is so fragile that one person creating a breaking build results in a chain of failures and a pressure crunch then that's a work environment problem. I would consider that sort of thing completely unreasonable and consider finding a new job immediately. If you find yourself in that sort of thing frequently then perhaps you should reconsider normalizing it and instead push for actual fixes.

You look at the issue and say it's a personal issue. I look at it and see a dysfunctional development environment issue. Now this doesn't always hold true and sometimes devs have to be held to higher pressure environments (such as having on-call duties): but those kind of things are usually better compensated for and called out as part of the job duties.

Even in the best environments, stuff happens. If you have a central enough role in a large enough environment, you will cause pain for a ton of other people every once in a while, even if it’s not directly your fault. If you have a process that completely prevents all fuckups that an engineer could possibly cause, you either have a relatively small leaf node project or one that is low productivity.

That said, I wouldn’t necessarily give this question to the most junior candidates. Coping with a large existing sourcebase rapidly is a set of learned skills even if it’s just cargo-cutting a solution like this.

In an ideal world, no one would ever have to work under pressure, and while some people in this industry don't, many (I would bet a majority) of people do or have in the past. This seems especially true for startups trying to break into a market with competition.

Either you have been lucky with the places you've worked at, have sifted through tens of shops to find a good one, or have very little experience in the industry. I really do hope that none of my assumptions are true and that one day I can find a functional, low-pressure team to work with.

This goes back to what I said earlier: If the work environment is dysfunctional, then you should either work towards fixing it (especially if you're a senior engineer) or work towards finding a better job. Software engineers are one of the few career paths afforded the ability to do so and it would be better for us as a whole if there was less normalization of awful development practices under the guise of 'everyone else has experienced this or does this'.

This goes doubly true for startups in my opinion because rushing things like this and having a shaky foundation just adds another point of failure to your organization. Remember for every startup that succeeds, multitudes of others fall flat on their face due to a build up of problems.