The equivalent the other way. If programmers hired like carpenters are hired made a table:
"How long will it take to make this table?"
"3 weeks. But we're going to try using this new kind of leg because it's easier to replace with another leg if you don't like it. So it may take 5 weeks."
5 weeks pass
"Is the table done?"
"Well, no, not really. But now you can have four different legs if you want to. We've also got this table building machine that can make all the different types of legs that will slot in"
"Can we use the table-building machine to build the table?"
"No, it only does legs right now"
10 weeks later
"All right guys, it's been twice as long. Is it done?"
"Yeah, we're finished. You're going to love this. We upgraded the table building machine so now it builds as many tables as you like. All you have to do is sketch out a full blueprint. We've got one blueprint for the table you want, but you can make more if you like"
"Where's my actual table?"
"Oh, it's that pile in the corner. It's broken, though. Jack placed a red cup on it and it fell apart. You're not supposed to do that. We told him to use blue cups. It's in the manual. We explicitly fixed blue cups last week."
Dev: Ok, give me 2 days and it is done. after 2 days Here's your particle board table about 1 meter off the ground with seating for 4.
Customer: Great, but it would be nice if it could seat 6 sometimes because we sometimes have guests.
Dev: Ok, give me half a week. 3 days pass Ok, here's your table for 6, we had to change the material to wood to make it more durable and unfortunately it increases the cost.
Customer: No way I'll pay extra for wood. What's wrong with particle board? And the texture of this wood is too noticeable, the texture has to be more subtle. And we want to minimize the size to a table of 4 when the guests are not around so we can have more floor space.
Dev: Ok but expandable tables are significantly more complex and I don't think we can do it with your cost contraints. Can you consider increasing the cost?
Customer: What are you talking about? When I asked the Indian shop down the road they said it was possible at this cost. Are you lying to me? If you don't fix this and deliver then I want my money back and I'll just go with the competition.
Dev: Ok, we obviously can't compete with that price so here's your refund. But we highly don't recommend that shop because you will have issues with the table.
Customer: I think everything will be fine. Good luck to you and don't try to upsell me.
6 months later
Customer: Here's the table the Indian shop built. It sometimes won't collapse and they can't figure out what's wrong with it. Can you fix it?
Dev: Ok, we can take a look... You see the problem is this rail design is not fit for these specifications. We can fix it temporarily but in order to fix it permanently we have to rebuild the table top surface which means only the legs will be reused.
Customer: What do you mean? Can't you just install new rails?
Dev: You see, particle board is too flexible a material so over time the fasteners will fail. That's why we recommend wood. But you didn't want to pay for that in the beginning so we didn't want to continue with the contract.
Customer: Fine! Fix it, we need the table next week for a dinner party. How much?
Dev: Our backlog indicates we're booked for the next month. So to prioritize this job we need additional compensation as we'll temporarily have to hire additional help to satisfy demand.
Customer: Are you crazy? I can get 2 new tables that don't expand for that price. This isn't rocket science, I'll find my own way.
6 months later
Customer: We need a table. We're ready to pay anything.
Dev: Oh, you're in luck. Expandable tables are now free of charge. We only charge an installation fee and optional warranty fee if you want us to fix potential issues after delivery. The only catch is they only come in white.
Customer: Excellent, but what about brown? And since it is so cheap now can't you make it height adjustable?
Dev: The brown configuration is a small additional fee but the height adjustable feature has to be made from scratch as it is new technology. It is quite expensive because the motors have not been validated yet, so we have to do a qualification test on each part.
Customer: what? just give me the white table and I'll go talk to the Indians again.
---
Software often has expanding scope and new "innovative" requirements. It is almost never the case that we have a fixed deliverable; once the customer has a solution, they immediately want something else improved. This flexibility manifests on additional R&D costs for new or customized technology.
I once did a website to specification + some additional optional, free bells and whistles. They were like this is perfect! everything is great except for some small changes....
the small changes never stopped coming until it was a new website. I kept all the major versions so they could see their changes as they developed, so that when they demoed it to a focus group one of the people accidentally navigated to the original version.
next meeting: What is this website? a user accidentally navigated to it and this is now what we want. ... the original version
Haha. The references to Indian developers were funny. But this joke works even if you replace Indians by other developers in US. Remember healthcare.gov fiasco?
The same is said about Indian outsourcing (expensive in the long run), right?
I think many people miss the fact that boring jobs with low wages will not attract talented programmers. Same holds true when you outsource jobs. Send interesting jobs and pay for good Indian programmers for quality results.
healthcare.gov was a clusterfuck not because it was complicated (a typical data integration task with a query layer) but because of the quality of programmers and managers working on it. Later after political and international embarrassment, a crack team of exceptional programmers was assembled (on leave from major tech companies) to fix that website.
But communication overhead and a wage that attracts talented programmers in India, will make development there just as costly as if you do it locally. So your manager outsources to cheap Indian shops, and then always gets frustrated with the quality.
One of many hidden truths here is that software is expected to scale easily and change easily while physical objects don't have these expectations attached.
Interviewer: since you have experience working with wood, show us how you would implement photosynthesis on this whiteboard...
Or
Interviewer: what's the most popular kind of wood right now? Exactly. We're putting together a team to make a sink using it. In the second phase we will use wood to build a toilet. Interested?
Or
Interviewer: A carpenter? We were looking more for a mahogany-scientist or a pine-wizard. Are you even a spruce-ninja?
Please draw the molecular diagram for Cellulose. What if the requirements were a 20% increase in cellular wall strength? Design a new polysaccharide that fulfills this requirement. Select a plant, how would you modify the genome of that plant to begin producing this new cell wall.
Given this sequence of basepairs, compute the resulting protein that may be expressed from this sequence.
Suppose Xylem was no longer an accepted technical solution, how would you move water from the roots to the leaves of a tree using only things the tree could grow, and the sun? Compute the maximize tree size using your new method and design a plan for implementation in 3 generations of selective breeding.
Show on the whiteboard the for producing ammonia-based fertilizers at industrial scales, use the Odda process instead of the Haber one. How can you prevent ammonium nitrate from entering a tetragonal crystaline state at 84.2C?
Design a table saw that uses a linear electric motor instead of a rotary motor, assume a 7.3V 5A input source. If we wanted the saw blade to turn at 7300rpm, what gearing ratio would you use in the 3rd translational gear? Compute the lorentz forces on the components and show the resulting torque in an assumed ideal zero gravity environment. Diagram out all vectors on the whiteboard.
Wow, as an analogy this is brutally accurate. And suddenly I realize the answer to all 5 questions is "Fuck off, next question" which is why it's essential that I never have less than a year's salary in the bank.
> what's the most popular kind of wood right now? Exactly. We're putting together a team to make a sink using it. In the second phase we will use wood to build a toilet. Interested?
>> what's the most popular kind of wood right now? Exactly. We're putting together a team to make a sink using it. In the second phase we will use wood to build a toilet. Interested?
>that's actually kinda fun!
(years later) ... and that's how I ended up installing toilets in exchange for equity.
Interviewer: Could you give us a couple of examples of carpentry projects you have completed in your spare time, and do you have a portfolio of projects you have worked on outside of your day-to-day job?
Carpenter: Uhm, what do you mean?
Interviewer: I mean like carpentry in your community, or a project you've completed to hone your skills outside work?
Carpenter: Oh, I am usually quite tired of hammers and nails when I get home and I like to spend some time cooking and cycling, but my carpentry work I do in my day job I am really proud of.
Interviewer: We are not really interest in your day job.
Interviewer: Also, do you have any full stack experience?
Carpenter: Yeah, I guess.
Interviewer: How quickly would you adapt to using a new tool framework that comes out in the market?
Carpenter: I would rather choose to use the tools that I have honed my skills in and am good at.
Interviewer: But, considering the toolbase that our org uses, our other carpenter say that some new kit/framework comes out every other day and they all keep up. I think that toolbench is called JS in short.
Carpenter: ...
Interviewer: Also, how about the fragile methodology, any experience in that?
Carpenter: Yeah, I guess.
But strictly speaking, considering that the outcome from both disciplines carpentry and software development are on opposite sides of tangibility, a straight up comparison isn't really helpful, to both disciplines.
It would be pretty cool if programmers could show their day job programs the way a carpenter can say "I build this" and people could look at it to see its quality. Unfortunately, this is often not possible.
Shouldn't have to. Should be able to talk intelligently about what you do and that should be enough. If I write SW that interacts with RFID readers, I should be able to talk about the various protocols. I should be able to talk about poll vs push and the benefits (and pains) of both. I should be able to talk about how to architect a performant system that gets the data from the devices, processes it and sends it on to some other device.
I should not have to worry about not being able to show any of that. If the people interviewing me don't understand what I did without me showing them, then I am certainly applying at the wrong company.
I once wrote some software that needed to interact with RFID readers. I couldn't talk about protocols then and I still can't today, but the program is still running just fine 10 years later.
Don't underestimate the value of some general understanding / intuition of how systems will probably work combined with a little googling.
I agree. I also read somewhere that talking about past behaviors (e.g. how you solved a complex issue) is the best indicator for competency (I can't back that up with sources sorry).
On a side note I also worked with RFID readers, they were yesteryear's Internet of Things :).
I agree reality is probably more subtle that this, but I do feel that there is too much emphasis on public repositories in application processes.
It's probably more common for recent graduates to have public repositories than for the majority of senior devs. Then again I'm sure there are other pressures graduates have to deal with that senior devs don't.
I don't know what kind of emphasis you've seen, but being able to look at a public example of code a person has written is IMO the single biggest risk reducer available to a company hiring developers (well, other than actually having worked directly with the person before, which is an order of magnitude or two less common) because it gives me a picture of performance on real world software. Hiring is substantially about risk reduction because there's a huge amount of stuff you don't know about how the candidate will do. It would be foolish for companies to not take advantage of this potential source of signal. If it's not available, then I would proceed with my normal assessment process. Lack of public code isn't going to disqualify a candidate, but it does help to increase my confidence.
I suppose that is fair enough, and I don't think there is anything wrong with it being one of the ways in which companies assess potential candidates.
From my recent experience (and anecdotal evidence) it seemed it was becoming a deal breaker for companies but maybe I reached that conclusion too quickly.
Ive been in the game a while now , almost 18 years - 7 as a dev, and still get asked by recruiters generally within the first or second question if i have a github profile. Nope, I moved to BitBucket. Recruiter: never heard of it, what's that?
It'd be nice if tech recruiters actually had a background in tech.
Too much emphasis? Most recent graduates don't even have a GitHub profile. They get jobs because they graduated. It's totally fine.
If you did not graduate, you better have some projects to show though.
That's interesting. For companies I have approached recently it was the first question they asked. Maybe it depends on the kind of company (for me it was mainly start-ups).
How often can a carpenter really do this? What if most of his clients won't allow him to take pictures? And certainly most won't allow strangers to come in and fondle the furniture.
It's not uncommon for a contractor or architect to take pictures of a building after it's completed to use in their marketing material. It's pretty standard unless the client requests that they don't.
Few years back, had a knock on the door. Dude was there, said that he built our staircase, and could he take a couple pictures. It was a massive open log staircase, it was pretty cool. Filled us in on where the wood was from (local).
If you can do this that's great - often that is not possible for various reasons, usually "You wrote code for an employer, the employer doesn't want you to show that code to someone else".
I wouldn't be surprised if there was a pretty high correlation between working in a trade like carpentry and having a home workshop (it's almost universally true in my anecdotal experience).
You forgot the job description beforehand that expects the carpenter to also have experience as a metalworker, welder, plumber, electrician and bricklayer. Oh, we could hire all those roles separately, but hey we want a rockstar ninja capable of everything who's willing to work for less than market rate.
I'd flip that around. The key question is "Have you actually built a house? You didn't have to do all of the work, but have you built a house and understand how all the pieces fit together so you could help us build us a house of our own? Could you help us hire a plumber, know enough about his work to keep an eye on him and help him out while we're out playing golf?"
"Heck no. I've spent the last ten years becoming an expert in cabinet doors. I don't worry about all that other stuff."
This attitude of breaking things into tiny silos is how you get small projects with 30 people in them that still can't deliver a working product.
Yeah, exactly this. The parent is describing a general contractor, not a carpenter. Even general contractors tend to subcontract out the specialized stuff, like designing the house, installing computerized gear, etc.
A carpenter knows enough to know not to try and do the electrical work, because he'll probably do it wrong.
You're supposed to know the job above yours. You don't have to be capable or qualified to do it, but you need to be familiar with it.
So yes, I am somewhat describing a general contractor, but not really. A GC both knows and manages the work. A good construction worker generally knows what is going on and can pitch in and help (given the appropriate supervision) when needed.
Or put it this way: good construction workers could be really lousy general contractors, but they choose to stick to one area of speciality and become an expert. Really bad construction workers are extreme experts in one area -- to the point that they are obsessed with trivial bullshit that makes no difference to anything -- and refuse to open their eyes to the bigger picture going on around them. It's a difference of whether you're looking outward to the overall value being provided or looking inward to your own little world.
I've worked with good carpenters. They'd never touch an electrical box or plumb out a system, but they can describe what kinds of things happen when this work is done. They can also tell stories of how folks in those areas run into problems and how they've assisted. The physicality of construction, the fact they're all in the same place, makes for really good carpenters, especially if they've worked various kinds of jobs. In IT a hell of a lot of programmers actively want to be physically separated from the overall work.
You can know about everything involved without having to be able to do it or manage it. And you should.
> Really bad construction workers are [...] obsessed with trivial bullshit that makes no difference to anything
That describes bad employees in general. And if we bring this back around to programming, I'd absolutely expect a back end developer to know a bit about the front end, and the design, and the architecture (and help out if needed).
Here's the key difference: "[A carpenter would] never touch an electrical box or plumb out a system." Software companies, in contrast, routinely expect front end developers to design (because it's all just CSS rules), to write backends (it's the same language), and to deploy in an easily scalable fashion (because "serverless"). That is where the expectations differ.
Note I didn't say one person does it all. The question was whether or not the person was familiar enough with all of the types of work to be useful across-the-board (even if they weren't an expert in all of those areas).
Even on a skyscraper, you can bet that all the senior folks there understand the basics of most all of the jobs involved. You don't work in construction without understanding the job in general. This is opposed to IT, where it can be common to hide away in some sub-area and never have experience watching and helping other folks do their work. In many large orgs, the vast majority of developers couldn't build a plain-jane web app from scratch. That's pretty whack.
What are the dimensions of the house? How much will it weigh? What's the lay of the land? Is the soil compaction sufficient? Are there city utilities, or will we have to hook up a well and sewer?
It's about 2000 sq ft.
Those aren't dimensions.
Oh, just figure it out! We need it installed by Tuesday, we're giving it to the client then.
The article is from 2004. In the meantime, we've seen considerable progress. The mindshare of banging nails with rocks (as opposed to a nailgun or a hammer) has gone up considerably since 2004.
Banging with rocks is out of date. We now bang nails with concrete — that way you can cement your banging tool out of any pebbles you like. Sure, sometimes one of the pebbles (like the one that keeps the left side of your banging block straight) falls out and gets lost and you can't bang any nails that day, but that's the price of progress.
But now the smooth rock is hard to grip and deflects off of the nail too easily and you still scratch your hands or smash your fingers. Not to mention that each smooth rock is shaped slightly differently. When you get your technique down with one rock and try the nail with the other rock you're just back to smashing your fingers. And don't get me started on the million and one rock and nail toolkits.
Technical interview:
Interviewer: Ok, so you have only 4 boards here and two nails, can you figure out a way to make a standing pyramid that won't fall over?
Carpenter: Will I be building pyramids or is there a limit to how many nails we'll have during construction?
Interviewer: No, but we want to assess your critical thinking skills.
Carpenter: (Arranges Pyramid) Ok, I think its done.
Interviewer: Hm... ok well it was kinda slow, but I guess you did ok. Alright, next question. You have 100 boards, for every one that is fir, say "Fir", and for everyone that is Birch say "Birch", and for any that are both "Fir" and "Birch"...
NEXT DAY:
Ring...
Interviewer: Hello?
data scientist: Hello. Remember me, I'm the data scientist you interviewed for the black AI job. Just wanted to touch base to see if you've made a decision.
Interviewer: Actually, we have. We liked your experience overall, but we decided to go with someone who has done a lot of work with ML.
data scientist: Really, is that it? So I lost the job because I didn't have enough ML?
Interviewer: Well, it was partly that, but partly we got the other fellow a lot cheaper.
data scientist: Really -- how much experience does he have?
Interviewer: Well, he's not really a data scientist, he's a car salesman -- but he's sold a lot of ML cars and he's worked with AI interiors.
data scientist: [click]
Interviewer: So you'd like to be a CEO?
Candidate: Yes
Interviewer: And you've worked as a CEO before?
Candidate: Yes, three times. All those companies lost market share, worker satisfaction, and credibility. But the share price increased - at least until after I left.
Interviewer: Great! See you for a couple hours on Monday. What time after lunch works for you?
> Interviewer: How long have you been doing it?
> Carpenter: Ten years.
Now if that were 20 years, instead of the rock it would be a complex, slow hammering machine that employed tumbled-smooth colored rocks.
Those rocks would pulled from a shared quarry at the point in time when they were needed.
The new way to provide such rocks would be to order a large truck carrying the rock hammering machine and a set of subcontractors you'd previously had to train by showing them videos on an old VHS tape player. However, the truck would still need to be loaded after each materialization for the job. The truck usually would contain the same supplies, but sometimes some of the rocks would be replaced by scorpions.
Whether or not to use the truck at a job and which trucking company would be a point of debate. Google Building Co. would make the best fleets of trucks with laser targeting systems that made sense to the highly-intelligent, fluffy bears that worked there. Microsoft Building Co. also had two versions of trucks: the old truck that was much slower but worked with existing technology and the new truck which worked if you used a Danish truck and better smaller rocks that few people could find. All of their workers swore like sailors. A subcontracting team all wearing red baseball caps worked with both companies, but supplied their own equipment that was all transparent, and you could either pay for it or not, depending on whether or not you got it from someone else they gave it to.
I think this is a great way of hiring people. With certain caveats of course: your company must give candidates, preferably one at a time, an honest chance and not exploit them to get leaky roofs fixed for free.
This is the way to go. Still do the usual screening and interviews (hopefully without incompetent recruiters in the middle) but then pay the developer fairly for a small project and see how it goes. Repeat if necessary.
The only problem I've seen with this approach is where the applicant is legitimately pressured for time by their current work or family issues. Being understanding and working out how to extend the trial period will get you through most of these.
In countries (like mine) that don't have at-will employment it amazes me that employers don't insist on this approach. Instead - weird filtering by recruiters, overly specific interview questions and then disappointment when recruiting goals aren't being met and stress when developers who aren't a good fit are stuck with the team for years.
So you always have leaky roofs at your company? And if you don't like what he did, you just keep the repairs? Sorry for being picky, but you could've used "make a dog house" or something like that. I hope you don't put patches from interviewees in production code.
I should add that it's illegal, at least in California, to have somebody do productive work and not pay them. So if somebody is using work on a production system for an interview, you either must pay them for their time or you must throw away the code.
Q: so you're a programmer, how many years experience?
A: 10
Q: ever make a web application?
A: yes, I did I..
Q: great! you're hired!
A: Uh, don't you want to know what languages, frameworks, backend systems I've used?
Q: what no, you've built web applications. You will come in and do that right away because you built web applications!
A: uh, don't you want to know what my thoughts are on testing, product management methodologies I prefer, team sizes I feel comfortable with?
Q: no, of course not! HELLLOOO, web applications here. They're great, you're a natural!
A: Uhm, what size are these web applications meant to scale up to?
Q: any size that's reasonable of course! The size of web applications that people use! Be here tomorrow we're going to start you off right away!
A: I don't really want this job.
Note: I've never really hired a carpenter, but it seemed like the linked article didn't let the idea that these might be very different occupations get in the way of snark, so why should I?
I wish we were only hiring experienced developers, hiring right out of school and having a manager that only wants experience out of school people is insane. Do you know what oop is? Have you used git? Have you ever indexed a table column to speed up queries? Any MVC experience? How comfortable are you with the language ? Do you know anything about sql injection? Have you used the inspector on a web browser before? Get half right and have a sense of humor and you're probably hired but we hire 2 in 20 interviews a year.
One upside is i don't have to worry about some jerk giving me an unearned critical review on Angies List and thus killing my search rankings when someone looks for a programmer.
I had a similar story except swapped paint and wood with specific vendors for power tools and hammers and other generic tools. I call this "The Stanley problem of resume shortages".
Software is software. The paradigms are the same. The languages have the same roots. What is culture for a programming language anyways? Sure, the tools and frameworks are different, and every language has it's own quirks and uniqueness but they're not as different as you make it sound. If a developer is skilled, these are small differences.
I think that the differences are bigger for inexperienced developers (and experienced ones who don't try to understand the theory underlying their work).
A novice PHP developer will (or at least would have 5 years ago) create a messy script with interspersed HTML and PHP, a SQL injection vulnerability or two, and little code organization.
A novice Java developer will implement a bunch of patterns they don't understand (probably misusing them), and write a mess of code with too many side-effects.
An experienced developer can write good code in either language, and many of the patterns will end up looking similar.
But wait, the implication here is that "the theory underlying their work" is similar for most languages?
Don't Haskell and Java differ significantly wrt Type systems? And the rigid class structures of Java might cause one to build very different programs that you might in a more dynamic language?
I can switch between languages. But i learned to write code in PHP, Java, C++ and other languaes. There is no necessarity for someone, who is a PHP or Java Developer to switch easily to another language.
It takes a few weeks, month and perhaps 1-2 years for someone and i think it is fair enough to decide to hire an java guy for a java position over an php developer and to ask this in a job interview. It might be also okay to hire some php developer (or vice versa) but dismissing it, that there is a difference, is wrong.
I don't think you need to dismiss it as a factor. I think there are quite a lot of people who can get into a new language in a matter of weeks. That's really not the issue, you just have to find out if he's motivated to get into it. Because motivation is key. If your PHP developer is excited about becoming a Java developer he'll do fine. If he wants to stay in his comfort zone it's not.
So Clojure, Java, Javascript, Haskell and Ruby are all basically the same?
I think damage can be done hammering different languages into the same methodologies..
> If a developer is skilled
You suggest skill is generic. If a programmer is smart they can learn new paradigms. Projecting the paradigms they are used to onto new domains can produce problems, least of all the standardisation.
> So Clojure, Java, Javascript, Haskell and Ruby are all basically the same?
Nice try, but we were talking about PHP and Java. Also, for instance, functional paradigm is the same for all functional languages, which is what I meant in the first place.
> You suggest skill is generic.
I'm suggesting the developer understands the OOP paradigm, knows about design patterns and isn't confused by the small differences in syntax or how much a language borrows from each paradigm. Two languages using the same paradigm are closer to each other, regardless of how different their syntaxes may be.
> Projecting the paradigms they are used to onto new domains can produce problems
That's completely true, but I'm not going to write generic comments that cover every case. I'm replying to someone comparing PHP to Java. It's my understanding the PHP is mostly OOP.
> Nice try, but we were talking about PHP and Java
You started by saying "Software is software", you didn't mean this to imply all languages are similar?
> functional paradigm is the same for all functional languages
So Haskell and Clojure are similar?
> understands the OOP paradigm, knows about design patterns
Design patterns differ between languages. And OOP principles too. I don't want to see ConfigurationBuilderFactory classes in my Python code.
> I'm not going to write generic comments that cover every case
You only claimed "Two languages using the same paradigm are closer to each other" - but this seems tautologically true, depending on how you define "paradigm". Many OO languages differ in ways significant to the Java way of OOP.
> Design patterns differ between languages. And OOP principles too
Not that much compared to paradigms. They're closer to coding styles. Once you understand what encapsulation is and how python lacks visibility modifiers, it's only a matter of using a coding style to compensate.
> "Two languages using the same paradigm are closer to each other" - but this seems tautologically true
Taken out of context, sure, but you excluded the second part. That's why I think Haskell and Closure are similar.
Eh, we picked up a developer with no experience but Erlang, and he's productive in Python and Go only a few months later. Peer coding and good code reviews (and a good attitude) do wonders.
>I think damage can be done hammering different languages into the same methodologies..
Using the incorrect nail for the job can lead to disaster or complications down the road. Think of using a nail that will rust over time being used on an exterior deck. Or a nail that is too long or thick for the pieces of lumber it is supposed to be securely (potentially splitting the boards).
> So Clojure, Java, Javascript, Haskell and Ruby are all basically the same?
Basically, yes. You learn to think how, the rest is implementation. Don't get me wrong, it's not an immediate switch, it takes learning and time, but deep inside, the are the same indeed.
No, they are not the same, because they lead you (some more, some less) to different thinking when solving problems. Clojure and java don't have much in common, I think differently when I solve problems in Clojure vs Java. Haskell is also a very different beast. I see languages as frameworks for thinking and developers should embrace that and not fight it. Sure you can code in OO style using Clojure, but language was not designed for that.
Maybe Java/PHP isn't the best example, since they are not so different.
I think it is quite possible for an experienced dev to switch from to Java to PHP and vice-versa within a few weeks.
Especially if you make use of code-reviews or pair-programming.
Let's say you are looking for experience with Machine Learning, Distributed Systems, Databases, Kernel, Graphics, Embedded, etc.
IMHO those things are harder to learn than a new programming language or framework (at least after having some experience).
That said, I think this article was more about requirements such as: "at least 3 years experience with X".
Where X is just another language/framework/tool.
It artificially limits the number of applicants and you might miss some pretty good devs, just because they don't try to apply since either they've only worked with X for one year yet or they've only used tool Y instead of X.
It depends on how you work. If your developers are pretty siloed, then sure, you can only ever hire people who know what your whole team already knows.
But the more collaborative your environment is, the more the trivia doesn't matter. I often work on pair-programming teams, and in that context I mainly care about deep skills.
Interviewer: Are you a good team player? You need to lead junior carpenters, communicate with our going-to-leave carpenters for the handover, and make sure everything in harmony.
Carpenter: Yes, I have experience to be a naughty apprentice and cursing the old carpenters who forgot the anti termite treatment.
Obvisly at my first job our wood shop where true carpentry ninjas capable of turning out anything in wood you like - they once built a fabulous desk for our ceo for a leaving present it made the fabulously expensive antiques you seem in museums seem like journeyman pieces.
I'm sorry: In my career, I've been through a lot in the OP and more, all really wasteful nonsense. As a result, I've concluded:
In the US, for significant, long term financial security, it is close to essential to start, own, and run a business and make it successful.
As a young person in a hot field, being an employee can look good, but usually too soon, well before retirement, being an employee is awful.
For computing: If computing is valuable, and of course it can be very valuable, then somehow a person in computing needs not to be an employee but to own their own business and make it successful.
Broadly a key to being successful in business is to sell directly or nearly so to the end user. So, in computing, for the business, develop a product or service that sells to, gets revenue (or eyeballs for ad revenue, here and below) from, the end user. For this, pick a problem the end users want solved and that you can solve with computing, have a barrier to entry, ..., and get the revenue. Try to have the product, service so that the number of end users times the net revenue from each makes a good business, e.g., gets you some good financial security.
There is a huge, but easily overlooked, difference: (A) As an employee, you are getting all your money from your employer, only from your employer, and they know exactly how much money you are getting. If the employer concludes that they are paying you more than necessary, then they will work to pay you less. It's super tough to get good financial security as an employee from an employer. (B) As a business owner, you are getting money from usually at least a few and often many users, and usually the users have no idea what your profit margins and net revenue are, and, even if your revenue is high and they know it, there's next to nothing they can do about it. So, if you can find a way to get a lot of net revenue, then you have a good chance of some good financial security; the users have little or no way to keep you from the revenue.
In simple terms, if your work is valuable, then you should get a lot of money for it. Being an employee is a poor way to get that money; instead, your employer gets the big bucks. So, own your own business and keep that money, the big bucks, plus what would have been your employee's salary, for yourself.
In the terms of the OP, there are some huge advantages in owning your own business. To illustrate this point, I will draw from the best example I have, my startup:
I saw the problem, did some applied math technical work for a solution, designed a Web site as the means of delivering the solution, designed the rest of the software, learned a little HTML and CSS (but no JavaScript -- didn't need it) and Microsoft's .NET Framework (for writing applications software), ASP.NET (for Web pages), ADO.NET (for programming use of relational database, e.g., Microsoft's SQL Server), typed in 24,000 programming language statements in 100,000 lines of typing, and am going live on the Internet ASAP.
Well, all I had to learn was just what I needed, and for more I didn't learn it. So, e.g., compared with C#, I prefer Visual Basic .NET as easier to learn, teach, read, write, and debug and otherwise, as access to .NET, etc., essentially equivalent to C#. E.g., C# has much of the deliberately idiosyncratic syntax of C, a language designed to be really sparse and low level and to compile and run on a 5 KB DEC mini computer; and C++ was originally just a pre-processor to C (in those days, language pre-processors, e.g., RATFOR, were popular). So, for me, to heck with the C# syntax, and I have not studied C# and have yet to write a single line of it.
Yes, apparently Python is quite useful and very popular. As I understand it, it is interpretative which means it can be easier to use but slow. As I understand it, Microsoft's Iron Python is compiled and provides good access to .NET. As I understand it, Python has some really nice software "packages". Maybe in time I will need or be able to make good use of Python; then I will learn and use it. But so far I've had no use for Python and have not used, learned, or even installed it.
Python is just an example: I just learn and get needed experience with the software tools I need for my startup, and that's much, much less than would would be needed for the scenarios, in my experience accurate as a parody, in the OP.
Now what I concentrate on learning is not software tools (so far I have what I need and from early in my career much more) but what I need for my business, e.g., now, getting good initial data, publicity, and products (processors, motherboards, main memory, mass storage, etc.), and server construction, monitoring, maintenance, and administration.
E.g., for my servers, can I use AMD Ryzen processors with ECC (error correcting coding) main memory and Windows Server 2016 (that wants ECC main memory)?
So, I'm 100% owner of my startup. Thus, if there is good value in my software, then I will get that all that value instead of some only some small fraction of that value with some employer getting the rest.
So, to respond to the situation in the OP, I suggest that people who can write valuable software should start their own business, own 100% of it, pick a good problem, write valuable software for a valuable solution, and collect the big bucks themselves.
E.g., the OP has the employer asking really dumb questions. Why should a good software developer put up with such nonsense? They shouldn't and, instead, should have their own business. Such nonsense is not a good path for either the employer or the employee to make much money.
"How long will it take to make this table?"
"3 weeks. But we're going to try using this new kind of leg because it's easier to replace with another leg if you don't like it. So it may take 5 weeks."
5 weeks pass
"Is the table done?"
"Well, no, not really. But now you can have four different legs if you want to. We've also got this table building machine that can make all the different types of legs that will slot in"
"Can we use the table-building machine to build the table?"
"No, it only does legs right now"
10 weeks later
"All right guys, it's been twice as long. Is it done?"
"Yeah, we're finished. You're going to love this. We upgraded the table building machine so now it builds as many tables as you like. All you have to do is sketch out a full blueprint. We've got one blueprint for the table you want, but you can make more if you like"
"Where's my actual table?"
"Oh, it's that pile in the corner. It's broken, though. Jack placed a red cup on it and it fell apart. You're not supposed to do that. We told him to use blue cups. It's in the manual. We explicitly fixed blue cups last week."