7 ms·

This has always been my pet peeve with jobs that won't hire people without '5-7 years experience with X' - the vast majority of these jobs do not need an EXPERT

This has always been my pet peeve with jobs that won't hire people without '5-7 years experience with X' - the vast majority of these jobs do not need an EXPERT on language x, or framework y. If they do, the rest of this post does not apply. You can learn enough of a language to be dangerous in just a couple weeks. Enough to be productive in 2-3 months. However, there are 3 other things you have to learn: 1. How the code for the project you are hired for works. How it's laid out. All the weird shit about it. 2. How the framework/libraries used by the project works. Nothing to do with the project, but maybe you haven't used Angular, Swing, or Boost before. 3. How the data is laid out, and how it gets in/out of your system. What database tables are there, what's the workflow. Those 3 things are the hard part and what take 6-12 months. Learning Javascript, Ruby, or whatever language is the least of your worries.

swader999 6y ago
Insightful. The other area is often learning the intricacies of the infrastructure it runs on.
- sumtechguy 6y ago
  Sometimes it is just the env you work in and how much they trust you. Some places 'I need a server' you will have a VM or machine on your desk in an hour. Others companies it is a 2 year processes and bunches of approvals.
pjmlp 6y ago
The problem is that many places want to hire developers and have them deliver as soon as they get a devenv, with zero efforts on training, naturally that only works if the experience is already there.
- rory_isAdonk 6y ago
  Experiencing this currently, no docs on what access to apply for deployment/build systems, no explanation of graph database. Only person that's not a grad, expected to deliver sprint one.
- LeifCarrotson 6y ago
  No, as the article describes, that does not work even if the language/framework experience is already there. If you're a veteran with Javascript, and Angular, and Node, and MySQL, you will scarcely be able to add something as simple as a "Birthday" field to the user profile pages of your new employer's SPA on your first day or first week on the job. That background will give you an idea of how you would have done that on previous applications, and give a slight speed boost as you try to skim the project for tables and functions that are related to user profiles, but the new application is almost certainly different. If you knew C#, SQLite, and desktop application development instead, or, heck, were fresh out of college with nothing but some toy applications that used Java to write some CSV files, that would scarcely matter, you'd still spend that first day reading through the codebase to understand how user profiles work, and regardless of your experience you're probably merely going to copy-paste and modify the "Occupation" field anyways. There are a couple minutes of that first day where you're editing a bit of code and it will go slightly faster if you can remember off the top of your head that in Angular, the keyword to parameterize an input[date] field with a maximum value so your users don't accidentally claim to be infants is "ngMax". Or you could go to docs.angularjs.org and look that up in 5 minutes or less, which is a delay, but that doesn't matter much if the other 7 hours and 55 minutes of that first day (and much of the coming weeks and months) will be spent learning the domain-specific details of your business, navigating the project hierarchy, and memorizing the most common table columns and class names. I think too many hiring managers are unwilling to voice and reason about their subconscious expectation that they're going to hire someone who is a clone of their existing employees. The only developer on the planet with 5 years' experience building a CRM and scheduling tool for landscapers in West Virgina using React/Node/MySQL with database layout and code architecture that matches what you have is named Dave, he's already in the office down the hall, and yes he's behind on v3 because he's swamped with tickets from customers on V2 right now, he needs you to hire someone to help. Just get anyone who's reasonably technically competent and good at problem-solving, and they'll pick it up as has always been done.
  - snicker7 6y ago
    > simple as a "Birthday" field to the user profile pages Nothing simple about this, considering that Omega Star doesn't support ISO timestamps.
