[nmjohn]

If you're needing to read 10 different books you are doing a very poor job of picking companies to apply to.

If you're a python developer, it wouldn't make sense for you to apply for a ruby job, a nodejs job, a C++ job, and a java job - thus requiring 4 books.

Instead, you should apply to 4 companies looking for python developers, then you need one book at most, unless you've already master the language in which case you don't need any books.

===

Coming from the companies perspective, if I have 10 applicants for a job, the first round of people to get cut will be those who don't have experience with our tech stack. If I have other applicants who already are familiar with it, it wouldn't make sense to hire someone who would need to learn a new language first.

> Why can't you, the employer, be arsed to make that small investment in your new employee?

If there is only one person applying for the job that would be the case. But that never happens. So it's your choice to have that opinion, but understand that not being familiar with the languages the company you are applying to uses will get you ranked last among all the applicants - the most qualified candidates will be interviewed first, and only if no one else panned out would it make sense to hire the candidate needing to learn a new programming language before they can actually start.

[MichaelCrawford]

I'm a consultant, I take the work that the clients offer.

Most commonly I'm asked to write the Macintosh equivalent of some existing Windows program. While I know lots of stuff about Mac and Windows, it's quite common that I don't have a clue about anything else that that program requires, other than the core OS and standard library calls.

The way it commonly works is that I'll apply for a consulting gig. If I'm asked to interview, I'll buy the required book after I have agreed to interview, but before the interview takes place. That means I only have a few days to read the book.

You'd think that would not work but actually it works just fine.

What does not work at all is when someone wants to know how many years of experience I already have with a given technology. "None at all, but I can buy an O'Reilly book for just thirty bucks."

[greenyoda]

"Coming from the companies perspective, if I have 10 applicants for a job, the first round of people to get cut will be those who don't have experience with our tech stack. If I have other applicants who already are familiar with it, it wouldn't make sense to hire someone who would need to learn a new language first."

This approach to hiring sacrifices long-term productivity gains for short-term productivity gains. A really smart and experienced developer who doesn't know your tech stack may be less productive for the first few weeks, but after that time they could become far more productive than your "Python developers" by leveraging their superior thinking skills, debugging skills, CS skills, communication skills, etc. But if you never give them a chance, you'll never know what you're missing.

[nmjohn]

> A really smart and experienced developer who doesn't know your tech stack

I really question whether that exists or not. The kind of developer you are referring to by and large knows how good they are and has no problem finding a job with a tech stack they are already familiar with. Additionally, this kind of person wouldn't move to a new language without trying it out first and likely comparing its features to a handful of other languages before making a calculated decision to switch. And by this point in time they probably have enough experience with the language to be able to make it through an interview because most interview questions tend to be more algorithmic in nature than language specific.

I completely agree that the kind of person you speak of in the long term could be a much better hire, but in the real world I don't think it's applicable. Let's say this kind of person is 1/100 applications where the applicant doesn't have experience on the desired tech stack. For most companies it is not even remotely feasible to interview 100 people with little to no chance of getting the job to find the diamond in the rough.

[MichaelCrawford]

"a tech stack they are already familiar with".

Like 16-bit assembly code?

PC-NFS?

How to diagnose a serial cable problem with a breakout box and an oscilloscope?

How to calibrate a CCD image sensor?

So how are today's iOS coders going to feed their hungry children when no one remembers what an iPhone even was anymore?

I quite commonly point out that I can debug anything. I'm also quite good at performance optimization as well as reverse engineering.

The API, programming language, platform or what have you - the tech stack - are all orthogonal to my being one of the very best in the business at debugging.

It's not like no one needs their code debugged, but they don't seem to recognize that until it's way too late.

What they ask for is "How many years of Python experience do you have?" If I say "Less than one" - which is what I actually have - I don't get an offer. Were I able to claim that I had five years experience, I'd have a job.

What I'd like to see, is an interview where someone handed me a buggy Python program, then asked me to fix it.

While that does happen, it is quite rare.

[MichaelCrawford]

Actually, I am that specific smart and experienced developer. I find that no one believes I have a clue anymore.

For example I was once asked whether I knew how to write Mac OS X Apps. I pointed out that I had been writing Macintosh code since 1986.

I did not get the job because the hiring manager did not believe me, when I claimed I knew how to write Mac OS X programs.

From time to time, while I don't come right out and say so explicitly, I make it plainly apparent that I regard the hiring manager as a damnfool idiot.

That's not to imply that one must understand computer programming to employ computer programmers. I've had lots of really good managers - consulting clients too - who really didn't have the first clue about computers.

However, there is quite a lot more to management, than understanding what your employees actually do.