Not to suggest this all can't be learned.

Is GPU work unique or is it generic programming such that I should be ok to hire a programmer with zero GPU experience for a GPU role?

Similarly, sometimes you're hoping for someone that can be productive immediately, not after 2-6 months of getting used to something new. For example, I trust that a Java programmer could write C# or Swift or Python, but I'd expect the Java programmer to know the Java standard library and common solutions fairly well but not know the C#, Swift, or Python standard library. I get it might short sited not to hire them for long term growth but right this second I might want someone who can hit the ground running?

I would not have taken a C++ role. But that's because I don't like C++. Could I learn C++? Presumably, I assume it'd take quite a bit longer than C# but I don't want to.

A lot of programming skill that's transferable from one role to another is also transferable from one general purpose language to another. Almost everything about programming generally is transferable. All the practical implications of architecture is transferable. All the theory is transferable. Data structures are transferable (albeit if you've got very narrow experience you may not be aware of just what's possible). A lot of high level APIs are transferable.

On the other hand corporate knowledge isn't. So, the fresh graduate hire who is an expert in your preferred language does not know that around here nobody above an Engineer Lead reads their Teams chat, and nobody above Group Manager reads email. They don't know that tweaking the CSS requires a Design Team Lead authorisation because once somebody made the text the wrong colour and branding were furious - and they equally don't know that "Normal Minor" changes take six months to approve around here so they should mark small changes "Urgent Minor" instead and then pester a Senior Engineer to OK them, but never pester a Senior Engineer if it needs a Config change because that is an ops problem and... you are going to need to hire internally if you actually need them to "hit the ground running".

Yes, there are differences, but they are not fundamental. And with google, it really takes little time to learn things on the go. And with a team sharing necessary experience it will take no time at all.

EDIT: "I might want someone who can hit the ground running" - this is luxury, so one wanting it gotta pay up... And such short projects where such quick ramp up is important perhaps will be a better suited for contracting out the work anyway.

(And if you are such a startup, you want mostly senior generalists anyway.)

[0] Well, this is also probably begging the question. For me that's part of the definition of senior. Based on resumes I see lately it's far from everyone's.

Sent them on a course and within a couple of weeks they were committing stuff with minimal review needed in terms of language things.

It's now been a year and they're still learning about our code base. For me it took about two-three years before I felt comfortable on my own in the most-used areas.

The lat thing I need about any of my colleagues is to learning all gotchas, at the same time as integrating into our team.

Some tech I'll argue against, other tech I will require.

Some tech is fundamental to a domain. Some tech is a nice to have. Some tech is just generic.

My current team will not hire anyone for a senior role, without Spark experience. No matter how good you are in C++...

An example close to my heart. The company I'm currently at had a totally ossified Spark monolith and data eng team because they only wanted Spark developers. Drop one C++ developer in there to start spreading the good news about data-oriented design and suddenly there are a dozen previously-intractable "big data" problems we can rip out of the ball of mud and run outside of the cluster. Drop in another SRE who doesn't know shit about Java but can actually write shell scripts, and hey alerts from bad orchestration from weekly to twice yearly.

Yeah if you have a Spark job, you probably need a Spark dev. But if you have a team of Spark devs, suddenly everything that involves more than 1MB of input data looks like a Spark problem and you're in for a real bad time in a couple years.

C++ programmers know map/reduce/filter too.

Thanks for generalizing Spark engineers to an insulting level, though.

I have no clue how you got that from what I wrote. I even said a Spark project needs a Spark dev!

It really sounds to me like you're the one generalizing from "the one C++ dev we hired couldn't do data engineering right at all" to "senior programmers are dangerous to us unless they are Spark developers" (which imo, is more indicative of serious deficiencies in your architecture / design process), to "all senior programmers crossing subdomains are dangerous."

Sure LLVM or C pro will cringe looking at my code. But the business problem is solved, by someone who is not LLVM/C pro, and there is no need for more of that LLVM/C skills for now at the organization...

I've often seen organizations spend 6 months or more to find the perfect Foo developer when they could have hired someone right away who had Foo-adjacent skills and was very willing to learn Foo.

Would you rather hire a developer with 20 years experience but only 3 in the language you want, or would you rather hire the guy who has 6 years experience in the language you want and that’s it?

Personally, I’d hire the former every single time, even though he didn’t have the requisite 5 years in the language.

Pretty much better to reduce the years on the resume.

Sometimes, the right tool for the job is just a hammer :-)

I think more pragmatic question in such situations however, is why the potential employer is requiring $A years of experience in $TECHNOLOGY. For example, why they need someone to be productive from the say day $N and what does it actually mean (for them) to be productive?..

IMHO getting to shared understanding of what drives such requirements can help find a better path forward for both sides.

Is that the right analogy, or is it more like requiring CUDA experience vs knowing OpenCL (or Vulcan/Metal/etc.)?

I haven’t done C or asm since college but haven’t forgotten the concepts. Probably know more now than then.

I my experience, when working in a programming job, your programming skills rather degrade quite fast if you are not actively working in your free time to work hard against this degradation.

I rather get better in programming almost exclusively by the side projects that I do in my free time.

So, I would rather say that x years of job experience show nothing; what is important is what you do in your free time (if such side projects are possible).

Engineer? Yes.

Someone with a solid track record and a good foundation and background should be able to pivot relatively quickly.

There also are loose tiles in Algiers that are similar to traps in the first Prince of Persia. You step on them, and they rotate to let your foot into the water.

Master Foo would do well in Algiers. This is not an instance where the master points to the moon and me looking at the tiles.

*disambiguation added

[0] https://en.m.wikipedia.org/wiki/List_of_popular_place_names

Odessa is not and was never the capital of Ukraine.

And of course if you walk without rhythm, it won't attract the worm.

The fact that I love to walk in Bangkok proves that I am into Walking in a way more regular, more fit, longer-distance, better equipped walkers generally are not.

Dunno what the programming equivalent would be… maybe if you’re into coding Windows apps in Brainfuck?

I'll hook you up with painters here as well.

Other people excel at going deep on specificity. They know every detail and arcane quirk about THIS specific language/build system/toolchain.

Both of these traits are desirable, but they will be great at slightly different things and under slightly different circumstances.

Why would one wait to make mistakes on their own time?

But it is a trait I notice in a lot of highly competent folk who are high achievers. They'll see something coming on the roadmap that they feel like they want to prep/educate themselves on, and then they will noodle on it for an hour or two when they get a chance. By the time it comes time to implement it 'for real', they have already gotten most of the learning curve out of the way.

But, if you want access to a larger pool, then the next best is people who:

1) know how to walk and have been walking for years, and

2) have walked on many floors so that you can have confidence that they can walk this particular floor.

There's a reason why you get geographically specialized pilots - little bits matter a lot

Better know those floors goddam well