Yes, there are a few tools that are as interchangeable as various types of wood, and there are some weird dogmas out there analogous to using rocks as hammers. But these are exceptions, not the rule.
Languages aren't interchangeable. Sure, any half decent programmer can pick up any sane language and be hacking something together in a day or two. However, most languages have idioms and subtle usage patterns that take far more time to learn than you'd estimate. You've mastered first principles? Awesome. Ever heard of an "unknown unknown?" This kind of thinking will have you tripping over them constantly. The best part is it will always look like you're tripping over your own shadow.
And guess what? Tools do have meaningful impact on the way you perform your work, and even how you think about problems. Sometimes these tools are old and at first they look a bit like swinging a rock, but the people around you with more experience are probably using them for a reason. Go find out what it is.
Actually, that brings about a larger point. If you find yourself agreeing strongly with the OP, maybe you need to force yourself to work through a different set of languages/frameworks/platforms/tools/philosophies for a month or so and test the idea that it's "toe-may-toe/toe-mah-toe."
"I don't understand why X is different to work with than Y, but I know that X and Y can be used to accomplish the same goals so they must be interchangeable."
Now imagine that being said by someone who is somehow responsible for setting your deadlines and for whether or not you get paid. I've dealt with that too many times to find it funny anymore.
If we're talking about building websites, there's a dozen of languages that you can pick from and they are all fine for making a website of almost any complexity.
Yes, you personally will (likely) prefer one language over every other. That doesn't mean anything.
Q: So, your resume says you've been a systems administrator for 10 years. Have you worked much with Linux?
A: Sure, almost all my experience has been with Linux.
Q: How much experience do you have with Red Hat. That is what we use here.
A: Hmmm. Red Hat. Most of the servers I've worked on are Debian based. But I worked a lot with Fedora in college.
Q: But not Red Hat?
A: Well I have some Red Hat experience. I had a temp job where I was setting up Red Hat servers back in 2008.
Q: How long was that.
A: About six months.
Q: Well, perfect! We have an internship available to someone with six months of Red Hat experience! But wait a minute... What version of Red Hat was that?
1. The interviewer asks about my portfolio, previous projects etc
2. The interviewer asks obscure technical questions. I've been asked, more than once, about the structure of .NET assemblies and MSIL.
3. The interviewer asks some abstract "outside the box" question, usually involving bit twiddling (they seem to like that)
They usually like the portfolio, and I usually screw up on the technical & outside the box questions.
I always feel like saying "Look, here's the work I've done, you can see its quality. This is real life work I'm showing you here, not some obscure part of some technology neither I nor you care about. Hire me on that!"
I've never understood why a good portfolio isn't enough to get you hired to most places. Oh well.
The way most companies hire developers today is a complete and utter fucking travesty.
I'm responsible for a lot of technical interviews where I work. I think we've got a good process down. We have a simple "walk me through your resume" phone screen, then we send them two programming problems that take a few hours to complete, and then we bring them in for an on-site. If you pass the first phone screen and if you submit good-faith solutions to the problems, you're pretty much guaranteed an on-site.
The first of the two problems is more of an infrastructure type problem with an extensibility requirement. It involves looking for files in a directory and carrying out some simple pluggable actions on them. The second one involves writing a custom, optimized data structure. The naïve solution is very quick and easy to implement, but our performance threshold for the sample dataset requires a more advanced solution.
Almost everybody gets the infrastructure one w/o any problems. We mostly use it to look at their code style and how they'd structure an extensible program. Almost nobody submits a solution to the second problem that comes in below the maximum time specified in the performance threshold. This is okay, as the goal of the second interview is to discuss these solutions and the problem solving process that went into them in depth.
We hire a bunch of people who've gone on to perform well who didn't submit optimal solutions, and although it's rare, we've declined to hire people who did submit an optimal solution. It's the conversation we have that's important, not the code.
The intro posted there is as follows:
The following joke was posted to an internal Magenic list. I don't know who actually wrote it, and I'll give credit if someone points out the creator of the joke. It perfectly illustrates what I think developers (especially consultants) have to go through all the time when they're interviewing for the next gig.
 From the jasonbock.net post: Posted at 10.13.2004 11:38:07 AM