- at-fates-hands 6y ago
  I've experienced both. The first place I worked as a dev, they had copious amounts of documentation and such an expansive wiki, every time I asked something, the common response was, "fates, it's in the wiki." I did have quite a bit of onboarding, but after a few weeks, the purpose of handing me off to their documentation was to make me more independent and solve the problems myself Conversely, I started a new FTE role at a large health care corporation. No training, no onboarding, not even a cursory tour of the network, what source control they use, literally nothing. The amount of time I wasted learning all of this I'm sure cost the company more money than having a proper onboarding and training program. I pushed my manager and his manager on the importance of onboarding (we were hiring a lot of new devs at the time) but his retort was "it's not in our budget, you just have to learn as you go." Ironically, having spoken up, every time a new dev joined our team, they were pawned off on me to bring them up to speed on everything they needed to know - all the while handling a full load of project work. Not properly onboarding developers has a huge impact on multiple areas of a business. I was shocked a smaller company knew this, but the larger, entrenched corporation wanted nothing to do with addressing this.
notretarded 6y ago
You're overestimating the competency, drive, and intelligence of an average developer. Fortunate are you to have worked with people to give you such a point of view.
- lostcolony 6y ago
  Yeah, but what hiring process intends to hire average devs? Yes, most probably -end up with- average devs...but most also ask and test for X years in a language, not people who seek to learn things and are curious and want to take responsibility and own things.
jeffreyrogers 6y ago
I mostly agree, with the caveat that people can usually learn something analogous to what the know quickly, but not necessarily in a new domain. E.g. easy to go from Django to Rails or vice-versa. Similarly, not too hard to go from C++ to Java or Go, etc. But I had a tough time doing front-end development for the first time despite being a pretty strong backend/systems/embedded programmer because the programming model was so different from what I was used to and I was coming into a complicated product.
smt88 6y ago
I learned C# in under a day by using ReSharper and reading a few articles about C# idioms and memory management. If you know a variety of languages already and your IDE is hinting, linting, and suggesting idioms, you can be productive super quickly. (I've now been writing C# for years and can confirm that my understanding of the language has not changed dramatically since my first week with it.)
- cableshaft 6y ago
  The actual language, sure. The ecosystem, tools, libraries, and techniques surrounding it, I would say takes longer. For example, I was making games professionally using C#/.Net for several years before getting hired in enterprise app development. I was able to contribute right away, but there was a ton I wasn't familiar with and took time to understand, from SQL Server (especially SQL optimization, transactions, triggers, etc), to BLL/DAO, dependency injection, CQRS, Unit Testing, Octopus Deployment, Powershell, Active Directory, TFS Server/Build, Windows Services, XAML, Microsoft Azure, IIS, Entity Framework, .NET Core, and a bunch of other things. Six years into enterprise/web work on the Microsoft stack and I'm still learning new things here and there. All that being said, I will reiterate that I was able to work on bug fixes and new features within a week of being hired at both companies, despite not knowing hardly any of this stuff at the beginning, and most of that time was spent getting familiar with how everything was structured and flowed in all their various software.
- jcelerier 6y ago
  > I learned C# in under a day by using ReSharper and reading a few articles about C# idioms and memory management. did that include reflection ? P/Invoke, and support for native pointers ? async/await and coroutines ? differences between structs and classes ? how generics are implemented ?
  - smt88 6y ago
    Yes to all except P/Invoke. I don't know what that is or why I'd need it. I'm writing web services, not replacing C++. I also haven't used native pointers, but have read about them.
JamesBarney 6y ago
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.
- martamorena234 6y ago
  > 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.
  - Mauricebranagh 6y ago
    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 :-)
irrational 6y ago
I agree. The main thing I'm looking for in new hires is the ability to think logically, problem solve, and learn new things. I don't care whether you already know whatever languages or libraries we are using.
- cutemonster 6y ago
  What are ways to find out if someone is good at learning new things?
