How do you switch languages during a job search? Are you avoiding companies with language requirements (four years Ruby)? Do you run into language/framework tests and/or homework assignments in languages you are unfamiliar with?
I've interviewed at probably 15+ companies over the last decade, and none of them had language requirements or tests. Honestly I see those things as red flags. If you can find somebody with good problem solving skills and proficiency in any language, they'll be able to pick up your language no problem.
"they'll be able to pick up your language no problem."
That still takes time. If someone is already experienced in an (complex) ecosystem, he or she will be way more effective in it, than someone who has just general skills. I guess I am a very good problem solver. But if I suddenly would have to do a C++ project with all its footguns, I am not aware of (last time I coded in C++ was in university)? I would suck in it for quite a while. This would not be effective at all, unless I would want to change my skillset to the C++ ecosystem.
I'm guessing that's not typical for most devs and most job openings. Recruiters in particular seem to assume they need to find devs experienced with particular stacks, and for companies who need to quickly re-fill roles after losing staff, a good dev with experience in the stack/ecosystem you've been working with is always going to get up to speed faster than one without that experience. I'd also say convincing hiring managers that specific libraries/ platforms/languages/tools that you've been using shouldn't be listed as "must have"'s in a JD is hard.
I'm not sure. I'd guess very few companies that hire more than 20 devs a year would have any language requirements. But I don't know what % of jobs are at companies of that size.
In my own city I'm not sure there are any such companies. But I was involved in helping out with a hiring round for Thales recently that were looking for 15 devs. They had very strong language requirements.
I prefer companies which are open about the technologies and languages I'm experienced with. That's a huge green flag, that they consider their software engineers as smart people solving hard problems while continuously learning new skills. It also means they listen to their senior technical staff, which consider that learning new bits of stacks is hardly the most complicated thing they expect you to do.
As opposed to companies which consider them as glorified factory workers, who are insufferably hard to manage and monitor.
I'm currently working with RoR, which I'd never used before, and what matters is that I know algorithms, SQL beyond ORM, how to write code which won't be a nightmare to maintain in a couple of years, etc. All those skills are the same in Rails, in Django, in C++.
Does anyone still have language requirements? I did my Google interviews in Perl and wrote mostly Java and Go there. At my current job, our codebase is all Go (expect frontend) and pretty much nobody we hire has prior Go experience.
Prior experience is almost a curse these days. I learned Go by having the Go team review every one of my CLs for a year. Now I do Go code reviews and think "that simply isn't done, I would never have been allowed to check that in", but often have a hard time supporting my arguments. (When Effective Go, Code Review Comments, and Test Comments fail me, I usually resort to snippets from the standard library. "This pattern appears 0 times in the standard library, I don't think we should use it." It's a lot of work, but I will say that a few things I thought were simply never done are actually done. And that's my standard; I hate it, but Go itself did it to implement Go, so you can too.)
Side rant: I guess the Go team stopped doing this. Read Kubernetes for the current state of Go at Google. Wow.
It's easy to trick recruiters about tech stack ("We require someone with 5 years of experience in Django". Me: "Sure, I'm qualified"... While in reality I have over 6 years of experience in RoR and I have probably used Django in one side project). The moment you pass the screening part, then it comes the part when you judge your future/potential team: do they care about good engineers or good django engineers? Usually, it's the former.
