Would I rather have a great dev who doesn't know a framework than a mediocre one who does? Yes.
But there are a couple of reasons why I hire for for expertise in the ecosystem. Granted I'm in .NET which is a very homogenous ecosystem, so framework/library/tool knowledge bifurcates into people who are experts on every tool/library/framework we use and people who've never used one.
1. For the first 6 months you're paying a sr. engineers salary to get jr. engineer productivity. Given that most devs switch after 2 years this is a huge productivity hit and it's all front loaded.
2. While great devs are great, it's a lot easier to figure out if someone is a framework/language expert than if they are an intrinsically great dev in an interview. i.e. ("Do you know C# well?" is easier to determine than "Are you a good problem solver?")
3. Being an expert on an ecosystem pays dividends even after the first couple of years albeit smaller than the first 2.
4. It's not that much harder to hire someone with expertise in your ecosystem than not.
5. Most devs are searching for jobs in the ecosystems they like working in. But a lot of devs who can't find a job get desperate and start applying to everything, which can bring down average quality of people who don't have expertise.
I've been at this software thing for 20+ years and I could see a couple things happening based on your points but I mainly wish to address:
1. Senior engineer productivity
Most companies have zero idea what to do with a senior engineer and they measure them against a junior engineer. The junior engineer usually does the following:
- works a tonne of hours
- closes a tonne of bugs
- makes a tonne of mistakes
- asks a tonne of questions
- uses up a tonne of senior engineer(s) time
And you end up with:
- a high ticket/bug fix rate per day from the junior
- generally horrible and poorly designed code from the junior but the code works
- few big fixes from the senior
- what the senior does produce is generally better designed, fewer bugs and is easier to maintain.
If you have hired a quality senior engineer it shouldn't take too long before your junior and mid level engineers start soaking up the time of your senior engineer. It shouldn't take too long for your senior engineer to become the subject matter expert in several areas of your product which takes up even more time.
I am usually hired because things are a mess and they need to be cleaned up. Years of junior engineers doing the best they can with limited knowledge and experience tossed in with some management pressure leads to unmaintainable code/environments.
The largest impact I have ever had was when my manager put some trust in me, gave me autonomy and a huge project. I think this is what you should do with your senior engineers. Give them the space to make an impact.
+1. On a project with any serious complexity (ie not glorified CRUD apps), a junior engineer is pretty close to net neutral without good guidance.
The industry at large does not realize how much mentorship a beginning software dev needs, or how much damage a poor engineer can cause. I know of a startup where an eng with too much appetite for shiny new tools caused probably $500k in lost runway, and I don't think that was exceptional.
> 1. For the first 6 months you're paying a sr. engineers salary to get jr. engineer productivity. Given that most devs switch after 2 years this is a huge productivity hit and it's all front loaded.
There's something wrong with your hiring pipeline and IC career path if that's what you are observing.
Try paying more for new hires.
> 2. While great devs are great, it's a lot easier to figure out if someone is a framework/language expert than if they are an intrinsically great dev in an interview. i.e. ("Do you know C# well?" is easier to determine than "Are you a good problem solver?")
It's easier to grade multiple choice exams as compared to essays. But the former mostly measures how well someone can rote memorize.
> 5. Most devs are searching for jobs in the ecosystems they like working in. But a lot of devs who can't find a job get desperate and start applying to everything, which can bring down average quality of people who don't have expertise.
Get a better hiring pipeline. If you start dealing with too many clueless candidates it's time to look out where they are coming from (which recruiter, school, whatever) and switching source.
We were paying ~200k a year which while not FAANG is almost double the national average for software engineers.
> It's easier to grade multiple choice exams as compared to essays. But the former mostly measures how well someone can rote memorize.
It seems obvious to me if you have two equally useful attributes, and two measures. You should rely on the measure that more accurately reflects the actual attribute. Finding and hiring great problem solvers is a notoriously hard problem.
> Get a better hiring pipeline. If you start dealing with too many clueless candidates it's time to look out where they are coming from (which recruiter, school, whatever) and switching source.
What pipelines would you suggest? We used recruiters, indeed, monster, hiring, hacker news, stack overflow, etc... None of them were a silver bullet. They all had drawbacks.
> We were paying ~200k a year which while not FAANG is almost double the national average for software engineers.
I read two things: Not FAANG and national average.
If you are competing for FANNG talent that's where you should aim. Whatever average, that includes all bodyshops and bootcamp grads is a useless measure. Average Football player in the US and NFL football players have very different compensations.
> What pipelines would you suggest? We used recruiters, indeed, monster, hiring, hacker news, stack overflow, etc... None of them were a silver bullet. They all had drawbacks.
For college hires go directly at the source. At which university do you recruit?
> 1. For the first 6 months you're paying a sr. engineers salary to get jr. engineer productivity.
Ouch. While I myself have been guilty of that 2-3 times during my sadly way too rich on customers and employers career, this is definitely the exception and something with your hiring filters is very wrong.
Combined with your disclosure that you pay about $200K but still have problems with good programmers then I'd think you are letting people in either way too easily or you don't aim well. Which brings me to...
> 2. While great devs are great, it's a lot easier to figure out if someone is a framework/language expert than if they are an intrinsically great dev in an interview. i.e. ("Do you know C# well?" is easier to determine than "Are you a good problem solver?")
I will respectfully disagree with the last assertion. You or the people who interview devs must reach outside of the usual leetcode / whiteboard tests and do some research on more general interviews and learn techniques through which you will get a very good idea if the interviewee is a good problem solver.
Trouble is, most tech interviewers view gaining those extra evaluation skills as a waste of time.
Piece of advice: give the candidate 10-15 minute and an easy coding problem they could solve in front of you, or give them a really small homework (not this "you'll need 1-2 days at home to solve this homework" nonsense) -- but don't make the tech aspect of the interview the dominant part. Talk with the candidate. Give them a few examples of tough situations from the past. Chat with them about how would they approach the problem(s). Ask them what they know about CI/CD, about best practices in framework X or Y, what project or task that they did makes them proud of themselves. Many other such great interview questions exist.
Not meaning any disrespect to you, you seem to be trying hard to get good devs. But from what I read here it does seem like the aim of your company isn't good and it's mis-firing the hiring gun.
$200K will tempt a lot of people to lie and "wing it" when they get hired. But you should leave the high remuneration in place. That way when you get a good professional they'll have one extra -- and very fat -- reason not to leave. :)
If it took me six months to become productive, I would be deeply embarrassed. There must be something wrong with the talent pool you are able to attract.
To elaborate a good engineer will be able to read a well designed system and almost immediately start mimicking what needs to be done when adding new features regardless of how much experience they have in the given language/framework.
Maybe I haven't seen enough great devs but I see a lot of great devs stumble into a system or framework and they're doing their best but they want to be that great dev and work fast and ... they stumble though stuff that a mediocre dev who knows the system knows better than to do.
> For the first 6 months you're paying a sr. engineers salary to get jr. engineer productivity.
Then you are doing something wrong or have a watered down notion of "senior engineer" (as in "junior engineer" that spent X years on the job, as opposed to someone who is actually progressing well through his career in that time). Senior engineers should IMMEDIATELY outperform junior engineers. Knowledge of the system is largely unnecessary. What senior engineers bring to the table are completely different skills than junior engineers. You can have 100 junior engineers and they will still not be able to figure out the things a good senior engineer will do for you.
Probably you are not utilizing them correctly or giving them the right problems to solve.
I'm using the definition of someone who has been professionally developing software for 10+ years.
So I'm comparing someone who has been professionally developed software on a different stack for 10 years compared to someone who has developed software on an identical stack to yours for 1-2 years.
If you ever need heart surgery, do you want the surgeon who has done 10 years of heart surgery (or better yet, 30 years)?
Or do you want the surgeon who has jumped from area to area and has no more than a year or two of experience in each area? The experience doing knee replacements will be invaluable in your heart surgery. Right?
It is so weird that this meme of "10 times one year of experience" is somehow become a negative.
I've heard this trope for the past 10 years. And just like different sr. devs are better or worse jr. devs can be better or worse. Ideally you always want to hire better.
Yes six months seems very long I recall when I switched to a new language (PL1/G) on the Map Reduce part of our project, the developer I took over from after 3 days said "you don't know it all yet"
I was teaching my self from a 1964 vintage IBM manual that my father had kept :-)
It's not just a new language(C#), it's also a new ORM (EF Core), a new front end (React or Angular or Razor or Blazor or whatever), a new database(SQL Server), a new cloud provider(Azure), a new web framework(ASP.Net), a new work tracker(Azure Devops)
It can be, but a senior who is well-versed in the fundamentals and has some exposure to complimentary tools in other ecosystems is not going to have a problem coming up to speed with those tools.
What they're going to spend more time on is: learning how you decided to solve your problems with your knowledge of those tools and how you decided to fit it all together.
If you have been around for a sufficient number of tech cycles you already have conceptually analogous systems in your head, which you just have to remap to the new syntax. That's what makes a "senior".
The frontends are actually the hardest to stick with because they turn over fastest, probably followed by distributed-compute solutions. C# is a short walk from Java, SQL has been around for decades(even given dialect differences that change best practice).
You aren't wrong that it is a bit of work. It's just less work than learning the actual software itself by a lot. Learning .NET's flavor of the year framework stack is not that bad since there is lots of good documentation, classes, books, and blogs. Your software, at best, has documentation that is as good as .NET's. This is highly unlikely though. Learning the product's layout and quirks dwarfs learning the latest incarnation of .NET.
But there are a couple of reasons why I hire for for expertise in the ecosystem. Granted I'm in .NET which is a very homogenous ecosystem, so framework/library/tool knowledge bifurcates into people who are experts on every tool/library/framework we use and people who've never used one.
1. For the first 6 months you're paying a sr. engineers salary to get jr. engineer productivity. Given that most devs switch after 2 years this is a huge productivity hit and it's all front loaded.
2. While great devs are great, it's a lot easier to figure out if someone is a framework/language expert than if they are an intrinsically great dev in an interview. i.e. ("Do you know C# well?" is easier to determine than "Are you a good problem solver?")
3. Being an expert on an ecosystem pays dividends even after the first couple of years albeit smaller than the first 2.
4. It's not that much harder to hire someone with expertise in your ecosystem than not.
5. Most devs are searching for jobs in the ecosystems they like working in. But a lot of devs who can't find a job get desperate and start applying to everything, which can bring down average quality of people who don't have expertise.