duxup 6y ago
Yeah there's way too much alphabet soup exact matching going on out there job wise, and not enough "You know that framework or system is not unlike what this dev knows..." going on.
wtetzner 6y ago
Not to mention the huge amount of time it often takes to get setup and understand how to use the company's internal tools for source hosting, code review, ticket tracking (even it you used Jira at your old job and are now using at your new one, it's probably configured differently), CI, etc.
username90 6y ago
In a traditional corporation you wont get fired for hiring devs with many years of experience in the correct stacks. That is the most important incentive. If you hire devs with experience in the wrong stacks and it doesn't work out people will start asking questions, why did you hire this guy even though he didn't know the things we need?
sevrinsky 6y ago
I have often said that there are practically no C programming jobs. Rather, there are many job writing in the macros for a specific project (with the minimal associated C code).
notyourwork 6y ago
This is why I frown upon people who hop jobs or teams within a year. To be truly productive and effective large scale systems require at least a year of time.
karmelapple 6y ago
That’s one advantage of opinionated frameworks like EmberJS. If you’re experienced with Ember, that knowledge will carry over a lot to other Ember apps. It’s pretty wild how consistent the architecture is from one app to another... and that’s thanks to a lot of very smart engineers being opinionated about how the apps should work. Our team chose Ember since we didn’t have extensive front end experience and opinions, and it’s worked out well for us overall.
dublin 6y ago
NO! The important (and hardest) part is NONE OF THE ABOVE. It's understanding the REAL WORLD PROBLEM that the software is intended to help with! Example: A decade ago I hired a Designer who had the potential to become a decent JS/UI coder, but wasn't one yet. He upleveled his own JS skills to where he was quite competent. But more importantly, we made sure he learned WHAT THE SOFTWARE DOES IN THE REAL WORLD. If he doesn't know that, and how the people that use it think about their own jobs and environments, he can't possibly design and write good interfaces. (This was software to manage, operate, maintain, and optimize utility-scale solar power plants.) When we merged with another company in the space a year or two later, he came back and reported that he was stunned that he (the UI designer!) knew MUCH more about how solar power plants actually operated than any of their "engineers" writing their application code. (And yes, he did...) It's not about solving the problem in the currently "right" or trendy way - it's about doing a good job of solving the right problem in a really useful way! (FWIW, I no longer care at all which tools, languages, or frameworks are used - if you care about that, you're focusing on the wrong stuff...)
dwd 6y ago
4. Domain knowledge Though I would have it as #1 in any job. Having some idea of what the business using the software is trying to achieve (at both the macro and micro levels) is far more valuable. Basically knowing the why, you can use as the frame for the what and how. Some of those quirky pieces of software could be misguided, unnecessary or counter-productive - and this is where you become a value-add to the organisation.

swader999 6y ago

Insightful. The other area is often learning the intricacies of the infrastructure it runs on.

sumtechguy 6y ago
Sometimes it is just the env you work in and how much they trust you. Some places 'I need a server' you will have a VM or machine on your desk in an hour. Others companies it is a 2 year processes and bunches of approvals.

pjmlp 6y ago

The problem is that many places want to hire developers and have them deliver as soon as they get a devenv, with zero efforts on training, naturally that only works if the experience is already there.

rory_isAdonk 6y ago
Experiencing this currently, no docs on what access to apply for deployment/build systems, no explanation of graph database. Only person that's not a grad, expected to deliver sprint one.
LeifCarrotson 6y ago
No, as the article describes, that does not work even if the language/framework experience is already there. If you're a veteran with Javascript, and Angular, and Node, and MySQL, you will scarcely be able to add something as simple as a "Birthday" field to the user profile pages of your new employer's SPA on your first day or first week on the job. That background will give you an idea of how you would have done that on previous applications, and give a slight speed boost as you try to skim the project for tables and functions that are related to user profiles, but the new application is almost certainly different. If you knew C#, SQLite, and desktop application development instead, or, heck, were fresh out of college with nothing but some toy applications that used Java to write some CSV files, that would scarcely matter, you'd still spend that first day reading through the codebase to understand how user profiles work, and regardless of your experience you're probably merely going to copy-paste and modify the "Occupation" field anyways. There are a couple minutes of that first day where you're editing a bit of code and it will go slightly faster if you can remember off the top of your head that in Angular, the keyword to parameterize an input[date] field with a maximum value so your users don't accidentally claim to be infants is "ngMax". Or you could go to docs.angularjs.org and look that up in 5 minutes or less, which is a delay, but that doesn't matter much if the other 7 hours and 55 minutes of that first day (and much of the coming weeks and months) will be spent learning the domain-specific details of your business, navigating the project hierarchy, and memorizing the most common table columns and class names. I think too many hiring managers are unwilling to voice and reason about their subconscious expectation that they're going to hire someone who is a clone of their existing employees. The only developer on the planet with 5 years' experience building a CRM and scheduling tool for landscapers in West Virgina using React/Node/MySQL with database layout and code architecture that matches what you have is named Dave, he's already in the office down the hall, and yes he's behind on v3 because he's swamped with tickets from customers on V2 right now, he needs you to hire someone to help. Just get anyone who's reasonably technically competent and good at problem-solving, and they'll pick it up as has always been done.
- snicker7 6y ago
  > simple as a "Birthday" field to the user profile pages Nothing simple about this, considering that Omega Star doesn't support ISO timestamps.
at-fates-hands 6y ago
I've experienced both. The first place I worked as a dev, they had copious amounts of documentation and such an expansive wiki, every time I asked something, the common response was, "fates, it's in the wiki." I did have quite a bit of onboarding, but after a few weeks, the purpose of handing me off to their documentation was to make me more independent and solve the problems myself Conversely, I started a new FTE role at a large health care corporation. No training, no onboarding, not even a cursory tour of the network, what source control they use, literally nothing. The amount of time I wasted learning all of this I'm sure cost the company more money than having a proper onboarding and training program. I pushed my manager and his manager on the importance of onboarding (we were hiring a lot of new devs at the time) but his retort was "it's not in our budget, you just have to learn as you go." Ironically, having spoken up, every time a new dev joined our team, they were pawned off on me to bring them up to speed on everything they needed to know - all the while handling a full load of project work. Not properly onboarding developers has a huge impact on multiple areas of a business. I was shocked a smaller company knew this, but the larger, entrenched corporation wanted nothing to do with addressing this.

notretarded 6y ago

You're overestimating the competency, drive, and intelligence of an average developer. Fortunate are you to have worked with people to give you such a point of view.

lostcolony 6y ago
Yeah, but what hiring process intends to hire average devs? Yes, most probably -end up with- average devs...but most also ask and test for X years in a language, not people who seek to learn things and are curious and want to take responsibility and own things.

jeffreyrogers 6y ago

I mostly agree, with the caveat that people can usually learn something analogous to what the know quickly, but not necessarily in a new domain. E.g. easy to go from Django to Rails or vice-versa. Similarly, not too hard to go from C++ to Java or Go, etc. But I had a tough time doing front-end development for the first time despite being a pretty strong backend/systems/embedded programmer because the programming model was so different from what I was used to and I was coming into a complicated product.

smt88 6y ago

I learned C# in under a day by using ReSharper and reading a few articles about C# idioms and memory management. If you know a variety of languages already and your IDE is hinting, linting, and suggesting idioms, you can be productive super quickly. (I've now been writing C# for years and can confirm that my understanding of the language has not changed dramatically since my first week with it.)

cableshaft 6y ago
The actual language, sure. The ecosystem, tools, libraries, and techniques surrounding it, I would say takes longer. For example, I was making games professionally using C#/.Net for several years before getting hired in enterprise app development. I was able to contribute right away, but there was a ton I wasn't familiar with and took time to understand, from SQL Server (especially SQL optimization, transactions, triggers, etc), to BLL/DAO, dependency injection, CQRS, Unit Testing, Octopus Deployment, Powershell, Active Directory, TFS Server/Build, Windows Services, XAML, Microsoft Azure, IIS, Entity Framework, .NET Core, and a bunch of other things. Six years into enterprise/web work on the Microsoft stack and I'm still learning new things here and there. All that being said, I will reiterate that I was able to work on bug fixes and new features within a week of being hired at both companies, despite not knowing hardly any of this stuff at the beginning, and most of that time was spent getting familiar with how everything was structured and flowed in all their various software.
jcelerier 6y ago
> I learned C# in under a day by using ReSharper and reading a few articles about C# idioms and memory management. did that include reflection ? P/Invoke, and support for native pointers ? async/await and coroutines ? differences between structs and classes ? how generics are implemented ?
- smt88 6y ago
  Yes to all except P/Invoke. I don't know what that is or why I'd need it. I'm writing web services, not replacing C++. I also haven't used native pointers, but have read about them.

JamesBarney 6y ago

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.

martamorena234 6y ago
> 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.
- Mauricebranagh 6y ago
  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 :-)

