Everybody looks for someone passionate for the job. Why would CS be any different?
There was a time some while ago (as I blow mental dust off my college literature studies) when "passion" was not a word that carried wholly positive connotations. It came with implications of things like irrationality, moodiness, strong emotions, even violence.
Passion can be an asset if a person must maintain momentum in the face of hardships and competition. It can be the base for tremendously hard work (which is one reason I think employers like it). But, it could potentially be a liability too, if it drives a person to create conflict or inhibits teamwork. Depends on the role and the team.
* Discussing and ultimately making decisions
* Learning about how things work from people with a different set of knowledge than you
* Doing things which optimize for the understanding of other people after you, as opposed to optimizing for your own productivity in this second
Software engineers who do these things with low empathy end up contributing to the stereotypes about engineers who are unpleasant to work with because they don't consider other people.
If you mean CS in the academic sense, e.g. algorithm research, probably not much.
If you mean CS as in "occupation that involves designing and/implementing software" then I'd argue empathy is an integral part of being an effective professional. Empathy facillitates effective communication and ethical/moral decisions.
I think the idea that "all that matters is your code" is flawed. It's very short-sighted and narrow minded, and it does nothing but to artificially limit oneself. The world is bigger. You interact with other people and can have either a positive or negative effect on them.
Some of those other people might not know as much about CS, but might have other skills like design, marketing, management, etc. Empathy is a trait that helps one to appreciate and adapt to these differences constructively.
I think it is a shortsighted strategy, but not one without basis. The supply problem is real.
Saying that you shouldn't hire people because they're only in it for a paycheck and not passion is just shorthand for I want you to make this your life, but not pay you to make it your life.
Subsequently, what I've seen is that most problems in the field of k-12 education in the states can be tied to this sentiment.
One of those places, however, did slide after a few years into the nastiness described (I left when the slide started, and it reportedly continued). Another
So while "Passion" CAN mean "we want huge levels of uncompensated work without complaint", that has not been the norm for mean and I think it's a mistake to assume that is what is always meant. Certainly I've been at some great places to work that I'd have avoided if I thought asking for passion was a negative.
My usual retort is why should I care about a founder’s vision if I don’t have a substantial amount of equity in the company? They find that highly insulting.
Nothing wrong with believing in the product or the company, but there is something wrong with thinking that would be enough. I don't think the entitled executive syndrome you're discussing is really the norm for companies, but yeah, I've encountered it and it's annoying.
Come on, you can't leave us hanging like this... What happened there? :)
A more charitable interpretation of "passion" would be... I'm nominally a Python & Scala programmer (according to my CV), but I can also competently talk about OCaml, Haskell, Rust, instruction scheduling, tracing JIT compiler implementation, propagating type inference, TCP stack, C memory model, register allocation, hardware concurrency primitives and ring 0 privileges.
Compare that to another Python programmer that once tried to convince me that when a C++ program tries to access unallocated memory "the computer just throws an exception".
But would you consider someone passionate if they said that they only care about learning a language/technology/framework that is marketable and doesn’t believe in learning for its own sake?
Unless the Python developer is actually writing C++, I don’t think he would ever need to learn the intricacies of C to be a good developer.
But take that opinion with a large grain of salt. I spent 12 years bit twiddling in C/C++, 10 in C#, and have been doing Python for a grand total of 6 months so I definitely haven’t done anything complicated with Python.
The end result is, that (1) my knowledge and skills extend way beyond any of my past or present job descriptions, and (2) (this is probably even more important for employers/productivity) that I'm capable of, and curious enough to actually want to, learning quickly/deeply and solving hard problems that might not have an obvious instant-knowledge-based solution.
I think that anyone that has ever had an interest to go "beyond" (in any way) the obvious, or immediately what's necessary in his/her day job, would built such a knowledge base - but could of course be completely unrelated to mine (e.g. networking specialist, cryptography geek, hardware/embedded engineer, ...).
Wants to stay competitive and be able to earn near the top of local market => interest => knowledge.
There's no immediate reason to expect a company to help train up employees (not just juniors, but moving people from every level to the next step)....unless those companies want to improve the outcomes of their staff, want to improve morale, and want to resolve their perpetual difficulty in finding people senior enough for their needs.
Don't do it out of social responsibility, do it for keeping your business functioning long-term. I've worked too many places that have almost exclusively senior devs with more work than they can handle. They focus on hiring MORE senior devs (but don't have much success), meanwhile their senior devs are spending a lot of time doing work that junior devs could accomplish.
There are numerous side-effects too - mentoring (if you like it) can help improve your own skills and outlook. Fresh perspectives are always good, and once someone gets their first few years in, they will occasionally have insights that seniors can learn from. At the best places I've worked the more senior devs have wider perspectives and deeper experience, but the "who is right" between junior and senior becomes more of a statistical model than a certainty.