368 karma · joined May 5, 2020
It used to be true, and was a valid criticism. It hasn't been true in so long, that claiming so says more about the claimer than the language.
On one side, there is a depressing number of people out there applying for programming jobs who effectively can't code. Their "skills" range from mindlessly repeating previous patterns they were told to use elsewhere without considering their applicability to the current context, all the way down to literally copy/pasting code chunks till the program appears to be working. Many of this group either don't care, or are blissfully unaware of what they don't know, or how little they know about subjects they believe themselves to be experts in.
This group is the majority of applicants. This is where the take home coding tests come from (which frankly, I also loathe).
On the other side, interviews are usually conducted by who-ever has been at an organisation the longest, and/or is most willing to put up with the shenanigans of interviewing the group mentioned above. This often means they're the ones most likely to enjoy catching people out, or who have some particular thing they like to grill people on. This is where you get the twenty-questions bingo style interviewing. Your recent interview sounds like one of these.
To add to this, there's a variety of situations where the applicant _should_ get the job, but they don't for reasons outside of the interview room. A manager wants to hire someone they know. Due to reshuffling, the job requirements have changed between publishing the job ad and interviewing. The budget was curtailed after the interview. Chances are, you'll never know the true story.
In addition, a large portion of developers don't ever go through the normal recruitment process. They'll do interviews, but they're recommended by colleagues, members of their meetup, friends of the above, or their IRC / Slack / Discord / etc group, and their interview process will reflect that. This is currently the best way to get a job. Often these groups are invite-only, and effectively invisiable.
In the middle of this maelstrom, are the few reasonably competent applicants applying for a job that is right for them, with a reasonable and fair interviewer.
--
Based on all the above, without knowing a thing about you, I'd be forced to conclude one of three options: a) You've just been really unlucky. I've been there, it sucks. b) You're not actually as good as you think you are. Usually this is when a programmer hits a certain level of expertise and stops learning anything new for some reason. Sometimes this is down to ego, sometimes it's because they've become the biggest fish in a small pond. The symptom seems to be a lack of curiosity, if not hostility, about novel or unexplored concepts. c) The above observations are based on my incredibly biased view of my corner of the world, and don't match your reality at all.
That's a large figure, but it's not as if New Zealand lacks any kind of other industry. There's a massive primary industries (dairy, meat, logging, wine, plus others) where the country hasn't yet fully exploited it's opportunities yet for secondary value-add processing.
As a completely anecdotal observation, most tourists go to the South Island, where roughly a fifth of the population lives. The North Island is four times as densely populated. This disparity sometimes leads people to believe that country is entirely dependant on tourism, with a few sheep thrown in.
[0] https://tia.org.nz/about-the-industry/quick-facts-and-figure...
Arguably the same problem would exist in other languages, but at least there we would have had the option of using threads, and we could have executed multiple calls to SQS in parallel. Probably not something I'd want to do all the time, but it would be nice to have had that option in this case.
The example was where each SQS call (there could be as many as five) was taking between 50ms-200ms, and logging took another 75ms. The rest of the request processing time was approx 50ms.
There's a bunch of other architecture options we could have looked at, but due to the share-nothing nature of PHP, they weren't an option.
Just to be clear, my reasons stated above is why I'm moving to Kotlin. I make no claim that other people should or would want the same things. I've realised that I like languages with explicit strict typing, and that allow for a greater level of expressiveness at the cost of a higher intrinsic complexity and the comprehension that requires.
If PHP hadn't made advances in it's type system with the 7.x series, I probably would not have stuck with it this long.
However, while PHP the language supports strict typing, it does it at run time (inherently a limitation of scripted languages, I know), rather than compile time.
Requirements were strict typing, functional programming support, built-in concurrency, decent library support, and real support for both native and Javascript. It pretty much came down to Kotlin or Rust.
I really want to like Rust more, but the library support, and the jobs in my area just aren't there (yet?).
Picking up Kotlin feels like coming home.