irrational 6y ago

I agree. The main thing I'm looking for in new hires is the ability to think logically, problem solve, and learn new things. I don't care whether you already know whatever languages or libraries we are using.

cutemonster 6y ago
What are ways to find out if someone is good at learning new things?

duxup 6y ago

Yeah there's way too much alphabet soup exact matching going on out there job wise, and not enough "You know that framework or system is not unlike what this dev knows..." going on.

wtetzner 6y ago

Not to mention the huge amount of time it often takes to get setup and understand how to use the company's internal tools for source hosting, code review, ticket tracking (even it you used Jira at your old job and are now using at your new one, it's probably configured differently), CI, etc.

username90 6y ago

In a traditional corporation you wont get fired for hiring devs with many years of experience in the correct stacks. That is the most important incentive. If you hire devs with experience in the wrong stacks and it doesn't work out people will start asking questions, why did you hire this guy even though he didn't know the things we need?

sevrinsky 6y ago

I have often said that there are practically no C programming jobs. Rather, there are many job writing in the macros for a specific project (with the minimal associated C code).

notyourwork 6y ago

This is why I frown upon people who hop jobs or teams within a year. To be truly productive and effective large scale systems require at least a year of time.

karmelapple 6y ago

That’s one advantage of opinionated frameworks like EmberJS. If you’re experienced with Ember, that knowledge will carry over a lot to other Ember apps. It’s pretty wild how consistent the architecture is from one app to another... and that’s thanks to a lot of very smart engineers being opinionated about how the apps should work. Our team chose Ember since we didn’t have extensive front end experience and opinions, and it’s worked out well for us overall.

