This is literally the only way I've gotten job offers. I'm a very competent programmer, but when I'm asked to solve some silly puzzle with someone staring over my shoulder, I freeze under pressure and can not think at all.
Luckily not everyone thinks solving leetcode problems is a good way to hire.
I've been in situations together with clients deploying a product, them presenting it for their managers, orpreparing for a big demonstration, and something goes wrong due to some unforeseen environmental factor you couldn't have imagined or predicted, and breaks in a way you don't expect, despite the weeks of testing you've done.
You've got your main client staring over your shoulder, arms crossed saying fix it, and every two minutes asking "is it fixed yet?"
You damn well better be able to code under pressure... And like a freaking ninja
I can present to audiences pretty easily, I actually enjoy it. I also don't mind at all having a client watch what I'm doing. And yet, while I have no trouble doing interviews - having worked as a freelancer that would have been pretty bad - the situations are not comparable even for me. I loathe interviews. Fortunately a lot of clients, and I've had several major companies, had people hiring me without any of the usual stuff based on a gut feeling, I had to answer silly irrelevant technical questions only twice. And once I even failed "explain a right join" - something surely everybody would be expected to know, and of course I do, but at that moment I blanked. I go the job anyway but it goes to show that even to me interviews are a very different and greater kind of stress than anything normal work can throw at me. Even if it looks the same, it isn't, not at all! The brain knows context.
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.
Most tech jobs aren't like that. If the job you're hiring for is one of the few that involves high-pressure coding in front of strangers, then by all means test for that.
I have never in 12 professional years been given weeks to test anything. On only a couple of occasions have I been given 3-4 days to extensively test a project with multiple months of development time behind it.
Clearly you're talking about the project where the developer(s) told you very explicitly that it could not be done in less than 3 months. So you just assign the Jira ticket a 3 week deadline anyway. And then flip out when a half-assed project fails to ship. Welcome to the world of software development.
This is not a good way to hire people. I can do all those things, but I'm not normal. Some engineers do a lot better under stress with a system that they're very familiar with. Others do better under stress when they're working with people they know well. And still others are great engineers but aren't the person to be in front of the client under stress.
Congratulations that you can do all these things -- but unless 100% of the engineers in your company need to be like you, you might not want to use your list as hiring criteria.
Being able to code under pressure when the world is burning is also different to working under pressure of a deadline. Or rather, being on the last day of a 30 day deadline isn't the same kind of pressure as being told you have an hour to complete a complex task.
Not everyone needs to be able to work well when the world is burning. Its not part of many jobs. However, if it is part of your job (eg your the guy who has to fix stuff at 4am) then I see nothing wrong with asking candidates to do timed work in an interview. I just think most jobs don't or shouldn't require this.
In consulting you get in similar situations. In those cases it is not a "be able to code under pressure..." thing. Rather, a "know your code well" one. I have also been in a few demos where everything fails. As the manager sitting next to the client with your arms crossed, you have to know how to defuse the situation without having someone sweating their soul on a keyboard. Been on both sides.
if that's common then it's a reasonable criteria for the position, sure. That hardly ever comes up in my work environments, so I'd be happy with an engineer who is awesome 99.999% of the time when they aren't in this position.
If you can't code under pressure, you aren't a very competent programmer. Real world projects come with high pressure scenarios for software engineers. Code monkeys may be able to get away with low pressure, minimally impactful projects.
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.
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.
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.
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.
You're getting hammered for this, but for some jobs you're absolutely right. If you can't handle being put on the spot for a simple interview question, how are you going to go when a production line is down and it's costing your client $100k/hr, and the foreman's standing looking over your shoulder wanting to know when it'll be working?
Not all jobs give you all the time in the world on a test server without interruptions.
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.
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.
Luckily not everyone thinks solving leetcode problems is a good way to hire.