Unless the job is mostly giving presentations, it seems like its optimizing for the wrong thing. For all the talk about software development being a collaborative field, for most people it really is still mostly isolated mental work.
If you can’t boil your work down into accessible presentations and adapt them for technical or non-technical audiences, you won’t get anywhere.
Nobody will agree to help you, allow your team to grow, give you budget for tools you need, make compromises with you around integration requirements or shared design patterns, unless you can frequently convert your software work into highly professional presentations.
I’d argue that competent presenting and writing skills are of equal, or even greater, importance than software skills or expert knowledge, whether for a research software job, software contractor job, SWE within tech / ecommerce / banking etc industries - across the board there are pretty much zero types of software engineering jobs in which software skills are actually the most important thing. Presenting and writing are frequently much more important.
To be clear, explaining your work is a part of every developers job. But top notch presentation skills don't need to be a part of it. Developers can talk to other developers in sub-optimal ways that are still effective. But when your hiring process has an hour long presentation as a part of it, you are optimizing for the thing that is very likely not the most important feature of the role. The point is to structure your hiring process such that it optimizes for the right things for the role.
But also, I really really dislike when others talk about "optimizing" people. It's not possible to optimize your hiring process for anything useful. Due to this, there should be a lot more empathy in the hiring process than their actually is because everyone wants to make it robot-like by "optimizing" something.
This isn't true in my experience, there are plenty of well paid jobs where you don't have to talk to non-technical people. For example, lets say you are developing infrastructure at Google, how often do you think you talk to non-engineers? Never, everyone in your management chain will be engineers, your product managers are ex-engineers, your users are engineers etc. This is true for directors managing lots of people as well as well.
And even when you develop services much of it is just getting the technical parts right so you can work there as well at Google with very little time spent talking to non-technical people, so senior positions there are mostly about technical stuff.
You could argue that Google and other big companies are a special case, however if we exclude low paid jobs where you just earn half of what you'd do at Google or Facebook then pure technical work like this is a very significant fraction of the market. I'm not sure why I'd work on my presentations skills so I could get hired by a company paying me less.
I can speak from experience since I help run the site reliability incident response team in my (large ecommerce) company.
How often do rank and file SRE ICs need to speak with non-technical staff about projects? All the time.
They give tech talks and council presentations, they contribute work to quarterly roadmap project pitches, and they give business scorecard presentations to walk higher level managers through the breakdown of costs and benefits, why we should pay money for a new cloud tool, what time & effort some org-wide planned migration or upgrade is going to require.
Let alone basic stuff like writing effective tickets / issues / RFCs / PR descriptions, postmortems, etc., and walking teammates through work artifacts daily.
For every two hours of software work, I’d expect 1 hour of “wider audience communication” work - and that is for deeply technical ICs in roles like SRE. The closer you get to product engineering, the more the ratio shifts towards communication.
I can tell you this translates specifically to Google & Facebook - because most of the SRE colleagues in my company came from Google & Facebook, and attest to that being the case there too.
I agree with the other commenter, it baffles me that we think that asking someone to write code, when the majority of their job will be writing code, is somehow an unfair interview process so the solution is to have them give only hours of powerpoint presentations.
I've come across many a smart person who would abhor the idea of listening to a presentation, let alone give one. Give me a document they'll say, and they will go through it at depth and collaborate amazingly over text. A mix of both is required. You don't want everyone to be giving presentations all day, just as you don't want no one to be attending any presentations. Diversity is essential, and it's more effective to create structures that allow different types of people to work with one another than to mould people into personalities.
It's akin to saying that because some people have anxiety issues, we should completely do away with interviews and just let people randomly walk in and do work.
Because that's the only way to potentially avoid the criticism you gave here, only that's also not true because locale comes into play. "You didn't create a building every 500 feet that people can walk into, so now you're disenfranchising people without cars!".
My point here is that this is not a useful criticism. Come up with a useful grievance, one that's actually actionable, and then maybe we can talk.
Not every personality difference can be reduced to anxiety. That is precisely the kind of closed world-view I was talking about that can form within homogeneous groups.
You act as if the people listening aren't aware of this.
What is it you believe exactly, that if person A sounded nervous they wouldn't be hired?
The entire point is to get a conversation started, and the following Q&A allows them to do something everyone needs to do in a job, which is to answer questions.
No interview process is perfect. You can literally give me a description of any interview process and I can start finding problems with it.
Just as you can literally give me a description of any software solution and I can start finding problems with it.
That you can find problems with it doesn't make it useless or harmful. Please come up with better criticisms.
I can do presentations, however you are asking me to hold a free 30 minute lecture teaching your employees about something. I'd rather not, basically every company gets excited to hire me anyway and I'd rather spend a few hours doing some comfortable coding over spending a few hours preparing a presentation.
Technically speaking, if we're in an interview to "optimize for the right thing", then we would just have them come in and type.
But we all know that's also optimizing for "the wrong thing" despite it being what we do physically day in and day out.
This is because you _CAN'T_ "optimize for the right thing" in an interview. It's not possible and this needs to be acknowledged.
Therefore you go for something else. Anyone who is a software developer can listen to a 5-10 minute presentation from another developer and start forming general, broad opinions. They can then start asking questions afterwards to help clarify those opinions.
But the Q&A also has another purpose. Way too often interviewers will come to conclusions that don't follow (non-sequitur). I once had someone tell me they didn't feel I would be a team player because I told them as long as I had headphones, open office would be ok. The main difference I've found between business people and technical people is that business people will ask clarifying questions. The Q&A sets the expectation for the _INTERVIEWER_ to ask clarifying questions.