Yes. The skills are fungible.

When companies were looking for “a C# developer who knew the latest front end framework who was willing to commute to the office in midtown Atlanta” the pool was a lot smaller than “someone legally allowed to work in the US”

In the real world, I’m interviewing for positions where they are looking for leads at cloud consulting companies who can mentor juniors and that they can put in front of customers for recommendations, estimating statements of work for implementations on AWS and it’s specializing in application development where you are integrating with AWS services. I have lots of experience with most things AWS.

No one should hire me to do the same for either Azure or GCP. Sure I could do the initial discovery, pre-sales, needs analysis, business outcomes, etc. But I wouldn’t have a clue about what services to use and i definitely couldn’t mentor and help troubleshoot implementations on Azure or GCP.

Other than awful, unsuitable for production languages like ruby.

On the other hand, would you know the limitations of Dapper until your system grew and you found out that you really needed EF but because you didn’t know the tradeoffs you didn’t know what to look out for?

They will send your next of kin “thoughts and prayers” and you will soon only be remembered when someone sees your name while doing a “git blame”

A less morbid example, what I call the “are you replaceable test”. Can you can hit on your boss’s spouse repeatedly at the Christmas party and have a job the next year?

GitHub, Discourse, and Basecamp would like to have a few words with you.

I kid.

Sure, you wouldn't be as fast as someone who has worked with these tools a million times, and sure, that would matter if you're being hired on a three-month contract to build something and part ways. But if you're being hired to be a valuable contributor and leader at a company, this learning period is going to come out in the wash.

Let me give you an example: At my current company, by my estimation our MVP employee on the engineering side spent most of his career making video games, largely within the Microsoft stack. We do python, go, and React. If we hadn't hired this person because he had never used any of those technologies, that would have been, by a very long shot, the stupidest decision we ever made. This stuff just. doesn't. matter.

And at this point in my career I’m looking for lead positions. Would you hire me to lead your front end efforts?