dublin 6y ago

NO! The important (and hardest) part is NONE OF THE ABOVE. It's understanding the REAL WORLD PROBLEM that the software is intended to help with! Example: A decade ago I hired a Designer who had the potential to become a decent JS/UI coder, but wasn't one yet. He upleveled his own JS skills to where he was quite competent. But more importantly, we made sure he learned WHAT THE SOFTWARE DOES IN THE REAL WORLD. If he doesn't know that, and how the people that use it think about their own jobs and environments, he can't possibly design and write good interfaces. (This was software to manage, operate, maintain, and optimize utility-scale solar power plants.) When we merged with another company in the space a year or two later, he came back and reported that he was stunned that he (the UI designer!) knew MUCH more about how solar power plants actually operated than any of their "engineers" writing their application code. (And yes, he did...) It's not about solving the problem in the currently "right" or trendy way - it's about doing a good job of solving the right problem in a really useful way! (FWIW, I no longer care at all which tools, languages, or frameworks are used - if you care about that, you're focusing on the wrong stuff...)

dwd 6y ago

4. Domain knowledge Though I would have it as #1 in any job. Having some idea of what the business using the software is trying to achieve (at both the macro and micro levels) is far more valuable. Basically knowing the why, you can use as the frame for the what and how. Some of those quirky pieces of software could be misguided, unnecessary or counter-productive - and this is where you become a value-add to the organisation.