When I read this post I remembered the previous one so dug it up; turns out the post references the original source, which I had missed the first time 'round.
In any case, I enjoy knowing the history of "famous" internet things, and presume to think others might too.
I don't usually comment on these articles, however especially when it looks like someone has lifted content I try and link back to the original (and original discussion where appropriate). In this case I was pushed to comment because I thought it was not attributed (and hence lifted) but in any case I am always concious of the type of post you outline - the 'OLD' comments.
I think a 'more intellectual' version of that comment is actually a good thing in general, mostly because it adds content rather than simply deriding, but it's always a tough question to decide if posting is the right choice or not. I'm happy enough with this post.
They don't add anything to the discussion. Do you need special techniques to work with walnut? I don't know and I bet the author doesn't either.
And where do you draw the analogy? What's the programming tool that's too specialized to be worth asking about? MSVC++? C++? Manual memory management?
This article doesn't make any useful claim about what level of precision interviewers should be looking for, and certainly doesn't make any convincing argument that it is the correct level.
LOTS of interviewers are going to have zero experience in the field they are hiring for. It will behoove the (carpenter|programmer|car salesman) to learn the language of the interviewer, so he or she can answer the questions the interviewer wants to ask, but doesn't have the vocabulary for.
A. Call the carpenters' union and take whoever they send over.
B. Ask some carpenters you trust if they know any decent carpenters who are looking for work, and when they show up at the job site sober with appropriate tools, you put them to work.
It's a slightly different process than programming.
However every so often we do have to advertise for a position, and then the process of weeding through the applications probably isn't so different from what everyone else has to do.
At this point in my career I can say that it's quite easy to spot a skilled carpenter if I spend a few hours with them. I imagine an experienced programmer could do the same. The problem is getting to that point.
Bingo, this whole topic in a nutshell.
so I should seriously be able to look someone who has done web development for an equal amount of time and say "yeah, I'm a decent programmer, surely I can get to the bottom of your domain in a few months of learning as I go". really? if you had a choice between hiring someone who was an expert in a totally orthogonal domain or someone with experience in the domain you were working in, you would prioritize experience over familiarity? how is that working out for you?
The problem that the post laments is that while there absolutely are separate domains within the programming field, HR people rarely have any idea what those domains actually are. Because of this, they tend to operate under the assumption that every single entity (language, framework, etc) is a different domain, and if you haven't worked with the right entity then you don't have enough experience.
Edit: To expand on this a bit further, your example of systems programming vs. web development is actually a perfect example of what the right question would be for the interviewer to ask. Has the carpenter built a lot of houses, or have they built a lot of tables and chairs? What wood they used to build them doesn't matter much, but what they built with it is very important and is where the real domain gaps actually lie. This distinction crosses over to programming very well.
The appropriate analog for a programming language is a hammer or a screwdriver. The appropriate analog for wood is the processor.
A better analogy would be to contrast the different styles of carpentry: things with moving parts vs things without them, things on a large scale vs intricate things on a small scale, etc.
I suspect a lot of programmers get so attached to the knowledge they've accumulated, that they start to overvalue it. They assume that no outsider could easily pick up what took them years. But that's not really true -- if you've been around long enough, you start to see patterns, and a lot of things just fall into place. It's like learning a new natural language, the first one is hard, but each successive one becomes easier.
I think of myself as a guy who can create or improve text files for computers. I think everyone needs this, but nobody wants this. I'm doing a terrible job of selling myself, and it's actually starting to hurt.
Don't sell what you do, sell what your work does. That is, sell the idea of the benefit of your work. Put it in terms of them, not you.
If you know java, you know python, and you know c, and you can think in algorithmic rather than implementation terms, then you're good for pretty much anything. The hard problems are the same everywhere: cache invalidation and naming things. (I'm only partially kidding.)
EDIT: Besides, if you're hiring for 3-5 years, the advantage language knowledge grants candidates becomes minimal, and the ability to apply old lessons, to learn, to adapt, dominates. If someone has issues learning a language, there are probably more striking problems that would prevent them from getting the job anyway.
Amazingly, even if someone does learn Java, Python, and C, he or she is not necessarily able to generalize that knowledge to other languages, or even to larger-scale projects in those languages. For example, I wouldn't want to take someone with a lot of Python experience and a semester's worth of C, and put them on a large-scale firmware project or Linux-kernel-hacking project. There are a lot of ways somebody who thinks they know C could mess up a project like that.
In general I agree with you: a truly smart engineer can pick things up as they go, especially on a longer time frame. However, this isn't always the case. Though my perception is admittedly warped a bit working in startups, where you need people to hit the ground running immediately.
Second, I only mentioned C because of its use in understanding computers. Memory management is definitely a skill that people should (but often don't) learn in college, at least to understand what's happening when your GC hits some GC-unfriendly code. So I agree that memory management (via C) is a niche skill, so the analogy outlined in the original post doesn't apply... but quite honestly, how many people on this site write C regularly enough that lack of knowledge of C is going to seriously impede them? The vast majority of jobs I see are for PHP, Python, Java, and C#, at which point the largest impediment is the time it takes to get the O'Reilly book.
It also sounds like you agree that that's not so easily done with (quoting myself from above), "some programming languages/tools/methodologies." So sometimes, sometimes not.
So... we agree? :P
have the carpenter build something (of trivial scope) while you watch. somewhat analogous to coding on the whiteboard in the interview.
come to think of it, it might be darn hard to interview carpenters. but if you watch them work for 2 hours you know everything.
I would imagine much of the technical side of HN would be considered overqualified for the lowest quartile (completely arbitrary number) of jobs by interview quality... I've never witnessed this either, but I've seen it in tangential ways. The Daily WTF isn't fiction, unfortunately.