(my area of expertise is enterprise app architecture/dev + AWS. As a developer I spent most of the modern era of my career working with Node, C# and Python).

You are right though that I wouldn't hire you to lead a dedicated front-end team. But I'd prefer not to have such a team to begin with. But I'd be happy to hire you[0] to lead a product team working on a product that requires a front-end to succeed. Either other members of your team will know how to make that part work well, and I would expect you to learn quickly from them, or I would expect you to figure it out and then teach the rest of the team.

[0]: I'm using "you" as a stand-in for someone with your experience, who is otherwise a good fit for the organization. I may well not hire you in particular and suspect you would not take a job from me in particular, since we clearly have very different philosophies on specialization vs. generalization and investment in employee training, such that we may not enjoy working together :)

The software dev job market is cooling down. Making good choices on what to build experience in is more important than it has been in recent years.

I think many companies, including mine, are thinking they have only a few spots to fill and a lot of candidates to consider. I know we consistently say things like “who will be productive quickly?”

The model I've seen at startups is an approximately two-year cycle of 1. raise money against a couple year plan of milestones, 2. hire quickly on the back of that raise, 3. use that personnel growth to hit those milestones, 4. go back to 1.

Importantly, the large bulk of the hiring happens around those post-raise points, when there is a couple years of runway. And the idea of startups is to be ambitious and forward-looking, not myopically churning on short term features.

I would submit that it's even more important for startups to be focused on investing in the right team during those scale-up periods, because many of those people are going to be the leaders during the next round. You want people who are going to be strong stewards of your business as it grows, not just people who see themselves as "react devs" or whatever.

I'd love to have someone apply to a .NET desktop app position with 5 years of solid experience building Java web services. I'd love to fill a Node.js web service position with at least someone who spent 10 years writing embedded C for home automation devices. Hell, I'll take a brand new CS grad who built a janky Unity3D app in their spare time, not because it was a school project, but because they just wanted to.

What I get is IT network technicians who took a programming certification, substitute teachers who 15 years ago did software QA testing, public policy majors who dabbled with Matlab or Python in grad school, boot camp grads who haven't touched programming again since they finished their 8 week course 10 months ago. People who have never had any experience with the care and feeding of any kind of software project that other people had to work with them on for any significant time.

I'll get 1 resume out of the batch (and they always come in groups of 10) that is just a software developer: for whatever N years of experience, at least the most recent .8N has been software. Then it comes down to figuring out if they were actually a contributing member or spent most of their time hiding in a large team.

We're all out here shedding a tear for you. Not too sure what you expect, as they say, the real talent doesn't need to apply to job postings and submit resumes blindly. With that said, is there anything in your .NET desktop job posting that would encourage a Java web service developer to apply? The first day of every month a bunch of people with widely varying backgrounds and experience post on this very site that they are seeking work... ever reach out to any of them?

I’ve been warming up my network like crazy over the past four months, preparing my resume and career document, etc. I keep my network semi-warm regardless.

When the day came and I had the offer to quit and get big check or stay, I chose the quit option, before my last day, I had one manager trying to create a position for me, a second round scheduled with another former company and a third and final round scheduled at a third company.

All based on networking.

It’s foolish in this market to hope something is going to happen quickly by randomly uploading your resume to an ATS and keyword stuffing your resume like an SEO technique from the 90s trying to juice your position on Altavista.

On the hiring side, a hiring manager also needs a network that they can call on when trying to find candidates.

I think there's a huge valley of difference between "no relevant job experience" and "real talent". I do a mix of job postings to stuff that looks interesting while also talking to my network.

I mean obviously it depends on a bunch of other stuff in the resumes and during the interview process. But no, it's not a huge advantage to know React or have done front end development recently, just because we do some front end development in React. It's like the tenth most important consideration for whether someone would be a valuable contributor.

> Learning a language is easy. Modern development requires knowing the toolchain framework, idiosyncrasies, foot guns, best practices, etc.

That said, I still nearly always hire for general skills and not specific technologies, as long as there is at least one expert in the specific tech under consideration on the team (which there nearly always is). And I budget anywhere from 3-6 months for a person to become truly proficient at a new platform technology.

Because of the stupidity of hiring and raise practices (not your fault as a hiring manager), you can get HR to open a job req at market rates. But it’s a lot harder to get HR to allow you to give your current employees raises to get them at market rate.

That investment is then lost because your employee is going to jump ship.

if someone gives you two years of good work and moves on because you aren't giving them what _they_ need, or because their father got ill, you still came out way ahead. you should be a human and accept that.

If I hired someone with the experience I was looking for, then they gave me 2 years of productive work.

Why would I train someone new instead of just poaching your developer at market rates?

streamlining onboarding and extracting the secret recipes from the seniors is really valuable

there is no better understanding than that gained by teaching

its clearly a higher risk investment, but often times that one super workhorse and brilliant jewel is the one that you helped grow

but yeah, I've had employees that just sat around learning the latest fad and left. it happens. but if it happens a lot then maybe you should look at your hiring and management

if I convince someone to come work for me, its not poaching. its life.

You as a hiring manager only have power of hiring and management. Your HR department at the behest of their management controls how much of a raise you can give your employees.

You can give them the meaningless platitudes of “we are family” for only so long.

Because you pay more, and still have the risk of less/negative productivity anyway? Who says experienced dev won't do 2 years of resume driven development instead? Who says they won't simply zone out and spend their last 6 months being poached the same way you poached them from the last company?

your argument works under the assumption that your experienced hire has no downsides, and there's no risk of upside for the less experienced hire.

and when I read it that way I agree. Some of the best devs I have hired had no prior experience in the stack.

I'm not hiring for Python or C#, I am hiring a software engineer and the skills I value are all transferable.

The language or stack is irrelevant.

A good lead knows the right questions to ask, understands they don't have all the answers and plays to their own and the teams strength.

Honestly the last thing I care about, especially here, is if they know the stack.

What good is a lead if they can’t answer technical questions and can’t help other developers with technical guidance?

What will it do for team morale on your iOS team when they know you bought in a “lead” who couldn’t actually help them with the tough technical problems?

I'm not saying this is right in all circumstances. I wouldn't do this with, for example, realtime embedded.

For what I operate in, fairly bland web applications and stacks.

It works fine, exceptions excepted.

I think that for architecting systems that's probably true, but as technology becomes more specialized and ecosystems become more complex it's harder for individuals to pick up and run with.

Consider if someone has written lots of PHP and jQuery

Now tell them to write a NodeJS server, React Frontend using NextJS.

It's not just "Oh I need to pick up ExpressJS" anymore. It's a whole beast.

Yeah the fundamentals stay the same. REST is still REST, SQL is still SQL, but actually writing lines of code is still a key activity of the job which people familiar with the technology will be better at.

Personally I run into this any time I try and write C#. There's a massive undercurrent of stuff that I feel I don't understand about C# and I bounce off that ecosystem every time I try

And you’re going to hit a brick wall at 100 mph thinking SQL is still SQL once you try to treat a columnar database like Redshift or Snowflake like you would a traditional database.

That would be an expensive lesson to learn on the job. That’s just one example of trying to pattern match based on what you know when you hit a new to you technology.

It’s like the old school operations people who study one course of ACloudGuru, get a certificate, call themselves “consultants” and duplicate an on prem infrastructure and internal process and their poor clients wonder why they are spending twice as much and not moving faster.

I will say that even moving from Postgres to MySql has a speed bump or two, so I completely agree.

Tech knowledge just isn't as interchangeable as hiring managers sometimes seem to think.

The lead may know less than them about some things. That's OK for us. But what's important is they know more than the team about other things.

For example, we would rather have a lead that knows when to say "How do you know this is performant? Show me." and understands statistics and how to read perf dumps ... than how to profile whatever PHP script or whatever hands-on.

Sorry that contradicts the black-and-white world view you're holding.

I also strongly believe good technical leadership is about accepting you know _less_ than a team, and being able to ask the right technical questions to the right people who know more than you to ensure the best outcome.

You can do that with a ground knowledge of the stack, picked up on the job, along with learning the application's code and architecture. What a good technical lead brings is a deep understanding of how to manage complex people and systems by having done so across different languages/stacks/architectures many times.

Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.

The reason you would is because while I don’t know Android. I do have years of experience designing systems for field service workers where they go out on the field with mobile devices in places where they may or may not have connectivity. But they still need their applications to work and they work in a “semi connected state” [1] and be able to sync and handle conflicts.

Then you need to know whether the feature you’re going to spend man hours on will break App Store rules. Someone needs to know how long the process usually takes, etc. knowing how to write a complex mobile app is not “easy”.

[1] My four experiences with dealing with mobile implementations

1. Windows CE ruggedized devices back when trucks had satellite dishes on them to get a signal and some customers didn’t want the extra expense of early cellular data plans. These were trucks that delivered propane and other field service work to rural areas or they were in basements

2. Railroad car repairmen in a rail yard

3. Doctors in hospitals that often didn’t have great reception. I wrote the backend syncing protocol for the iOS and Android apps. But I knew the design constraints.

4. Home nurses for special needs kids and often the signal wasn’t strong at home or at the school when nurses would go to the school with the students. This was built on top of a third party forms engine. But you could customize it anyway you wanted using web technologies and it had an API where you could save local data and sync it.

I can tell a paper tiger from someone who just went through ACloudGuru and memory enough to pass an exam.

It is, maybe you aren't a good developer (yet). The more you do it, the easier it gets. It took me a good time to change from PHP to Python, but from there to Java, JavaScript, C#, Clojure and some 10 more, it only got easier. Toolchain frameworks, idiosyncrasies, foot guns, best practices also follow patterns and gets easier to learn.

All this stuff is the same as learning the details of the language. Once you know the pattern it’s not hard to use it in a context with incidental differences in details. It’s usually more than days, but can easily be weeks or months — it depends on how well you really know the patterns. If you really know them it is just days.

But being hired is a completely different thing. Hiring managers (1) don’t understand any of this, generally; and (2) in any case, have no way to directly determine whether a candidate really knows all the relevant patterns. They use past direct experience with the technology as an approximation (a pretty poor one, but it’s easy).

Personally, I’ve done many jobs successfully on stacks I didn’t have previous experience with, almost always as lead or sole. But of course, I got these jobs through people who know me, not a random hiring manager.

(BTW, the skills most important for a lead/architect type have nothing to do with specific technologies. You’re making sure the project/team/product/business doesn’t run into dead ends and progresses efficiently, daily, in the short term, the medium term, and the long term, and balancing their conflicting needs. Probably less than half of this is tech at all.)

In my time, I have been an embedded C developer, a kernel developer, MFC C++, then J2EE, then Mobile C# .NET, then Python we dev, Python DS, Python Scientific, DevOps, WebDev

These aren’t trivial projects, but entire systems, E.g. I solo built https://atomictessellator.com just to scratch my own itch learning quantum chemistry simulators.

I think you are 100% right, at about the 10-15 year mark learning new languages and tooling really is a matter of days, maybe a week if the tooling is very different. That’s 1 week from no experience in a language to “employable, productive member of a team”

At some point it all just clicks, I suspect the people above who are disagreeing and likely devs with maybe only 5-6 years experience who this hasn’t happened for yet.

BTW, I’m using the definition of senior developer as defined by large tech companies - the whole “scope”, “impact”, “dealing with ambiguity”, “leading initiatives” metrics not “I code really well”.

My experience on the enterprise dev side (1996-2020 and going back on that side now), is that titles mean very little outside of tech companies with leveling guidelines.

BTW, the last time I had only six years of professional experience was 2002.

The last time I only had six years of programming experience was 1992. By then I had done assembly language programming as hobby on four architectures (65C02, 68K, PPC and x86)

1. Working with external/internal stakeholders to define business outcomes and deal with ambiguity and doing project management - from my experience at AWS (ProServe) you can be really good at this with hardly any technical proficiency

2. Determining what is the right service or combination of services to use and the overall architectural design. I could do this without any specific platform knowledge - I know what type of database I need. I know I need a messaging bus. I know the trade offs of different types of technologies.

I was able to go from never opening the AWS console to working at AWS in the cloud consulting department within 2 years. But I sucked during those two years while I was learning the ropes.

3. Using the “right” one of the literally 100+ services and being able to mentor junior consultants and help them troubleshoot complex issues.

The 3rd bullet point is where you need someone who has the specific skillset.

My experience at the second bullet point is the downside of hiring someone based on “potential”. The CTO who hired me threw me at the cloud initiatives without experience and let me figure it out. But paid me $30K less than he would have had to pay someone with experience. He would have never been able to push through the 20%+ raise I would have been looking for when I left 2 years later if I had stayed on that side of enterprise dev/BigTech compensation side.

He definitely couldn’t push through the 50% raise I ended up getting at BigTech.

Now that I did my bid and the pay/bullshit ratio is going too much in the wrong direction, I can go back to my former company (since been acquired) and ask for about the same I would have been asking for three years ago (a lot less than I was making at BigTech)

I've long said, and would stand by: Programming/Development is logic; learn logic. Languages are just syntax; if you understand logic, you _can_ learn the syntax.

Taking concepts from one language to another shouldn't be an onerous task.

Of course, none of that means you'll get that _senior_ language -focused position, or any particular position at all.

But let's not act like picking up a new language, for a developer, is the equivalent of switching from development to medical practices, or even networking/system administration/etc.

Guess how long the learning curve was at my next job where I had the learn the intricacies of Win32/MFC, COM and DCOM, when to use which of the 8 different methods that Microsoft had of defining a string and how to safely convert between them, why my C++/ATL COM object kept crashing the other developers VB apps because I wasn’t doing reference counters correctly…

No, but you probably can in 6 months. Whereas if you hadn't even touched any language and UI framework before, it would have taken you a few years.

Does it have to happen "in a few days" to matter? Or the hyperbole is to argue that past experience with different languages and their concepts, and SDKs and their architecture doesn't help going forward, because each of them is some kind of unique snowflake?

If you havent' done that with any technology for a full 15 years in some domain, and so can't adapt to the current framework used quickly, it's not like this refutes the parent's comment.

The parent described a situation where you serially learn new technologies and move on, which means there's a lot of concepts that transfer fine, and things that gradually change that you can more easily pick up in much smaller time. If you had done Android development in 2018, it wouldn't be that different to 2023.

I'll wager that you can't. Android development is Kotlin nowadays with Jetpack Compose.

Efficient, hardly. Not "in a few days"

You can become whatever you want to become. Hiring is a totally different thing altogether.

Did A for B years is how you get hired. Not what you can do.