Hacker News Reader

Comment by bluedino | Hacker News Reader

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.

View on HN

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.

> 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.

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)

That's a lot to learn.

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.

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.

That in combination with the learning curve of all the tech can make the ramp up much longer than might be acceptable.

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).

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.

There are engineers with 10 times one year of experience and others with ten years of experience.

Believe me they are very different.

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.

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.

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.

> 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...

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. :)

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.

> The largest impact I have ever had was when my manager put some trust in me, gave me autonomy and a huge project.

Full stop, this is the _only_ way I think to allow an engineer the ability to actually affect change.

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.

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.

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?

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.

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.

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.

> simple as a "Birthday" field to the user profile pages

Nothing simple about this, considering that Omega Star doesn't support ISO timestamps.

Yeah if that other team doesn't get their fucking shit together we're blocked. We're fucking blocked! And we'll die alone.

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.

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...)

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.)

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.

> 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 ?

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.

That was my experience with Java. I knew C++ and I was able to start coding on Java almost immediately, for me Java was semantic subset of C++. Of course I had some books and checked out things here and there and, of course, Eclipse was of tremendous help to me, but I never did Java learning as a specific activity.

That was Java 5, though. And frameworks is a different story either, I spent lots of time trying to figure out what J2EE is.

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.

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.

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.

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

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.

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.

What are ways to find out if someone is good at learning new things?

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).

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.

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.

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.

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.

Reply on news.ycombinator.com