1. General problem solving skills. A lead developer needs a whole bunch of skills that aren't listed anywhere on that list.
2. More slowly changing technologies, and underlying principles. E.g. Python and Java will be around for a long time. RDBMS have been around for even longer, and will continue to be around.
3. Ability to learn new technologies quickly.
And if you do it right you can get job that claims to require certain technologies even if you don't have know them.
Longer version: https://codewithoutrules.com/2017/07/16/which-programming-sk...
(Blog post I linked to talks about that in more detail, and I talk a bit more marketing vs. skills here: https://codewithoutrules.com/2017/01/19/specialist-vs-genera...)
That is, if you understand the ideas behind Smalltalk well enough, you will have no trouble picking up Ruby, Python, or even PHP; swap the initial language to taste.
If you are a beginner and the amount of ideas you know is limited by the two languages and a framework you picked up so far, then yes, matching a checklist of an employer is more about the specific tech. The farther from that, the less.
edit: should be fixed now
- Go took a dip in demand, down from the 6th most mentioned language in listings to 8th.
When looking at trends from all 2017 reports:
- The top languages steadily in demand this year have been: Python, JavaScript, Java, Ruby, SQL, CSS, HTML, Go, C, and C++
- The top four application frameworks have fairly steadily been: Rails, Spring, Flask, and Django
- React is the top choice when it comes to UI libraries/frameworks. Angular doesn't seem to be gaining on it, and mentions of jQuery have been steadily declining.
- The top three databases/stores have steadily been PostgreSQL, MySQL, and Redis
Fairly standard/boring "we're making a monolithic app in a dynamic language" stuff.
edit: should be fixed now
I imagine quite a few do. They may not be using the map/reduce API (although there are almost certainly use cases where that makes sense too), but HDFS and Yarn are pretty ubiquitous.
"Must be an excellent communicator" - unless they notice you have a hard time talking to them in the interviewer they don't check for it. They don't ask you to write an email for something, or create a presentation, or explain some difficult technical concept to a non-technical person, etc.
Btw, those are communication skills. There are many others that are also important
1. Kubernetes, me: uhm, ok
2. Terraform, me: WTF
Also HTML/CSS as languages? Erm, okay.
The idea of Open Source was still in its early days, and only Perl had a great central library of code that was free for anyone to use.
And of all these languages, most were hot with a fanatic idealism about how Object Oriented Programming would solve the problems of the tech industry. Those languages that rejected Object Oriented Programming (Python and PHP, and also, to a lesser extent, Perl) were proud of their defiance, till the moment (a few years later) when they gave in and decided to become Object Oriented.
There has been a convergence of culture. Nowadays most programming languages have all of the same things:
1.) package managers to manage your dependencies
2.) frameworks with command line tools to automate setup and database migrations
3.) multi paradigm -- most languages now facilitate Object Oriented Programming, but also Logic programming and Functional programming and pattern matching, and other paradigms.
4.) open source libraries of code for everything, typically on Github
Nowadays I can go from writing in Python to writing in Javascript, and most of the stuff I expect is exactly the same in both languages. I can think these words about practically any language that I am asked to work with: "Oh, I have to write a module to send email to new users? Okay, let me look up the open source libraries that handle email. There are probably a dozen projects on Github"
There is much more of a mainstream to computer programming than their used to be. This "normalization" happened first with software for the Internet, though lately its even been spreading to hardware projects. A few languages (Clojure, Haskell) still have strong philosophical differences from the mainstream, but they offer the common basics, like any languages that nowadays wants to make a programmer feel productive.
So these lists of skills are less meaningful than they used to be. Once upon a time it would take months to give up one language and learn a new one, whereas nowadays the switch is easier, since so many assumptions that are true in one language remain true when you switch to a different language.
It definitely still hits a nice sweet spot in terms of battery-included frameworks for rapid web application development.
I'm not saying these things aren't important. Just that it's almost never included in a job description, and it's invariably eye-roll worthy the few times they are, because no one tests for them explicitly anyway.
"Time management skills", "Ability to prioritize effectively", "Able to handle stress in positive ways", "Able to self-task", etc; no one changes their interviews to actually test for these things. Well, except maybe for seeing how someone handles stress, but frankly, we've heard about companies who do that, purposely make the interview as stressful as possible just to see how someone handles it, and we hate the very idea of it.
Once you're experienced you can start treating those lists as nice-to-haves, if you have the right core skills and present yourself the right way.
Interviewing people about their experience is a traditional way to verify things. E.g. If I'm looking for someone who can solve hard problems I can ask for examples. If they're beginning programmer who just got handed tasks like "code this function"... they will have no good examples.
I can also explain a problem I'm working on and see how the candidate approaches it.
But writing job posting that hides the fact I need someone who can solve hard problems seems silly.