The process right now seems focused on finding people who are the best at only coding. In the future, do you intend to also consider communication skills? Senior developers act as mentors for junior employees, and often need to coordinate projects across multiple teams.
The best way I can describe the difference in stress is with an analogy. When I visited the Grand Canyon and hiked around the mountain, my body literally froze. I couldn't move a muscle even though my mind knew I could do this and hike around. I knew it was irrational, but I was powerless. This is what interviewing feels like - a fear of heights. And with every rejection letter, the fear is reinforced.
Stress in the office is like playing competitive sports - it's a challenge rather than percieved harm to oneself.
Not exactly confrontational (though it could easily get that way if you aren't careful) but just as stressful.
Of course it's far better to avoid such situations, but they do happen.
Person after person says they do fine in the job, yet have trouble with interviews.
I've presented in rooms where the lowest ranking officer was a colonel, and most were important people at the Pentagon. No freeze up, easy peasy, because I know what the hell I'm talking about and because I know I'm not going to be judged on some bullshit evaluation. (re: "x<<8 from above). Interviews are more a crap shoot. I mostly get offers, but sometimes just utterly choke. More importantly, I usually feel miserable after.
Don't make up theoretical situations when you have real, empirical data, please.
I made no comment on what kind of interview works best. I merely observed -- what is certainly true -- that sometimes "defusing the bomb" situations actually do come up in real life, where everything is at stake and you have to work under very severe time pressure.
Do you disagree that such situations sometimes arise in real life?
If not -- if your point is that that isn't necessarily a good reason for interviews to involve such situations -- then I think we are in violent agreement. I am not arguing for defusing-the-bomb interviews. I just don't think it's quite right to say that in real life you never have to defuse a bomb.
On the other hand, the time constraints in an interview are immediate: you have a few minutes to come up with a solution to a problem (interviewer will put up with at most 10 minutes of silence or babbling), it's often a zero-to-one problem (usually there isn't a way to have a partial solution) and those factors combine into exponentially increasing sense of pressure: as time goes on you become less likely to solve the problem.
Finally, if this situation does happen at all and, contrary to my claim above, certain people do freeze up, it does so so infrequently as to be immaterial in a hiring decision in the vast majority of cases. Its practical importance is certainly disproportionate to the weight placed on it in interviews.
Personally I don't have nervousness/stress issues in interviews, but I've found that conversation screws up the analytical mode that I use when I'm programming. It's like how people say they don't like having their managers interrupt them in the middle of the day because they get taken "out of the zone." I can program or I can converse, I can't do both without screwing up both of them.
That's just my particular conundrum. People probably have all sorts of reasons (besides the possibility of them being bad at programming) for why they may have trouble in interviews.
When I'm thinking about an abstract concept, trying to visualize how the pieces fit together, 'talking it through' is not helpful either. It's really goddamn distracting.
The feedback I got from my last 'cs 101 algorithms whiteboard quiz for a web dev job' was, "You need to talk more and explain what you're thinking." Ugh. Do you want the code or do you want me to talk, because you're not gonna get both.
Personally, I've spent hours working on a project or problem only to find that, be it the result of miscommunication, lack of critical thinking by a manager, or lack of understanding on my part, what I'd created contributed nothing to the bottom line success of our organization.
Anyone, what kind of resources are there to objectively assess a candidates communication skills, leadership ability, and teamwork? What is a constructive way to provide feedback and resources for interviewees about their performance?
I can't imagine there are that many 3-4 hour projects that won't already have available code. The most important part of an at home project in my opinion is the walk through.
The best interview I had asked me to go through the project and explain the what and why I did things and asked for high level understanding of what the framework I chose or the browser/node was doing based on what I wrote.
It was an app in React and they went through why I decided to make a component for x, y but not z and then asked if I understood the virtual DOM as a concept.
To me that's the best you can do, you need to understand how the programmer thinks about problems, works through them and that they are engaged in the ecosystem at large.
IMO it depends on the position. I did a test-project with a follow up code review for my first job and it was a fantastic. If I had not gotten the job, I still would have been happy with the experience and code to show future employers.
If you are interviewing for a more junior or senior position, many candidates are probably switching jobs and are already swamped with work. Also, they probably already have some pet projects they can share. Requiring a test project may seem amateurish.